[SOLVED] How to setup phpStorm + xDebug + Docker in Windows?

Answered

Hi, I have been struggling for the last two hours with phpStorm + xDebug + Docker in Windows 10 and I am not able to make the debugging to work. I am running the following software version:

  • PhpStorm 2017.2.2 EAP
  • Windows 10.0.15063.0
  • Docker CE Edge 17.07.0-ce-rc1-win21 (12927)

I have setup the IDE as follow:

In addition I should say I have ESET Smart Security installed but I think it's properly setup as per this images:

I have read this and this once and again trying to figure it out why the debugger is not working but again without success so I am out of ideas. Can I get any help?

 

13 comments
Comment actions Permalink

Hi there,

1) What xdebug log has to say about it?

2) What IP:port it tries to connect to? Are they correct?

I know that SSH is not what meant to be installed inside Docker container .. so you cannot easily login into container and do some telnet test (to connect from remote to IDE) ... but maybe you can use some another tool (e.g. calling telnet or similar tool from PHP script) .. or even establishing connection with PHP itself (e.g. https://www.geckotribe.com/php-telnet/ or using few PHP's own functions like fsockopen() etc)?

This is to test if you can connect from Docker image to the xdebug listener in IDE -- to confirm that it's not a firewall issue -- be it your ESET or Docker one. Obviously, it means that "phone handle" icon in PhpStorm must be activated or IDE is already listening for incoming xdebug connections.

0
Comment actions Permalink

Hi @Andriy,

 

  1. Do you mean xDebug logs at server level? I do not have them enabled, should I?
  2. I am not sure about how to answer this question, could you give me an example of what are you asking here?

I can give a try to telnet, I will have to do it later tonight. What I can say is the same setup did works in Linux, the only difference is I don't have any AV or FW setup. 

0
Comment actions Permalink

1) Yes -- https://xdebug.org/docs/all_settings#remote_log

2) That's will be shown in that log

My idea is to see what xdebug is doing there: where it tries to connect .. and if it connects -- how it behaves.

If the IP:port are 100% correct but not connecting -- then it might be a firewall .. or IDE is not listening (which you may check with netstat or alike -- who listens on TCP 9001 -- must be PhpStorm)

If it connects but response is weird -- maybe it connects to the wrong IP:port (e.g. connects to some another service which knows nothing about xdebug)

But overall -- allow full access for PhpStorm in firewall ... and maybe even consider disabling firewall completely while making these tests.

For debugging to work the xdebug connection from Docker container must reach PhpStorm running on your Windows host on TCP 9001 port (as per your settings).

0
Comment actions Permalink

> If the IP:port are 100% correct but not connecting -- then it might be a firewall .. or IDE is not listening (which you may check with netstat or alike -- who listens on TCP 9001 -- must be PhpStorm)

 

Well apparently phpStorm is not listening on port 9001. Take a look to the following test using netstat in Powershell:


PS F:\Development\applications\sources> NETSTAT.EXE

Active Connections

Proto Local Address Foreign Address State
TCP 10.0.75.1:445 10.0.75.2:59222 ESTABLISHED
TCP 10.108.108.90:49289 ec2-34-224-17-207:https ESTABLISHED
TCP 10.108.108.90:49310 server18105:5938 ESTABLISHED
TCP 10.108.108.90:50018 ad:https ESTABLISHED
TCP 10.108.108.90:50116 mia07s49-in-f10:https CLOSE_WAIT
TCP 10.108.108.90:50190 ec2-54-152-3-228:https ESTABLISHED
TCP 10.108.108.90:50193 ec2-54-152-3-228:https ESTABLISHED
TCP 10.108.108.90:50195 ec2-54-165-118-242:https ESTABLISHED
TCP 10.108.108.90:50196 ec2-54-227-194-207:https ESTABLISHED
TCP 10.108.108.90:50200 yw-in-f125:5222 ESTABLISHED
TCP 10.108.108.90:50208 ec2-54-145-17-47:https ESTABLISHED
TCP 10.108.108.90:50228 li1309-23:https ESTABLISHED
TCP 10.108.108.90:50261 li1297-112:https ESTABLISHED
TCP 10.108.108.90:52968 mia07s48-in-f5:https ESTABLISHED
TCP 10.108.108.90:54254 vs-in-f188:https ESTABLISHED
TCP 10.108.108.90:54613 lb-192-30-253-125-iad:https ESTABLISHED
TCP 10.108.108.90:55926 mia07s48-in-f14:https CLOSE_WAIT
TCP 10.108.108.90:56861 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56862 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56863 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56866 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56867 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56868 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56869 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56870 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56871 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56872 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56873 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56875 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56876 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56877 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56878 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56893 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56894 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56895 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56896 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56897 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56898 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:56935 lb-192-30-253-125-iad:https ESTABLISHED
TCP 10.108.108.90:56942 151.101.56.133:https ESTABLISHED
TCP 10.108.108.90:57022 151.101.193.69:http ESTABLISHED
TCP 10.108.108.90:57023 151.101.193.69:http TIME_WAIT
TCP 10.108.108.90:57024 40.117.96.104:https ESTABLISHED
TCP 10.108.108.90:57027 a23-202-87-203:https ESTABLISHED
TCP 10.108.108.90:57030 104.16.108.18:https ESTABLISHED
TCP 10.108.108.90:57033 104.16.108.18:https ESTABLISHED
TCP 10.108.108.90:57036 104.16.3.9:https ESTABLISHED
TCP 10.108.108.90:57038 a23-202-87-203:https TIME_WAIT
TCP 10.108.108.90:57039 a23-202-87-203:https TIME_WAIT
TCP 10.108.108.90:57040 151.101.65.69:https ESTABLISHED
TCP 10.108.108.90:57041 104.16.108.18:https TIME_WAIT
TCP 10.108.108.90:57042 104.16.108.18:https TIME_WAIT
TCP 10.108.108.90:57043 104.16.108.18:https TIME_WAIT
TCP 10.108.108.90:57045 104.16.108.18:https TIME_WAIT
TCP 10.108.108.90:57047 104.16.108.18:https TIME_WAIT
TCP 10.108.108.90:57052 104.16.108.18:https TIME_WAIT
TCP 10.108.108.90:57053 104.16.3.9:https TIME_WAIT
TCP 10.108.108.90:57054 104.16.3.9:https TIME_WAIT
TCP 10.108.108.90:57055 104.16.3.9:https TIME_WAIT
TCP 10.108.108.90:57056 a23-202-87-203:https TIME_WAIT
TCP 10.108.108.90:57057 151.101.65.69:https TIME_WAIT
TCP 10.108.108.90:57064 151.101.65.69:https TIME_WAIT
TCP 10.108.108.90:57065 151.101.65.69:https TIME_WAIT
TCP 10.108.108.90:57066 151.101.65.69:https TIME_WAIT
TCP 10.108.108.90:57067 151.101.65.69:https TIME_WAIT
TCP 10.108.108.90:57068 151.101.65.69:https TIME_WAIT
TCP 10.108.108.90:57069 151.101.193.69:https TIME_WAIT
TCP 10.108.108.90:57073 ec2-54-243-104-69:https TIME_WAIT
TCP 10.108.108.90:57074 ec2-54-243-104-69:https TIME_WAIT
TCP 10.108.108.90:57075 ec2-54-243-104-69:https TIME_WAIT
TCP 10.108.108.90:57076 ec2-54-243-104-69:https TIME_WAIT
PS F:\Development\applications\sources>

Connection from Docker to the host is established but even if I restart the IDE and click several times on the little green icon (see below) I can't see any active connection on port 9001. I've checked AV logs and nothing is being logged under FW

0
Comment actions Permalink

Please use "netstat -a -n -b"

This is how PhpStorm is shown here (listens on ALL IPs on TCP 9000):

 TCP    0.0.0.0:9000           0.0.0.0:0              LISTENING
[phpstorm64.exe]                                              

 

0
Comment actions Permalink

Here it's:

TCP 0.0.0.0:9001 0.0.0.0:0 LISTENING
[phpstorm64.exe]
TCP 0.0.0.0:10137 0.0.0.0:0 LISTENING
[phpstorm64.exe]
TCP 0.0.0.0:15001 0.0.0.0:0 LISTENING
[SideSync.exe]
TCP 0.0.0.0:20080 0.0.0.0:0 LISTENING
[phpstorm64.exe]
TCP 0.0.0.0:27017 0.0.0.0:0 LISTENING

I think is listening properly, what would be the next step, xDebug logs?

0
Comment actions Permalink

Yes -- it shows that PhpStorm listens locally.

Now you need to collect xdebug log and see what's happening there. If IP:port is correct (how do you know that?) -- look into firewall (be it Windows one or ESET).

Just in case: the IP must be an IP where PhpStorm is running and it should be one as seen from remote (from inside that Docker container). The easiest thing to check is to do what xdebug tries to do (when it's configured with xdebug.remote_connect_back = 1) -- check $_SERVER['REMOTE_ADDR'] or similar field.

0
Comment actions Permalink

Hi, I have enabled the logs as suggested and I can read the following:

Log opened at 2017-08-11 00:12:53
I: Checking remote connect back address.
I: Checking header 'HTTP_X_FORWARDED_FOR'.
I: Checking header 'REMOTE_ADDR'.
I: Remote address found, connecting to 172.18.0.1:9001.
W: Creating socket for '172.18.0.1:9001', poll success, but error: Operation now in progress (29).
E: Could not connect to client. :-(
Log closed at 2017-08-11 00:12:53

I have disabled the FW and however I can't debug:

The Windows FW is managed by ESET SS so it's disabled as well.

Any ideas?

 

 

0
Comment actions Permalink

Please check this thread: https://github.com/laradock/laradock/issues/460.

Not exactly the same software but discussion might help.

0
Comment actions Permalink

Hi,

 

I've found the solution but still don't know how or why. The xDebug configuration for Linux looks like:

[Xdebug]
xdebug.remote_enable = true
xdebug.remote_port = "9001"
xdebug.remote_connect_back = 0
xdebug.idekey = "PHPSTORM"
xdebug.remote_autostart = true
xdebug.remote_log = "/var/www/html/oneview_symfony/var/logs/xdebug.log

For Windows I'd to change into:

[Xdebug]
xdebug.remote_enable = true
xdebug.remote_port = "9001"
xdebug.remote_connect_back = 0
xdebug.idekey = "PHPSTORM"
xdebug.remote_autostart = off
xdebug.remote_log = "/var/www/html/oneview_symfony/var/logs/xdebug.log"
xdebug.cli_color = 1
xdebug.remote_host = 192.168.1.102 // host IP address

Still don't get it why. I did found the solution here. Also the FW in this case is enabled so the problem wasn't the firewall at all.

0
Comment actions Permalink

OK .. so the IP that xdebug detects is actually wrong -- outgoing connection is not getting out of the Docker container .. so you have to manually specify your real host IP address which then gets routed fine (outgoing connection gets out of the container).

I think (but could be completely wrong here) that it might be some misconfiguration (or a bug) at Docker's network subsystem .. because as per my knowledge container should not need to know the real host IP inside the running container -- such "network address translation" should be happening at higher (Docker) level. .. otherwise it means that you need to alter container config on each dev machine...

Anyway it's a working solution -- thanks for sharing -- will be useful for other in similar situation.

1
Comment actions Permalink

AFAIK, remote_connect_back will work when using the legacy docker app for Windows (Docker Toolbox). Just something to keep in mind

0
Comment actions Permalink

In newer versions of Docker (> 18.03) there is a DNS entry named host.docker.internal that will resolve to your host system. Thus, you can replace

xdebug.remote_host = 192.168.1.102 // host IP address

by

xdebug.remote_host = host.docker.internal // host IP address

making it much more versatile. In addition, for CLI scripts PhpStorm will set the remote_host via command line option. This can be resolved by overriding that option:

---

Open File | Settings | Languages & Frameworks | PHP and click on the "..." next to "PHP Interpreter" to bring up the interpreters. Choose [your interpreter] in the left pane and click on the little folder icon on the bottom of the window next to "Configuration options". In the pop up enter xdebug.remote_host as key and host.docker.internal as value and hit "OK".

---

via https://www.pascallandau.com/blog/setup-phpstorm-with-xdebug-on-docker/#fix-xdebug-on-phpstorm-when-run-from-a-docker-container

1

Please sign in to leave a comment.