5

I'm basically using this configuration to create the development environment for a Symfony project https://github.com/maxpou/docker-symfony. It runs but I can't get Xdebug to work: it doesn't stop when I set a breakpoint.

I also tried to configure Xdebug to use connect_back but that doesn't work. Maybe it's related to the fact that I'm developing on a Windows machine? Any insights are much appreciated.

Dockerfile PHP:FPM

# See https://github.com/docker-library/php/blob/master/7.1/fpm/Dockerfile
FROM php:7.1-fpm
ARG TIMEZONE

MAINTAINER Maxence POUTORD <maxence.poutord@gmail.com>

RUN apt-get update && apt-get install -y \
    openssl \
    git \
    unzip

# Install Composer
RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
RUN composer --version

# Set timezone
RUN ln -snf /usr/share/zoneinfo/${TIMEZONE} /etc/localtime && echo ${TIMEZONE} > /etc/timezone
RUN printf '[PHP]\ndate.timezone = "%s"\n', ${TIMEZONE} > /usr/local/etc/php/conf.d/tzone.ini
RUN "date"

# Type docker-php-ext-install to see available extensions
RUN docker-php-ext-install pdo pdo_mysql


# install xdebug
RUN pecl install xdebug
RUN docker-php-ext-enable xdebug
RUN echo "error_reporting = E_ALL" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "display_startup_errors = On" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "display_errors = On" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "xdebug.remote_enable=1" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
#RUN echo "xdebug.remote_connect_back=1" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "xdebug.idekey=\"PHPSTORM\"" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "xdebug.remote_port=9000" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "xdebug.remote_autostart=1" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
# DockerNAT gateway IP
RUN echo "xdebug.remote.host=10.0.75.1" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "xdebug.remote.mode=req" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "xdebug.remote.handler=dbgp" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini


RUN echo 'alias sf="php app/console"' >> ~/.bashrc
RUN echo 'alias sf3="php bin/console"' >> ~/.bashrc

WORKDIR /var/www/free-energy/symfony

docker-compose.yml:

# https://github.com/maxpou/docker-symfony
version: '2'

services:
    db:
        image: mysql
        volumes:
            - "./.data/db:/var/lib/mysql"
        environment:
            MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
            MYSQL_DATABASE: ${MYSQL_DATABASE}
            MYSQL_USER: ${MYSQL_USER}
            MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    php:
        build:
            context: php7-fpm
            args:
                TIMEZONE: ${TIMEZONE}
        volumes:
            - ${SYMFONY_APP_PATH}:/var/www/free-energy/symfony
            - ./logs/symfony:/var/www/free-energy/symfony/app/logs
        environment:
            PHP_IDE_CONFIG: serverName=free-energy.org
    nginx:
        build: nginx
        ports:
            - 80:80
        volumes_from:
            - php
        volumes:
            - ./logs/nginx/:/var/log/nginx
    elk:
        image: willdurand/elk
        ports:
            - 81:80
        volumes:
            - ./elk/logstash:/etc/logstash
            - ./elk/logstash/patterns:/opt/logstash/patterns
        volumes_from:
            - php
            - nginx
progonkpa
  • 3,590
  • 9
  • 31
  • 50
  • 1
    See if this helps http://tarunlalwani.com/post/debugging-php-xdebug-docker/ – Tarun Lalwani Dec 29 '17 at 20:29
  • I got debugging finally working with the help of your tutorial @TarunLalwani. Key xdebug.remote.host is now xdebug.remote_host and the IP now points to my host machine instead of the dockerNat address. I'm very grateful that something works after days. Still, I think after a reboot, my host IP will change adding a manuel step each day. Also in the SSH solution, root@host-ip points to the host IP so that doesn't bail me out :) Any ideas on that? – progonkpa Dec 29 '17 at 21:45
  • 1
    1) *"Xdebug is configured to run on port 9001 because FPM is running on port 9001"* I assume you meant to have 9000 in last one .. otherwise it does not make much sense. 2) Such change makes sense only if on a OS/computer where IDE is running the default xdebug port will already be used (e.g. by php-fpm). Having it inside Docker container only does not really require such change (as xdebug will not be connecting to that IP). – LazyOne Dec 29 '17 at 21:47
  • @LazyOne 1) Your assumption is correct. 2) I tried it out with port 9000 and it indeed also works. This configurations has my preference as it has default values. Thank you – progonkpa Dec 29 '17 at 22:53

2 Answers2

10

Xdebug traffic wasn't finding it's way back to my host. When I entered the IP-address of my host machine in xdebug.remote_host, debugging worked but this was not ideal because my IP changes on every reboot. Luckily, Docker provides a way to obtain the host IP via a DNS-entry docker.for.win.localhost.

Edit:
Docker now has a platform-independent DNS-entry host.docker.internal.

I tried to use xdebug.remote_connect_back=1 which just responds to traffic from where it came but it wasn't working. Phpinfo() showed that REMOTE_ADDR was set to localhost. Localhost in this context points to the Docker PHP-container while it should point to our host IP. Important to know with this setting is that xdebug.remote_host in the .ini will be ignored.

From the Xdebug docs:

xdebug.remote_connect_back Type: boolean, Default value: 0, Introduced in Xdebug >= 2.1

If enabled, the xdebug.remote_host setting is ignored and Xdebug will try to connect to the client that made the HTTP request.

Here is the Dockerfile with the xdebug.ini configuration for the PHP Docker container that worked:

FROM php:7.1-fpm
ARG TIMEZONE

MAINTAINER Maxence POUTORD <maxence.poutord@gmail.com>

RUN apt-get update && apt-get install -y \
    openssl \
    git \
    unzip

# Install Composer
RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
RUN composer --version

# Set timezone
RUN ln -snf /usr/share/zoneinfo/${TIMEZONE} /etc/localtime && echo ${TIMEZONE} > /etc/timezone
RUN printf '[PHP]\ndate.timezone = "%s"\n', ${TIMEZONE} > /usr/local/etc/php/conf.d/tzone.ini
RUN "date"

# Type docker-php-ext-install to see available extensions
RUN docker-php-ext-install pdo pdo_mysql

# install xdebug
RUN pecl install xdebug
RUN docker-php-ext-enable xdebug
RUN echo "zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20160303/xdebug.so" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "error_reporting = E_ALL" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "display_startup_errors = On" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "display_errors = On" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini

# relevant to this answer
RUN echo "xdebug.idekey=\"PHPSTORM\"" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "xdebug.remote_port=9000" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "xdebug.remote_enable=1" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "xdebug.remote_autostart=1" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
RUN echo "xdebug.remote_host=docker.for.win.localhost" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini

RUN echo 'alias sf="php app/console"' >> ~/.bashrc
RUN echo 'alias sf3="php bin/console"' >> ~/.bashrc

WORKDIR /var/www/free-energy/symfony


Edit:
I was messing around with XDebug quite a bit in this post.
Now I know your XDebug config doesn't have to be as big as I had back then.

xdebug.ini: (in your Docker PHP image).

zend_extension=xdebug.so

[Xdebug]
xdebug.remote_enable=true
xdebug.remote_port=9000
xdebug.remote_host=host.docker.internal
progonkpa
  • 3,590
  • 9
  • 31
  • 50
1

Add the remote_connect_back=on, so xdebug connects to the current visitor (using the REMOTE_ADDR system variable) instead of the remote_host which may change. You can try with remote_autostart=on too, to make sure this issue is not related with the browser itself.

Remember to configure the mapping in phpStorm as well, but it will tell you to do so anyway. Also make sure the IDE is listening to the debug session (small toggle in the debug toolbar). Good luck.

Mike Doe
  • 16,349
  • 11
  • 65
  • 88
  • Your suggestion is very interesting. I commented out xdebug.remote_host=10.113.85.60 and added debug.remote_connect_back=1. Unfortunately execution doesn't halt at breakpoints anymore. Maybe another key is breaking it but I checked the Xdebug docs for debug.remote_connect_back and no such thing is stated there. – progonkpa Dec 29 '17 at 23:09
  • `debug.remote_connect_back=1` quite often will not work (wrong IP will be detected), especially if you have more than one container involved (like in this case) – LazyOne Dec 29 '17 at 23:42
  • 1
    Should be xdebug.remote_connect_back. @LazyOne it’s not true, everything should work fine, I have lots of projects like that and xdebug works like a charm. As to the author: drop all settings except the connect_back, port, autostart and remote_remote_enable. Verify settings are applied with phpinfo(). – Mike Doe Dec 30 '17 at 07:23
  • @mike Not sure at all; otherwise I would not see questions and solutions like these https://stackoverflow.com/a/46265103/783119 , https://stackoverflow.com/a/47450391/783119 and similar (tagged [xdebug+phpstorm+docker](https://stackoverflow.com/questions/tagged/xdebug+phpstorm+docker)). From what I saw -- not every docker setup will "report" correct IP for xdebug to pickup -- no concrete ideas on why. – LazyOne Dec 30 '17 at 10:38
  • Solutions from people who don’t know how to configure xdebug. In this configuration the REMOTE_ADDR will report the gateway (your interface in the network) for instance 172.x.x.x/16 which is routable and will connect back to phpStorm. Like I said, I use docker extensively both in production and development and xdebug works always without any problems. – Mike Doe Dec 30 '17 at 11:36