It seems that I’m recording an inordinate amount of information concerning WordPress and Docker. This is, as usual, at the behest of my wife. She likes WordPress and I love her, so what can I do?
The benefit of all this WordPress/Docker monkey business is that I’m slowly discovering my own best practices concerning both. What follows is the next installment of my self-education.
I had to do a mass migration of my myriad web applications. My wife’s sites were not spared the inconvenience. They all had been previously Dockerized, so it was really just a matter of doing a backup of the WordPress files and MySQL data and sending it over to a new server in the cloud. The server, of course, had Docker, Compose, et al already installed. The whole setup looked a little like this:
This is the process I followed to backup the sites hosted on the system to be turfed.
This bundles up all the WordPress container files into a single, zipped tar ball.
I don’t bother copying all the container files here. I just need a dump of the WordPress database. Peripheral files are unnecessary and unwanted.
Prep the site’s new home. Here I put Docker Compose to good use managing the running containers. I set up two peripheral data-only containers that do not execute. These are not defined in the
docker-compose.yml file as a way of shielding the site’s data from accidental deletion.
First, create a directory and
Copy and save the following:
VIRTUAL_HOST variable. This site is (and was) running behind an nginx-proxy image.
Next, create the non-executing data-only containers. These are kept at arm’s length from the running containers so that our data doesn’t go up in smoke whilst monkeying around with image upgrades and whatnot.
It’s now safe to fire up the running containers:
At this point, if you were to visit the site URL, you should see WordPress inviting you to set everything up. I, however, have existing site data.
The backup files created above have been copied over to the new server and into my working directory (i.e., the one containing
docker-compose.yml). Write those files to the running containers. All the data actually gets sent to the non-executing, data-only containers because of how we set up
You should now be able to see your old site on its new server.