Docker Container Debugging

After learning about Docker compose and creating more complex environments, we looked at using Docker to set up a WordPress environment in our last article. A WordPress environment is made up of two containers. The first is the machine that runs the server with PHP files, and the second is the machine that runs MySQL. These two components work together and are synchronized by Docker compose. These two will remain ‘alive’ forever even if we take down the containers since we connected them to the host computer using:

  # Keep your data
   volumes: 
     - ./site:/var/www/html/

We covered all of this in the last article so check it out if you need a review. But sometimes there’s a problem with looking at examples. Everything seems so easy and runs smooth, but then when you try it yourself, bam! Some kind of issue pops up from God knows where. You try going to the WordPress site, or some other system just to discover a dreaded error screen: 

Well, issues are bound to pop up here and there. Often, a good ol’ restart of the host computer will fix it. But if it doesn’t we’ll need to do a little debugging. The container’s log, as we see in the terminal, may shed some light on things, but certainly not always. So once you’ve exhausted those two options, there’s really only one thing left to do: go into the container and check for problems.

If you’ve got a WordPress error on your hands, it makes sense to assume that you’ll need to check the WordPress container. So how do we go into a container that is running?

First, open an additional docker CLI in the same place that docker compose is running. Then, in order to go into the container, type:

docker-compose exec wordpress bash

Once this command has been run, we’re in a container that’s running in docker.compose. We’re not in Windows or the host system but rather inside Linux. So now we need to ‘talk’ to Linux, which isn’t so complicated. First, we’ll install nano, a Linux text editor.

apt-get update && apt-get install nano

Since we are root right now, there’s no need for sudo.

This is the stage where we need to make a php.ini file in which there are instructions for creating and printing an error log. We’ll go into where it’s supposed to be:

cd /usr/local/etc/php

We’ll create and edit the file using:

nano php.ini

Then put the following text inside the file:

log_errors = On
error_log = /tmp/error.log

The next thing is to make the log file tmp/error.log/ which we’ll do using:

touch /tmp/error.log && chmod 777 /tmp/error.log

And that’s about it! Now just restart the server, which we need to do since we made changes to the php.ini file.

/etc/init.d/apache2 restart

Once we run this we exit the machine. To get back in we run:

docker-compose exec wordpress bash

And now, in order to see the PHP error log, simply run:

tail -f /tmp/error.log

And that about does it. From this point on, you’ll see all the errors on the screen.

Of course, it’s possible to do whatever we want in this or any other machine. The main point of the article is not just to check for PHP errors but also to see just how easy it is to get inside Docker containers even with compose, and do what we need to do.

About the author: Ran Bar-Zik is an experienced web developer whose personal blog, Internet Israel, features articles and guides on Node.js, MongoDB, Git, SASS, jQuery, HTML 5, MySQL, and more. Translation of the original article by Aaron Raizen.