Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

First experience running DDEV on Windows 10 WSL2 #2251

Closed
dennisameling opened this issue May 13, 2020 · 19 comments
Closed

First experience running DDEV on Windows 10 WSL2 #2251

dennisameling opened this issue May 13, 2020 · 19 comments

Comments

@dennisameling
Copy link
Collaborator

Is your feature request related to a problem? Please describe.
Since DDEV is planning to add explicit support for Windows WSL2, I thought I'd give it a try already on my machine that's running Windows 10 2004. I took the approach of having my project files in the Linux filesystem, not in Windows, for faster performance. This is Microsoft's recommended approach.

Steps I took:

  • Install WSL2
  • Install a WSL2 distro (e.g. Ubuntu 18.04) from the Microsoft Store
  • Start your WSL2 distro, walk through the config steps
  • Install Docker Desktop on Windows 10 2004
  • Go to Docker Desktop Settings > Resources > WSL integration > enable integration for your distro (now docker commands will be available from within your WSL2 distro)

image

image

  • Go to Terminal in the top menu > New terminal
  • Install DDEV for Linux (not for Windows!) using the regular installation steps
  • Run ddev config and ddev start
  • You can now access your DDEV sites from within Windows 🚀 either using the .ddev.site URL or the special localhost port. The only thing that doesn't work yet is the mkcert SSL certificate (as that's installed in Linux, not in Windows):

image

... but after skipping this warning, I can access my DDEV site without any issues (and it's CRAZY FAST 🎉 🚀):

image

If there's anything I can do to help support WSL2 better (as in, improve the developer experience), please let me know!

Describe the solution you'd like
n/a

Describe alternatives you've considered
Tried running DDEV from the Windows OS as well, but filesystem performance was very poor. In Linux it's lightning fast 🚀

Additional context
n/a

@rfay
Copy link
Member

rfay commented May 13, 2020

The trick to getting mkcert to work isn't too hard. There's more than one way to do it, but the basic idea is to set CAROOT on the WSL2 side to point to the CAROOT on the Windows side.

I have a symlink on the WSL2 side in my home directory called "winhome", so ~/winhome is a symlink to /mnt/c/Users/rfay.

  1. On the Windows side, mkcert -install to put the trusted cert into your browser and system.
  2. On the WSL2 side, export CAROOT=~/winhome/AppData/Local/mkcert
  3. ddev poweroff and ddev start and you should be good.

@dennisameling
Copy link
Collaborator Author

That worked 🎉 , but there's one gotcha: your Windows and Linux username need to be exactly the same, otherwise you'll keep getting SSL errors (the Linux username is shown in the certificate on Windows, while the CA on Windows is based on the Windows username). Had to find that out the hard way 😂

Final thing I had to fix was my XDebug config in VS Code; I had to set the hostname to 0.0.0.0 so that it would trigger on Docker in WSL2 👍

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "hostname": "0.0.0.0",
            "port": 9000,
            "pathMappings": {
                "/var/www/html": "${workspaceRoot}"
            }
        },
        {
            "name": "Launch currently open script",
            "type": "php",
            "request": "launch",
            "program": "${file}",
            "cwd": "${fileDirname}",
            "port": 9000
        }
    ]
}

Up and running now on WSL2 + DDEV! Love it 😍

@rfay OK if I write a WSL2 section for the Installation guide, based on the steps mentioned above?

@rfay
Copy link
Member

rfay commented May 13, 2020

I'd love you to write a section in the docs, but maybe first a guest blog on ddev.com?

I don't use the same username on Window and in WSL2, and the CA is not tied to a username, so I'm a little lost about what you're saying there. However, the CAROOT has to point to the user where you're using the web browser. I guess that must be what you're saying.

There are a few other things I've been collecting:

  • Enable WIndows Hypervisor
  • Enable feature Windows Subsystem for Linux
  • wsl --set-default-version 2 Set default version 2 (Must do this BEFORE installing docker)
  • Enable WSL2 in Windows features
  • Get Ubuntu or another distribution from Microsoft store or elsewhere
  • Install docker (stable now works for both Win10 Pro and Home)
  • Enable WSL2 support in Docker (this may not be required any more)
  • Have to install docker and docker-compose clients (homebrew, etc) (Not sure if this is required any more)
  • apt-get install xdg-utils (to make ddev launch work)
  • The fast filesystem (and change-listening) are actually only available inside WSL. So you kind of need X11 for anything that is going to use that filesystem - like GoLand or PHPStorm. vscode has special workaround.
  • With ddev you have to choose one place to work, either "Windows" or wsl2. Because docker is active on both, they will conflict over usage of ddev-router ddev-ssh-agent and other things.
  • nfs is not needed
  • Choose one place to work. Don't go back and forth between regular Windows side and WSL2. Docker wants everybody on WSL2 side, but regardless, lots of bad things happen if you run ddev on both sides.

@dennisameling
Copy link
Collaborator Author

Happy to write a guest blog. Feel free to ping me on Gitter, just joined the drud/ddev room 👍

@rfay
Copy link
Member

rfay commented May 13, 2020

I'm sure you know we'd love you to do both; the blog and the docs update are both super-important with Windows 2004 about to drop.

@dennisameling
Copy link
Collaborator Author

@rfay Here's a concept blog post, let me know what you think:

https://gist.github.com/dennisameling/8317b9dc6b7d971860a4797c64f16eaf

@rfay
Copy link
Member

rfay commented May 18, 2020

Absolutely awesome. Commented there, https://gist.github.com/dennisameling/8317b9dc6b7d971860a4797c64f16eaf#gistcomment-3308672

@dennisameling
Copy link
Collaborator Author

@dennisameling
Copy link
Collaborator Author

Blog post should be done now (see Gist link above), will work on the DDEV installation docs on Thursday. Will be mostly the same content as the blog post but in slightly different format

@rfay
Copy link
Member

rfay commented Jun 1, 2020

Thanks to @dennisameling for writing this up wonderfully on https://ddev.com/ddev-local/ddev-wsl2-getting-started/

Looking forward to your docs PR when you get to it.

@rfay rfay closed this as completed Jun 1, 2020
@dennisameling
Copy link
Collaborator Author

Have the installation docs part now scheduled for the coming weekend, had a lot of work to go in the last 2 weeks. Apologies for the delay. Will provide a separate PR when done 👍

@rfay
Copy link
Member

rfay commented Jun 3, 2020

You are AWESOME, thanks.

@MuhammadMurtaza
Copy link

Hey guys I am not able to make xdebug to work.
My setup is ddev running in WSL2 Ubuntu
So there are three things:

  1. My browser (running in windows)
  2. Visual Studio code (running in Ubuntu Remote-WSL )
  3. My Drupal php code (running inside ddev container in Ubuntu)
    Problem is 1 and 3 can access host.docker.internal but 2 can't.
    I tried both 0.0.0.0 and mysite.ddev.site in visual studio code xdebug launch.json.
    I have disabled my firewall. I have tried changing default port from 9000 to 9010
    When I check container logs in windows I am getting this warning
    [21-Feb-2021 16:51:57] WARNING: [pool www] child 2327 said into stderr: "NOTICE: PHP message: Xdebug: [Step Debug] Time-out connecting to debugging client, waited: 200 ms. Tried: host.docker.internal:9010 (through xdebug.client_host/xdebug.client_port) :-("

Also I have installed xdg-utils but still I can't seem to open anything. xdg-open https://google.com doesn't seem to work so is ddev launch
I am getting
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: www-browser: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: links2: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: elinks: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: links: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: lynx: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: w3m: not found
xdg-open: no method available for opening 'https://drupal9.ddev.site'
Failed to run launch ; error=exit status 3

@rfay
Copy link
Member

rfay commented Feb 21, 2021

Hi @MuhammadMurtaza - this is a closed issue.

Please do these things and then open a new issue if you need one, or use one of the other support venues

  1. Your xdg-utils issue doesn't have to do with xdebug; it affects only ddev launch. It's failing because you don't have a browser apparently, and it's intended to open the browser on the Windows side, and perhaps you have $DISPLAY set for using X inside WSL2.
  2. Please go through the troubleshooting steps https://ddev.readthedocs.io/en/stable/users/step-debugging/#troubleshooting-xdebug
  3. Please read @dennisameling 's article on debugging with WSL2, https://www.ddev.com/ddev-local/ddev-wsl2-getting-started/

If you're running vscode using X11 inside WSL2 and setting $DISPLAY, that's a completely different (and totally valid) technique.

@rfay
Copy link
Member

rfay commented Feb 21, 2021

I do see you are running vscode inside WSL2, so that's a whole new situation, and it will work just like it does on Linux, so you should be able to use the debugging scenario pretty easily.

@MuhammadMurtaza
Copy link

I am running vscode in windows but using Remote-WSL extension to connect to ddev which is in ubuntu (WSL2 default distro in docker)
Followed @dennisameling article In fact it was the main article I used to install and setup remote-wsl extension but it doesn't seem to solve my problem.
let me know if I need to follow concrete steps to submit an issue. I am currently confused with all three systems

  1. VSCode is in windows using remote-wsl to access ubuntu file system and docker desktop's dashboard is also running there
  2. Ubuntu is the default distro for docker and ddev is installed in this ubuntu
  3. when I start a ddev project by ddev start and enable ddev xdebug xdebug seems to try to connect to host.docker.internal which is not accessible from ubuntu. So VSCode listening to all ips in ubuntu doesnt get any request from xdebug.

@rfay
Copy link
Member

rfay commented Feb 21, 2021

Please do the things I asked in #2251 (comment)

@MuhammadMurtaza
Copy link

MuhammadMurtaza commented Feb 21, 2021

Already done. Not just once but again n again with slight variations. Doesn't work for me.
Kindly delete these messages if you want. I am going to delete and uninstall everything and start fresh.
I am using ubuntu 18. Will try using ubuntu 20 but I dont think this is an issue.
The issue is simply docker container seems to consider its host as windows. I can connect to windows from from within docker container after going into ddev ssh and pinging and using telnet. But I can't connect to ip address of ubuntu which is somewhere in the middle (and is not the host) which i don't understand.
host.docker.internal can be used from within container to connect to windows but not to ubuntu. Its not very useful because vscode is trying to listen to all ips within ubuntu and not host windows

@MuhammadMurtaza
Copy link

Aright. I got it working!
It turns out the problem was either Hyper-V. or the system required restart :)
I uninstalled Hyper-V which created all these virtual and bridged network adapters. And then restarted the system. Once I removed those, It seems to be working just fine. Cheers!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants