Having messed around with Docker for the web app I’m using with my robot, Sheldon, I decided to dig a little deeper.
Well, that’s probably overstating it. What I actually did was follow along with one of the videos from Traversy Media which explains how to create a Docker container to run a WordPress site. Here it is.
It’s the usual high-quality stuff from that channel – very easy to follow and understand. The only problem was, when it got to the point of firing up the WordPress container, mine didn’t work.
My docker-compose.yaml file was nearly, but not quite, identical to the one in the video. I decided on using port 8001 rather than 8000 and I also used a different name for the network. And I added a container_name setting. Here’s the file:
version: '3'
services:
# Database
db:
image: mysql:5.7
volumes:
- db_data:/var/lib/mysql
restart: always
environment:
MYSQL_ROOT_PASSWORD: myRootPassword
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: userPassword
networks:
- wpnet
# WordPress
wordpress:
depends_on:
- db
image: wordpress:latest
container_name: wp
ports:
- '8001:80'
restart: always
volumes: ['./:/var/www/html']
environment:
WORDPRESS_DB_NAME: wordpress
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: userPassword
networks:
- wpnet
networks:
wpnet:
volumes:
db_data:
This is pretty much straight out of the Docker documentation. Yet, after issuing the docker-compose up -d command and pointing my browser at http://localhost:8001 I got … nothing.
To be more precise, my browser said that the site sent no data and mentioned the ERR_EMPTY_RESPONSE error. It was clear that a web server was running – it just wasn’t talking to me.
To find out if the containers (one for WordPress, Apache and PHP and the other for MySQL) were running, I typed:
docker logs wp
(My container is called wp because that’s what I specified using container_name). This showed me that, yup, both containers were up and running. But then I tried the command a few more times and noticed that the WordPress container was actually restarting every 20-30 seconds. Time to look at the logs.
docker logs wp | tail -n 15
This threw up a whole load of errors about failing to connect to the database.
During my various bouts of head-scratching I had, of course, visited StackOverflow, and this problem recalled something I’d read there, where one guy had tried starting up the MySQL container separately first. It was a convoluted solution and I thought there might be an easier way.
What happened and when?
But first, here’s what I think might have happened.
I can’t be sure because, when the container didn’t work I tried lots of different things, any one of which might have borked the installation. However…
When you install WordPress this way, it downloads all the WordPress files to your local directory. And it’s hard to know when it’s finished doing that (this happens after Docker’s various progress bars have finished). It can take quite a while if, like me, your broadband isn’t all that broad. It’s possible that I might have tried to connect to the service before all the files were in place. But that’s not what actually caused the main problem, I think.
Because it didn’t work straight away, I tried changing stuff like the database name, login credentials and I can’t remember what else. Somewhere along the line, I think that some MySQL configuration had got written to the disk image in the declared volume, db_data. And my current settings didn’t agree with that.
Solved!
I started again from scratch. Because I’d been using ‘docker-compose down’ to shut down the service, there were no containers left – otherwise I would have had to remove them. I also removed the relevant images (docker image rm <image_name>) for WordPress and MySQL.
I then edited the docker-compose.yaml file and changed the name of the volume from db_data to dbdata in the two places it’s mentioned. In other words, I was starting afresh with a whole new disk image. Fortunately, I’d not done anything with this container so there was no data to lose from the existing volume. I started up again with:
docker-compose up -d
And while the containers were still running, I typed:
docker system prune –volumes
As expected, this deleted the old db_data volume, and now everything was running as expected.
It’s possible I could have achieved the same by tearing down the running containers with:
docker-compose down –volumes
That removes the volumes named in the docker-compose.yaml file. I could then have started from scratch just by restarting – possibly. I guess I’ll never know now…