ddev uses host ip address for host.docker.internal, doesn't work with vscode language server

[MurzNN]

Is there an existing issue for this?

• I have searched the existing issues

Run a Diagnostic and Paste Link Here

Click to expand

$ ddev debug test Running bash [-c /tmp/test_ddev.sh] OS Information: Linux MURZ_COMP 5.15.0-25-generic #25-Ubuntu SMP Wed Mar 30 15:54:22 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux User information: uid=1000(alexey_korepov) gid=1000(alexey_korepov) groups=1000(alexey_korepov),4(adm),24(cdrom),27(sudo),30(dip),44(video),46(plugdev),109(render),120(lpadmin),132(lxd),133(sambashare),997(docker) DDEV version: ITEM VALUE DDEV version v1.19.1 architecture amd64 db drud/ddev-dbserver-mariadb-10.3:v1.19.0 dba phpmyadmin:5 ddev-ssh-agent drud/ddev-ssh-agent:v1.19.0 docker 20.10.14 docker-compose v2.3.3 docker-platform MURZ_COMP mutagen 0.12.0 os linux router drud/ddev-router:v1.19.0 web drud/ddev-webserver:v1.19.0-1 ======= DDEV global info ========= Global configuration: instrumentation-opt-in=true omit-containers=[] mutagen-enabled=false nfs-mount-enabled=false router-bind-all-interfaces=false internet-detection-timeout-ms=750 disable-http2=false use-letsencrypt=false letsencrypt-email= table-style=default simple-formatting=false auto-restart-containers=false use-hardened-images=false fail-on-hook-fail=false required-docker-compose-version= use-docker-compose-from-path=false no-bind-mounts=false

======= DOCKER info =========
docker location: -rwxr-xr-x 1 root root 61890504 Mar 24 05:45 /usr/bin/docker
======= Mutagen Info =========
======= Docker Info =========
Docker platform: MURZ_COMP
Using docker context: default (unix:///var/run/docker.sock)
docker-compose: v2.3.3
Using DOCKER_HOST=unix:///var/run/docker.sock
Docker version: 20.10.14
Able to run simple container that mounts a volume.
Able to use internet inside container.
Docker disk space:
Filesystem Size Used Available Use% Mounted on
overlay 105.2G 74.9G 24.9G 75% /

The ddev-ssh-agent container has been removed. When you start it again you will have to use 'ddev auth ssh' to provide key authentication again.
Existing docker containers:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
Creating a new ddev project config in the current directory (/home/alexey_korepov/tmp/tryddevproject-28837)
Once completed, your configuration will be written to /home/alexey_korepov/tmp/tryddevproject-28837/.ddev/config.yaml

Found a php codebase at /home/alexey_korepov/tmp/tryddevproject-28837
Project type has no settings paths configured, so not creating settings file.
Configuration complete. You may now run 'ddev start'.
Network ddev_default created
Starting tryddevproject-28837...
Container ddev-ssh-agent Started
ssh-agent container is running: If you want to add authentication to the ssh-agent container, run 'ddev auth ssh' to enable your keys.
Pushed mkcert rootca certs to ddev-global-cache/mkcert
Network ddev-tryddevproject-28837_default Created
Container ddev-tryddevproject-28837-web Started
Container ddev-tryddevproject-28837-dba Started
Container ddev-tryddevproject-28837-db Started
Container ddev-router Started
Project type has no settings paths configured, so not creating settings file.
Project type has no settings paths configured, so not creating settings file.
Successfully started tryddevproject-28837
Project can be reached at https://tryddevproject-28837.ddev.site https://127.0.0.1:49161

• curl --fail -I tryddevproject-28837.ddev.site
  HTTP/1.1 200 OK
  Server: nginx/1.20.1
  Date: Thu, 28 Apr 2022 06:42:22 GMT
  Content-Type: text/html; charset=UTF-8
  Connection: keep-alive
  Vary: Accept-Encoding

• '[' 0 -ne 0 ']'

• set +x
  Thanks for running the diagnostic. It was successful.
  Please provide the output of this script in a new gist at gist.github.com
  Running ddev launch in 5 seconds

Current Behavior

I've got the problem with connecting to XDebug within a ddev-web container. It enables well, but PHP script can't connect to debugger port.
Seems this is because the host.docker.internal hostname is attached to a wrong IP.

But I've found a workaround how to fix this issue via manually editing /etc/hosts file, it's described in "Steps To Reproduce".

Expected Behavior

PHP script should connect to debugger port successfully.

Steps To Reproduce

1. Create a new test environment via ddev config --project-type drupal9.

2. Enable xdebug via ddev xdebug enable

3. Attach VS Code to container, configure XDebug with default settings:

    {
      "name": "Listen for Xdebug",
      "type": "php",
      "request": "launch",
      "port": 9003
    },

4. Create a test file /var/www/html/index.php with a simple script:

<?php echo "Hello world\n";

5. Place a breakpoint on the line.

6. Launch the script from console and see that xdebug can't connect to the host:

$ php ./index.php 
Xdebug: [Step Debug] Time-out connecting to debugging client, waited: 200 ms. Tried: host.docker.internal:9003 (through xdebug.client_host/xdebug.client_port) :-(
Hello world

7. Check the active network interfaces and compare it with generated /etc/hosts file:

$ sudo apt update; sudo apt install net-tools; ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.21.0.2  netmask 255.255.0.0  broadcast 172.21.255.255

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.18.0.8  netmask 255.255.0.0  broadcast 172.18.255.255

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0

$ cat /etc/hosts 
127.0.0.1       localhost
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.1      host.docker.internal
172.21.0.2      test1-web
172.18.0.8      test1-web

See that the subnet for 172.17.0.1 ip is missing.

9. Try to move host.docker.internal to the 172.21.0.2 ip via modifying the /etc/hosts file like this:

#172.17.0.1      host.docker.internal
172.21.0.2      test1-web host.docker.internal

10. Try to launch the php ./index.php - xdebug starts working well!

Anything else?

No response

[rfay]

Could you please show the output of docker network inspect bridge ?

This is Ubuntu 20.04? And not in WSL2, right?

[MurzNN]

Yes, Ubuntu 22.04 (and was been reproducible on 20.04 too), here is my docker network inspect bridge output:

[
    {
        "Name": "bridge",
        "Id": "0984523bdd2135dc1fdfa4a0f4e334fffee3656192217c008e2441257b3f30c3",
        "Created": "2022-04-28T00:30:21.109906849+04:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]

[rfay]

ddev uses the gateway value "Gateway": "172.17.0.1" for host.docker.internal. But it does not put it into /etc /hosts.

Could you please gist the .ddev/.ddev-docker-compose-base.yaml on gist.github.com and link it here? The host.docker.internal is defined there.

[MurzNN]

It puts it to /etc/hosts by default, and I even can ping it:

$ cat /etc/hosts 
127.0.0.1       localhost
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.1      host.docker.internal
172.21.0.2      test1-web
172.18.0.8      test1-web

$ ping host.docker.internal -c 1
PING host.docker.internal (172.17.0.1) 56(84) bytes of data.
64 bytes from host.docker.internal (172.17.0.1): icmp_seq=1 ttl=64 time=0.100 ms

--- host.docker.internal ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.100/0.100/0.100/0.000 ms

But the problem is that is the host's ip (not the internal container's ip), so xdebug listener, launched internally inside container, can't catch the connections.

And here is my .ddev/.ddev-docker-compose-base.yaml file contents: https://gist.github.com/MurzNN/b2b4b01e1a8abd43e2403794f686569e

[rfay]

It looks to me like ddev is doing everything right. Can you please check this with a trivial new project, one of the quickstarts?

[rfay]

Btw, the debug listener is on host, not in container.

[MurzNN]

This problem is reproducible for me with a trivial new empty project.
Debug listener is launched inside the container, cuz vscode language server is launched inside the container too, here is the process launched inside the container:

alexey_korepov@test1-web:/var/www/html$ ps aux | grep xdebug
alexey_+   68650  0.2  0.1 587052 41864 ?        Sl   08:25   0:00 /home/alexey_korepov/.vscode-server/bin/dfd34e8260c270da74b5c2d86d61aee4b6d56977/node /home/alexey_korepov/.vscode-server/extensions/xdebug.php-debug-1.26.1/out/phpDebug.js

$ sudo netstat -ltnp | grep -w ':9003'
tcp6       0      0 :::9003                 :::*                    LISTEN      68650/node          

[rfay]

I wish you had mentioned vscode server long ago (or maybe I missed it?). That's different from what anybody has ever talked about before in all these years :)

You can use .ddev/php config to change the
xdebug.client_host=127.0.0.1

I imagine, assuming your vscode addon is listening on localhost inside the container.

[MurzNN]

I've mentioned vscode in the step 3 of reproducing:

Attach VS Code to container, configure XDebug with default settings

And yeah, xdebug.client_host=127.0.0.1 solves the problem, thank you!

Bug glad to have this working out-of-the box by default, without manual actions, if it's possible...

[rfay]

Thanks!

• Could. you please edit the original summary now that we know what's going on?
• I'd love to know why you're using the vscode language server inside the container, how it works for you, and your overall experience. And if it has great benefit, it would be wonderful to have a writeup on it somewhere.

Note that the "normal" vscode experience/configuration is described in https://ddev.readthedocs.io/en/latest/users/step-debugging/#visual-studio-code-vscode-debugging-setup

[Raidri]

Your workaround doesn't work for me. I have to delete the line with host.docker.internal from the hosts file inside the ddev web container. Then xdebug works. But after every restart ddev set the entry again in the /etc/hosts file. For me it would help If ddev would not set the host.docker.internal entry:)

[rfay]

@Raidri you have a completely different issue right? You're not using vscode language server, you have your IDE running on the host on Windows, right? You already have a separate issue going on #3772 right?

[Raidri]

@rfay you are right. I use PHPStorm on Windows and yes I've an other open issue but MurzNN meant I should take a look in this issue cause he could have a workaround which could help me too. But yeah, didn't read that he is using vs code server. Sorry.

[MurzNN]

I'd love to know why you're using the vscode language server inside the container, how it works for you, and your overall experience. And if it has great benefit, it would be wonderful to have a writeup on it somewhere.

@rfay I've started describing briefly the benefits here https://murz.notion.site/VS-Code-IDE-inside-Docker-container-fe31affafff747cdac8382167f3a03d9 - will post it on my blog when finished.

[rfay]

Thanks - Looking forward to it. Please do a PR to add to https://github.com/drud/awesome-ddev when you do the blog.

Since this is completely different from every other usage (and depends on the IDE, not ddev's config) we'll have to figure out how config can be done in the future.

[MurzNN]

Please do a PR to add to https://github.com/drud/awesome-ddev when you do the blog.

Better late than never! 😜 Here it is: ddev/awesome-ddev#22

[rfay]

Thanks!

[rfay]

With #4242 which just went in, you should be able to do this without workarounds now. ddev config global --xdebug-ide-location=container if you're running vscode language server.

You can use this latest version with brew install --HEAD --fetch-head ddev or several other ways.

[MurzNN]

ddev config global --xdebug-ide-location=container

Yeah, this works - thanks!