WordPress, and MariaDB on Docker

The motivation for the post was quite simple. Currently, I’m running wordpress for a blog site, and never happy with Themes created by others. Often, I find myself wanting to design my own theme from scratch. Several years ago, when I ran the same domain, on a different server, I used WordPress then as well. Which Ran a custom WordPress theme, which was basically a pre-existing theme, hacked / butchered by yours truly. Resembling something close to what was acceptable to me(Basically I called good enough – good).

Back to the point, and more direct. You do not want to develop a theme on a live “production” system. In the past, I would create a virtual machine for various use cases. This use case would have been no different. Yes, Docker was alive then too, but Docker was nowhere near as usable(for me). Now days however, Docker is very useful, and while perhaps still not perfect, is very useful for such a case.

So now that I’m done with my preamble, let’s get on with it, shall we ?

A couple of prerequisites. This Debian host of mine is on my local area network, with it’s own IP address. It may be possible to run this all on one machine, but that’s not how I’m setup. Well, technically, I am, but the debian host, is running in a virtual machine. Any bare metal machine should have no issues either. So long as it is connected to a local network, accessible to other systems on that same network. Then, of course, the base OS for the host is Debian 11.

Starting off, let’s create a directory, and traverse into it:

mkdir wordpress
cd wordpress

Once that is done, pull in the latest bitnami WordPress image from docker hub:

docker pull bitnami/wordpress:latest

Using curl, we can grab the latest docker-compose.yml file, and pipe the “raw source” into our own local docker-compose.yml file

curl -sSL https://raw.githubusercontent.com/bitnami/bitnami-docker-wordpress/master/docker-compose.yml > docker-compose.yml

If you want, you can view the contents of this file, locally, by using the command cat.

cat docker-compose.yml

Next, we can use docker-compose to bring up the base image. the -d argument, will run the image in “detatched” mode. Basically, running it in the background, instead of taking over your current terminal.

docker-compose up -d

Then, we need a network for our running Docker instances. Since we will have WordPress, and mariaDB in separate containers.

docker network create wordpress-network

Now, we start getting into the “fun” stuff. Potentially confusing if you attempt to take it in all at once. But if you take it one argument at a time. It’s not so bad. After these exact-steps, I’ll give a brief explanation of each “switch” or arguement. Anyway, next we’ll create a volume for mariaDB.

docker volume create --name mariadb_data

Then, a rather long list of arguments as to how we would like the mariaDB image to run:

docker run -d --name mariadb \
  --env ALLOW_EMPTY_PASSWORD=yes \
  --env MARIADB_USER=bn_wordpress \
  --env MARIADB_PASSWORD=bitnami \
  --env MARIADB_DATABASE=bitnami_wordpress \
  --network wordpress-network \
  --volume mariadb_data:/bitnami/mariadb \
  bitnami/mariadb:latest

Perform a similar set of steps, for the wordpress volume, and container:

docker volume create --name wordpress_data

docker run -d --name wordpress \
  -p 8080:8080 -p 8443:8443 \
  --env ALLOW_EMPTY_PASSWORD=yes \
  --env WORDPRESS_DATABASE_USER=bn_wordpress \
  --env WORDPRESS_DATABASE_PASSWORD=bitnami \
  --env WORDPRESS_DATABASE_NAME=bitnami_wordpress \
  --network wordpress-network \
  --volume wordpress_data:/bitnami/wordpress \
  bitnami/wordpress:latest

At this point, we should be able to point our web browser, at the host machines local area network IP address, and be greeted with WordPress’ Default page.

Ok, so assuming all that went well for you, here is a brief explanation of the various commands, and arguments I said I would revisit.

docker volume create --name mariadb_data
docker volume create --name wordpress_data

In each of the above cases, we’re creating a volume, and “tagging” it with a name. This name we assigned each volume makes it much simpler to identify, and use that volume during any subsequent commands.

docker run -d --name mariadb
docker run -d --name wordpress

Each of the above commands, are to run a container, in dethatched mode, while also naming each container. the -d option indicates detached mode, while –name should be obvious as naming the container. Again, naming our containers make container management much easier.

–env: This option used with the docker run command, sets a Linux environment variable.

––network: This option specifies a named docker internal network. This is a separate network from the host network, and can only be used by docker containers.

–p: This options specifies which port to expose to the host, from the container. Used in this format . . . . . . . -p aa:bb where aa is the port exposed to the host, and where bb is the port exposed from the container.

—volume: This option specifies a volume the container uses for persistent data. In the format of . . . . . . . . . <local volume file>:</mount/inside/volume>

Now the last argument in each case:

bitnami/mariadb:latest
bitnami/wordpress:latest

These are base images for each container. Think of these each as separate instances of Linux, used for exactly one purpose. e.g. One for mariaDB, one for WordPress. If you’re more experienced with linux, you can view these similar to a chroot environment.

That’s it for now, but I will continue this topic, testing, and performing basic operations in the context of setting up a development environment. As always, if you require a more in depth explanation on anything I’ve covered here. Make good use of, and practise your google-fu.

Hasta la vista!