Basically containers are able to reach other containers by their name, given they’re mutually reachable on their network.īy default, Docker uses a bridge network mode, refer to the documentation if you want more details on that but the important part is the gateway of these networks. To establish these containers connections, Docker internally creates networks on your machine, and also gives some superpowers to your DNS resolution. When you work with containers, it’s a common need to establish connections between containers, but not to the host. This is where understanding a bit of Docker networking comes useful. So we need to establish a connection from inside this Docker container to our host, which is quite unusual. Now inside Docker, that’s not the case anymore, the Xdebug server is still on the same localhost, this is our IDE, but the application server - the XDebug client - is located inside a container, and localhost will of course resolve to the container itself from inside the container. Makes sense? Alright, so when we work outside of Docker, that’s really transparent as those two parts will usually be located on the same network address: 127.0.0.1, aka localhost. So your local machine, actually your IDE, will be the server part of Xdebug in this scenario. When a user - you - initiate a request and Xdebug is ON, it will need to establish a connection somewhere, usually back to the request initiator. So, how does Xdebug work? Basically, what we installed in the image is a PHP extension, it is the client part of XDebug.
The solution is actually pretty straight forward, but that’s an interesting part to understand. The tricky part actually comes here, we have to understand how Xdebug works, and how Docker networking works. Now to the configuration, it’s not going to work out of the box. $ docker-compose up -d -build $ docker-compose exec app php -v PHP 8.1.6 (cli) (built: 08:14:41) (NTS) Copyright (c) The PHP Group Zend Engine v4.1.6, Copyright (c) Zend Technologies with Xdebug v3.1.4, Copyright (c) 2002-2022, by Derick Rethans I am using docker-compose here for the sake of simplicity, but you can adapt this to a standalone docker run, just don’t forget to rebuild the container.
#PHPSTORM XDEBUG INSTALL#
I’m using to install the PHP extension, feel free to install it with your preferred method, but if you don’t know this installer you should definitely take a look at it! Now let’s add Xdebug inthere COPY -from=mlocati /php-extension-installer /usr /bin /install-php-extensions /usr /bin / RUN install-php-extensions xdebug It is missing quite a few things to make our app actually work, but I’m only showing the relevant parts. FROM php:8.1 -apache WORKDIR /var /www /html So, let’s consider this simple Dockerfile as our base. I’ll use a very simple Dockerfile to showcase, but you might have to adapt this to your actual stack. In VSCode you'll need to install the PHP Debug extension, configre it, and then you should be able to set breakpoints in your code.īe sure to enable the helper and listener in your IDE.Alright, first things first, Xdebug needs to be installed in the Docker image you use. If you are using PhpStorm, setting up Xdebug is straightforward. In Chrome it's Xdebug helper, in FF it's Xdebug helper for Firefox. In order to debug the web application, you'll need a browser extension.
You can use Xdebug to debug your CLI scripts (tests for instance), or debug your web application. To prevent this, just make sure you delete it every once in a while, or simply don't enable logging. Possible side effectsĪ possible side effect of running Xdebug, especially if you enable profiler output in Xdebug settings in php.ini, is that the file can grow very large. Now you can install Xdebug again, and it should work as described in the previous case (follow the steps described above to add it correctly into your php.ini).
0 kommentar(er)
