Containerized databases

This recipe discusses best practices regarding the use of containerized databases.

Getting ready

We will require the following:

• Oracle Linux
• Podman

How to do it…

Containers make databases a much easier pill to swallow for your everyday application deployments. There’s not a lot to discuss in this recipe, but there are a few best practices with containerized databases that will definitely be useful to know about.

Do one thing and one thing only

Just as a core principle of containers is to do one thing and one thing only, the same principle applies to containerized databases. What do I mean by that? Well, for starters, you might be inclined to launch a containerized database and subsequently create multiple schemas within that database and/or multiple databases within that single container. Let’s say you have several applications that require a MySQL database, then it probably seems like a good idea to have a single MySQL database container with separate database schemas for each containerized application… something that looks a bit like this:

Figure 11.6 – What not to do with containerized databases

The problem with this architecture is that it does not adhere well to the principle of doing one thing and one thing only. Instead, I recommend spinning up a separate container for each database an application needs. Name that container so that it is complementary to the application it’s paired with – something like this:

Figure 11.7 – A better way to use containerized databases

For example, let’s say you have a WordPress container that requires a database. In this scenario, if you named your WordPress container wordpress01, then you should name your MySQL container wordpress01-db. Having a separate container for every database you want to run will make it easier to troubleshoot issues and will additionally serve as a more reliable architectural model for your deployed applications. If you need to take one containerized database down, you’re then only affecting one application, rather than all of them if you chose to run multiple databases within one container.

Data storage

Persistent data is something you’ll need to address when running databases in containers. With Podman, you have two primary options: volumes and bind mounts. With volumes, Podman will manage the storage of your database by writing the data to disk using its own internal volume management system. With bind mounts, you will need to specify a location on the host system and mount that into the container. Either option is fine, and typically volumes are easier because it requires less configuration by the user, but the downside is that the data can be more difficult to locate on the host system. Additionally, it is possible for the volumes to be deleted by mistake via careless use of the podman volume prune command. With that being said, for demonstrations or quick tests, I like to use volumes, but for persistent data that is truly important, I prefer to use bind mounts.

Creating volumes is simple. There are a few ways in which Podman allows for the creation of volumes. You can create a volume manually from the command line via the podman volume create [NAME] command. You can also let Podman do the heavy lifting for you, as it is capable of creating volumes automatically during container creation. Podman can create a named volume if you specify the name; for example, running podman run -v my_data:/var/lib/mysql mysql:8-oracle will create a volume called my_data. Podman can also create an anonymous volume if you leave out the -v my_data:/data specification and instead run podman run -it oraclelinux:8.

If you want to use a bind mount instead, all you need to do is specify the location of where that mount should reside on the host system. For example, if you want to store your data in /mnt/hdd/podman/volumes/, you would simply need to specify this location as the source location. I prefer to set my volume location as an environment variable called VOLUME_DIR so that I can reference it with ${VOLUME_DIR}. Then, when I specify creating a bind mount in the container, I simply use podman run -v ${VOLUME_DIR}/wordpress:/var/lib/mysql mysql:8-oracle. This will ensure that all my data is stored in a predictable location on my system, and each container gets its dedicated folder within that path.