How do I move data into a container- Part 1: the Use Case

In my previous series (“How do I ‘containerize’ something?” I worked my way through taking a well-known application (WordPress) and stuffing it into a couple containers. Of course, there is an official Docker WordPress image on the public Docker hub, but of course the majority of applications deployed today may not have been deployed in containers already – so understanding how to take an existing application and ‘Dockerize’ it is an important exercise for me.

This is the first in a series of posts focusing on extending and enhancing the previously ‘Dockerized’ WordPress installation – specifically focused on the movement / migration of data for the newly containerized application.

Overview

My use case is pretty simple – in WordPress I now have a tiered application (web / app / database), and it has been ‘containerized’ into 2 containers – one for MySQL and one for the WordPress server. Is this enough for production? My assumption is that over time, we will occasionally need to update some / part  / all of the code with the app, and the data as well.  In other words, if some of the application code is updated (for example an updated version of WordPress itself), we will want to deploy a version of the application to test the new code, but probably with a set of sample data in the database.  As a part of that effort, the deployment of the ‘test’ instance needs to be able to deploy the new web site code AND a copy of the sample data for testing.  If all the tests go well, then we will need to deploy the newly updated application into production.  Or, what if we are restoring the application from a backup or in DR – we will need to deploy a copy of the production data as well as a copy of the website and application code…

In either case, we need to be able to get a copy of a sample database – OR a copy of the production database – as well as a copy of the web app and application code into a new set of containers. Having queried several of my colleagues, it sounds as if this is a reasonably common pattern – and there are at least two ways to do this without introducing third party solutions, external storage providers, etc. I am sure there are more ways to do this, but I am going to investigate / implement these two.

Method 1 – The Data Mover

The idea here is fairly simple – upon deployment of WordPress and MySQL to either a ‘test’ or ‘production’ environment, a job is executed to copy the correct database file(s) and application data into the WordPress and MySQL containers. This will require introducing at least one more container – one I will call the “data mover…” Essentially, will be a transient container that will simply accept some variables to allow a user to deploy the solution to either a ‘test’ environment or ‘production.’ During its brief life, the data mover will use a script to simply copy the necessary files for the database and the WordPress installation into a volume that will then be used by the MySQL or WordPress containers themselves.

Method 2 – Multi-Stage Builds with Compose

This method is more Docker-esque, though as such it may preclude anything except the use of Docker, Dockerfile and Compose… Certainly it may be possible to adapt this method for use with other orchestration systems (think Kubernetes, etc), but it’s worth investigating either way.

With multi-stage builds, you use multiple FROM statements in your Dockerfile. Each FROM instruction can use a different base, and each of them begins a new stage of the build. You can selectively copy artifacts from one stage to another, leaving behind everything you don’t want in the final image.

https://docs.docker.com/build/building/multi-stage/

To paraphrase, essentially we will be asking Docker to perform a selective copy depending on the target environment (“test” or “prod”) – effectively doing the same thing as using a ‘data mover’ container in method 1, above.

The next two posts will dive into each of these.