In this part of the tutorial series on developing PHP on Docker we will set up our local development environment to be used by PhpStorm and Xdebug. We will also ensure that we can run PHPUnit tests from the command line as well as from PhpStorm and throw the tool 1 into the mix for debugging long-running processes. Show All code samples are publicly available in my Docker PHP Tutorial repository on Github. All published parts of the Docker PHP Tutorial are collected under a dedicated page at Docker PHP Tutorial. The previous part was Docker from scratch for PHP 8.1 Applications in 2022 and the following one is Run Laravel 9 on Docker in 2022. If you want to follow along, please subscribe to the RSS feed or to get automatic notifications when the next part comes out :) Table of contentsIntroductionThis article is mostly an update of Setting up PhpStorm with Xdebug for local development on Docker but will also cover the "remaining cases" of debugging php-fpm and php worker processes. We will still rely on an always-running docker setup that we connect to via an SSH Configuration instead of using the as I feel it's closer to what we do in CI / production. However, we will not use SSH keys any longer but simply authenticate via password. This reduces complexity and removes any pesky warnings regarding "SSH keys being exposed in a repository". Install ToolsInstall composerComposer is installed by pulling the official composer docker image and simply "copying" the composer executable over to the base php image. In addition, composer needs the extensions 2 and 3
Because we want our build to be deterministic, we "pin" the composer version by adding a 4 variable to the 5 file
and using it in 6:
Install XdebugInstall the extension via 7 (only for the 8 target):
We also don't want to enable 9 immediately but only when we need it (due to the decrease in performance when the extension is enabled), hence we remove the default config file and disable the extension in the application 0 file
See for an explanation of the 1 setting (previously called 2 in xdebug < 3). This will still work out of the box for Docker Desktop, but for Linux users we need to add the to all PHP containers (we can't add it to the php base image because this is a runtime setting):
Finally, we need to add the environment variable 4 to all PHP containers. The variable is defined as 5, where "dofroscra" is the name of the server that we will configure later for debugging. Because we need the same value in multiple places, the variable is configured in 5:
And then added in 7
Install PHPUnitPHPUnit will be installed via 8 but will not be "baked into the image" for local development. Thus, we must run 9 in the container. To make this more convenient a make target for running arbitrary composer commands is added in 0:
This allows me to run 1 from the host system to execute 2 in the container. In consequence, 8 will use the PHP version and extensions of the 4 container to install the dependencies, yet I will still see the installed files locally because the codebase is configured as a volume for the container.Before installing phpunit, we must add the required extensions 5 and 6 to the container
as well as rebuild and restart the docker setup via 0Now we can add phpunit via 1which will create a 7 file and setup up the 8 directory: 2CAUTION: If you run into the following permission error at this step, you are likely using Linux and haven't set the 9 and 0 variables as described in the previous article under . 3I have also added
4So I can run tests simply via 4 5Install SSHWe will execute commands from PhpStorm via ssh in the 4 container. As mentioned, we won't use a key file for authentication but will instead simply use a password that is configured via the 6 variable in 5 and passed to the image in 7. In addition, we map port 9 from the host system to port 0 of the application container and make sure that the codebase is shared as a volume between host and container 6The container already contains 1 and sets the password 7Setup PhpStormWe will configure a remote PHP interpreter that uses an SSH connection to run commands in the 4 container. Before, , which was kinda confusing ("What is SFTP doing here?"), so we will use an SSH Configuration instead and configure the path mappings in the Cli Interpreter interfaceSSH ConfigurationAt 4 create a new SSH Configuration named "Docker PHP Tutorial" with the following settings
PHP InterpreterAt 1 add a new PHP CLI interpreter that uses the new SSH ConfigurationIn addition, we define the path to the xdebug extension because it is disabled by default but PhpStorm can enable it automatically if required. You can find the path in the 4 container via 8We still need to by adding a custom PHP option for 1. That's the same value we use in 4.In the interpreter overview we must now configure the path mappings so that PhpStorm knows "which local file belongs to which remote one". The remote folder is defined in 5 via 9Afterwards we can set a breakpoint e.g. in 6 and start debugging:The screenshot shows that PhpStorm adds the Xdebug extension that we defined previously. PHPUnit 7 is configured via 8. First, we select the interpreter that we just addedThen, we add the paths to the composer autoload script and the 1 configuration file.PhpStorm will now execute tests using the PHP interpreter in the 4 containerDebuggingFirst of all, if you haven't already please also take a look at the official xdebug documentation. Derick is doing a great job at explaining xdebug in detail including some helpful videos like Xdebug 3: Xdebug with Docker and PhpStorm in 5 minutes Debug code executed via PhpStormThis should already work out of the box. Simply set a break point, right-click on a file and choose "Debug '...'" Debug code executed via php-fpm, cli or from a workerFor code that is executed "directly" by a container without PhpStorm, we first need to enable 9 in the container by removing the 2 in front of the extension in 3 0To make this a little more convenient, we use dedicated make recipes for those actions in 4 1To capture incoming requests, we need to make PhpStorm listen for PHP Debug connections via 5.The corresponding ports are configured at 6. In Xdebug < 3 the default port was 7 and in Finally, we need to add a server via 9The name of the server must match the value of the 00 key in the environment variable 4 that we configured previously as 02.php-fpmFor 03 we must restart the 03 process without restarting the container after we have activated 9 via 2Since this is a pain to remember, we add a make target in 4 3So we can now simply run 4Setting a breakpoint in 07 and opening http://127.0.0.1/ in a browser or via 08 will halt the execution as expected.cliInstead of triggering a PHP script via HTTP request, we can also run CLI scripts - think of the 09 target for instance. To debug such invocations, we need to follow the same steps as before:
Running the following make targets will trigger a breakpoint in 6: 5php-workersAnd finally the same thing for long running PHP processes (aka workers). Just as before:
Running the following make targets will trigger a breakpoint in 15: 6stracestrace is a great tool for debugging long running processes that I've adopted after reading What is PHP doing?. I've added it to the php base image: 7You can attach to any running process via 16 - BUT that doesn't work out of the box on docker and will fail with the error message 8This is caused by a security measure from docker and can be circumvented by adding 9in 7 to all PHP containers. After rebuilding and restarting the docker setup, you can now e.g. log in the 14 container and run 1 on a php worker process: 0Wrapping upCongratulations, you made it! If some things are not completely clear by now, don't hesitate to leave a comment. Apart from that, you should now have a fully configured development setup that works with PhpStorm as your IDE. In the next part of this tutorial, we will use a fresh installation of Laravel on top of our setup. Please subscribe to the RSS feed or to get automatic notifications when this next part comes out :) Wanna stay in touch?Since you ended up on this blog, chances are pretty high that you're into Software Development (probably PHP, Laravel, Docker or Google Big Query) and I'm a big fan of feedback and networking. So - if you'd like to stay in touch, feel free to shoot me an email with a couple of words about yourself and/or connect with me on LinkedIn or Twitter or simply subscribe to my RSS feed or go the crazy route and subscribe via mail and don't forget to leave a comment :) Subscribe to posts via mailEmail Address First Name We use Mailchimp as our newsletter provider. By clicking subscribe, you acknowledge that your information will be transferred to Mailchimp for processing. Learn more about Mailchimp's privacy practices here. |