Improve xdebug support with "host.docker.internal" hostname

[rfay]

What happened (or feature request):

Docker 18.03+ now supports the hostname "host.docker.internal" to reach the host, which means we'll no longer have to have people add a special network interface IP (172.28.99.99) to use xdebug.

Also, we may be able to use remote.connect_back depending on how docker has implemented networking in Edge. But probably we don't even have to do that, because we can use the magic hostname.

What you expected to happen:

How to reproduce this:

Version: Please include the output of ddev version, docker version and the project's .ddev/config.yaml.

Anything else do we need to know:

Related source links or issues:

Please use a complexity rating of 1-5 (5 is high) for a feature request. (High complexity implies more PR planning)

[rfay]

With Docker Edge, the short-term approach is simple: The project's .ddev/php/xdebug.ini can contain

[xdebug]
xdebug.remote_host = host.docker.internal

I don't believe that "host.docker.internal" is supported in Stable yet, but it will probably land there with the next quarterly release, as soon as the end of March, 2018.

There's a problem with this though on Windows, starting with Docker for Windows 18.03.0-ce-rc3-win56, ddev is completely broken by Edge, see #739

[snpdev]

@rfay, thanks for the information. I'll try an older version of Docker for Windows edge and report back.

[snpdev]

I reinstalled Docker for Windows using version 18.03.0-ce-rc1-win54 (16164) edge, and configured xdebug.ini per #736 (comment).

Debugging with Visual Studio Code is still not working :>(

See Figure 1 for my debug configuration in launch.json .

See Figure 2 for xdebug settings in admin/reports/status/php.

(FWIW, I confirmed that xdebug does work for local development outside ddev).

Figure 1

 { 
        "name": "Listen for XDebug",
        "type": "php", 
        "request": "launch", 
        "port": 11011, 
        "pathMappings": {
          "/var/www/html": "c:/Work/source/drupal7"
          //"localSourceRoot": "${workspaceRoot}",
          //"serverSourceRoot": "/var/www/html"
          },
          "xdebugSettings": {
            "show_hidden": 1
          } 
      }

Figure 2

Directive	Local Value	Master Value
xdebug.auto_trace	Off	Off
xdebug.cli_color	0	0
xdebug.collect_assignments	Off	Off
xdebug.collect_includes	On	On
xdebug.collect_params	0	0
xdebug.collect_return	Off	Off
xdebug.collect_vars	Off	Off
xdebug.coverage_enable	On	On
xdebug.default_enable	On	On
xdebug.dump.COOKIE	no value	no value
xdebug.dump.ENV	no value	no value
xdebug.dump.FILES	no value	no value
xdebug.dump.GET	no value	no value
xdebug.dump.POST	no value	no value
xdebug.dump.REQUEST	no value	no value
xdebug.dump.SERVER	no value	no value
xdebug.dump.SESSION	no value	no value
xdebug.dump_globals	On	On
xdebug.dump_once	On	On
xdebug.dump_undefined	Off	Off
xdebug.extended_info	On	On
xdebug.file_link_format	no value	no value
xdebug.filename_format	no value	no value
xdebug.force_display_errors	Off	Off
xdebug.force_error_reporting	0	0
xdebug.gc_stats_enable	Off	Off
xdebug.gc_stats_output_dir	/tmp	/tmp
xdebug.gc_stats_output_name	gcstats.%p	gcstats.%p
xdebug.halt_level	0	0
xdebug.idekey	no value	no value
xdebug.max_nesting_level	512	512
xdebug.max_stack_frames	-1	-1
xdebug.overload_var_dump	2	2
xdebug.profiler_aggregate	Off	Off
xdebug.profiler_append	Off	Off
xdebug.profiler_enable	Off	Off
xdebug.profiler_enable_trigger	Off	Off
xdebug.profiler_enable_trigger_value	no value	no value
xdebug.profiler_output_dir	/tmp	/tmp
xdebug.profiler_output_name	cachegrind.out.%p	cachegrind.out.%p
xdebug.remote_addr_header	no value	no value
xdebug.remote_autostart	Off	Off
xdebug.remote_connect_back	Off	Off
xdebug.remote_cookie_expire_time	3600	3600
xdebug.remote_enable	On	On
xdebug.remote_handler	dbgp	dbgp
xdebug.remote_host	host.docker.internal	host.docker.internal
xdebug.remote_log	no value	no value
xdebug.remote_mode	req	req
xdebug.remote_port	11011	11011
xdebug.remote_timeout	200	200
xdebug.scream	Off	Off
xdebug.show_error_trace	Off	Off
xdebug.show_exception_trace	Off	Off
xdebug.show_local_vars	Off	Off
xdebug.show_mem_delta	Off	Off
xdebug.trace_enable_trigger	Off	Off
xdebug.trace_enable_trigger_value	no value	no value
xdebug.trace_format	0	0
xdebug.trace_options	0	0
xdebug.trace_output_dir	/tmp	/tmp
xdebug.trace_output_name	trace.%c	trace.%c
xdebug.var_display_max_children	128	128
xdebug.var_display_max_data	512	512
xdebug.var_display_max_depth	3	3

[rfay]

Have you confirmed that your editor is listening on port 11011? You should be able to connect to it via tcp.

[rfay]

I should have mentioned that your Windows firewall settings can definitely blow this up - try making them very easy (allow temporarily from everywhere).

From within the container (ddev ssh) you should be able to netcat host.docker.internal 11011 and it should connect, it should not say netcat: unable to connect to address host.docker.internal, service 11011. You can also use netcat or telnet on the host to do this debugging, netcat localhost 11011, telnet localhost 11011. Neither netcat nor telnet come with Windows so you'll need to figure out a way to do the equivalent.

[snpdev]

@rfay , just a note to let you know I'm working on it.

Port 11011 is declarative in launch.json.

telnet localhost 11011 opens a blank telnet window.

I have added "log": true, to launch.json and specified xdebug.remote_log = "/var/www/ddevlog.txt" in xdebug.ini.

Firewall is turned off, temporarily.

On starting the debugger, the output of the Debug Console is:

Response {
  seq: 0,
  type: 'response',
  request_seq: 2,
  command: 'launch',
  success: true }

Program does not stop at breakpoints, and no xdebug log is written.

[snpdev]

P.S. Thanks for your attention to this issue. I'm sure you have lots of other fish to fry :>)

[rfay]

This is definitely important to solve. Sorry to say I don't have enough Windows resources to test it adequately, but hope to get that sorted out soon.

[rfay]

I confirm that this works fine in Windows 10 Pro, ddev v0.15.1, Docker 18.03.0-ce-rc1-win54 (later RCs are completely broken for other reasons). The approach in #736 (comment) works perfectly with PHPStorm. I did have to tell Windows at each step to allow the network access. But I was able to test as suggested with netcat host.docker.internal 11011 from within the web container (ddev ssh) and it connected.

The basic questions are:

• Is xdebug enabled? Look at any phpinfo you want; in Drupal admin/reports/status/php gives all the info.
• Is your IDE listening on 11011 (use netcat or telnet or the tool of your choice)
• Is host.docker.internal port 11011 accessible from within the container (Use netcat or telnet from within the container)

Please note that with this week's release (probably late this week) we'll be switching to xdebug off by default for performance reasons, so you'll need to pay attention to that.

[rfay]

Now that 18.03 is the stable Docker version we can implement this.

[rfay]

Added this to v0.18.0. Mostly all we have to do is a minor change to the php config and a massive simplification of the docs. No more setting IP addresses.