Docker Community Forums

Share and learn in the Docker community.

[Solved] Cannot connect phpstorm debugger to container running php

beta

(Jonnie) #1

I have a docker-compose file which mounts a folder containing my client and server projects:

 volumes:
    - ~/projectx:/projectx

my docker php.ini contains the following xdebug options

[xdebug]
xdebug.remote_enable=1
xdebug.remote_port=9000
xdebug.remote_connect_back=On
xdebug.var_display_max_children = 999
xdebug.var_display_max_data = 999
xdebug.var_display_max_depth = 100
I have the xdebug chrome extension installed

In my mac host file I have the following 127.0.0.1 localhost dtest.xxx.com so I can access my web app (and other docker web apps) through dtest.xxx.com which all works to run the app

In Phpstorm (version 2016.1.2) In preferences -> Languages & Frameworks -> PHP -> Servers I have :

host = dtest.xxx.com, 
port=80 ,
Debugger = Xdebug 
Use path mappings is checked and I have
      File/Directory set to /Users/<myname>/projectx/server
      Absolute path on the server is set to /projectx/server

I have tried setting the xdebug.remote_host to my macs ip obtained from ifconfig as well as trying the ip in /Users//Library/Containers/com.docker.docker/Data/database/com.docker.driver.amd64-linux/slirp/host

But I cannot hit a breakpoint , I have even added xdebug_break() to double check.

I would very much appreciate anyone’s help, it’s a real blocker for me.

If any further information is required I am happy to provide.

Information

The output of Diagnose & Feedback` on OSX:

Docker for Mac: version: mac-v1.12.0-beta18-3-gec40b14
OS X: version 10.11.5 (build: 15F34)
logs: /tmp/20160707-154924.tar.gz
[OK]     docker-cli
[OK]     app
[OK]     menubar
[OK]     virtualization
[OK]     system
[OK]     osxfs
[OK]     db
[OK]     slirp
[OK]     moby-console
[OK]     logs
[OK]     vmnetd
[OK]     env
[OK]     moby
[OK]     driver.amd64-linux

This was also posted on stackoverflow


(Jonnie) #2

This was resolved thanks to IP address for xdebug


(Amccabe) #3

I was also able to get my container to connect to PhpStorm with the linked thread, however I’m having trouble getting another container (linked to the one that works) to pause at break-points. If I need to make a new ticket, someone please let me know.

I’m using docker-compose to bring up both containers, one “talks” to the other (the former is the app, the latter is the api). The app is able to stop at break points and I can step through them in files contained within that mounted directory, but the files in the directory (mounted by api container) do not trigger break points in PhpStorm.

Currently I am using a start script to kick off the docker-compose up command, which updates the YAML file with the proper IP for Xdebug (using the trick referenced in the issue linked above), a la:
XDEBUG_HOST_IP=$(cat ~/Library/Containers/com.docker.docker/Data/database/com.docker.driver.amd64-linux/slirp/host)
sed -e “s/XDEBUGHOSTIP/${XDEBUG_HOST_IP}/g” docker-compose.tpl > docker-compose.yml

The dockerfiles update the php.ini to use Xdebug and the imported XDEBUG_HOST_IP value, and I can confirm that both containers are loading that configuration. It’s just that the app container can trigger the break, but not the api container.

The mounted directories for both containers share a root path:

├── root_dir:api_root_dir
│   ├── shared_models
│   ├── app_dir:app_root_dir

So the api container (the one that does not pause at break points in PhpStorm debugging) mounts one directory up the path from the app container, so maybe this has something to do with it.

I’ve also found that at some point, Xdebug logs were generated on the api container, despite no evidence of it on the PhpStorm end:
<- breakpoint_set -i 11 -t line -f file:///var/www/api/… -n 46
->
<- breakpoint_set -i 12 -t line -f file:///var/www/api/app/… -n 70
->

Notice the first breakpoint_set is detecting a break point in the api path: root_dir/…, and the second breakpoint_set (unexpectedly at first) is detecting a break point in the app code.