I was feeling pretty pleased with myself having just figured out how to set up a private Docker registry, when I discovered an interesting thing about Docker’s official MySQL image: commits don’t persist database data! This is my fault for not understanding the documentation and how to work with data volumes.
In any case, my wife set up a Dockerized website in WordPress. We wanted to transfer it to a new domain. I set up a private registry to which to commit images of her data. I deployed everything only to discover that the data, both database and WordPress, are not stored in ther respective images. This was no good for my purposes, so I set out to persist the database and WordPress data by creating and mounting two data volume containers.
Here’s how I transfered everything between my Docker MySQL/WordPress images and their respective data volume containers…
Supposing we are transfering the website from originaldomain.com to somenewdomain.com, this is how to configure Compose:
Copy and save the following:
volumes_from settings point to containers which point to volumes on the host system…
Fire it up!
The two data volume containers don’t contain any data yet. That comes next.
It was important that I be able to verify for myself that the data wasn’t being persisted, so I needed to examine the databases in each image…
First, I needed to find out what IP my MySQL container was listening on.
Then I used my local
mysql installation to connect to the database on the container.
mysql> prompt, I looked at the databases:
The database was simply called
wordpress, so I took a look in there:
I found a bunch of
woocommerce tables, which I knew to be my wife’s WordPress data. I repeated the process for the existing (but broken)
somenewdomain_mysql container and discovered that the WordPress database didn’t even exist. My investigation confirmed what I had suspected: the data wasn’t being committed to the image.
I needed to get the data out of the MySQL container so that I could write it to a new container pointing to a data volume container. What? To do this, I first needed to know the IP that the original (originaldomain.com) database is listening on:
Then, setting that IP with the
-h option, this exports all of the tables:
Find the IP of the new MySQL image:
Create a wordpress database (if necessary):
mysql> prompt, check to see if the wordpress database already exists:
Create it, if it doesn’t:
Logout of the the MySQL command line and execute from the host machine:
The data has now been imported and is stored in a volume guarded by the _somenewdomaincom_wordpressdata container.
All the WordPress template and customizations are currently stored in volume directly accessed by _originaldomaincomwordpress container. I needed to find that directory on my host machine:
I looked under Mounts for Source. The paths looked something like this:
I copied that data to my current working directory for safe keeping:
Then I needed the Source path for the _somenewdomaincom_wordpressdata container:
It looked like this:
I was careful to note the configuration whose Destination was
/var/lib/mysql. There will be two mount points. The other destination (the wrong one) looks like this:
Knowing the destination path, I removed the entire
_data directory, because I don’t want any weird stuff hanging around:
I copied the contents of the
data directory to the _somenewdomaincom_wordpressdata volume container’s source:
With all the data transfered, I restarted Docker Compose:
Everything looked good, except for one thing. All the links on the homepage were still pointing to the old originaldomain.com domain.
To fix this, I simply edited the
wp-config.php file contained in the
_data/ directory I had just copied
Then I appended and saved these two lines:
The site worked as it did before on its new domain.
I have a better understanding of how to work with Docker volumes, which renders my previous application of the Docker technology mostly inadequate.
As well, I suspect the whole import/export MySQL stuff may be unnecessary. It may be sufficient to simply copy the directory as with the WordPress data, but that has not yet been confirmed.