Containerization of server workloads is growing in popularity, and it is increasingly common to see web server deployments run in containers. Can the same benefits be applied to databases?
Docker can manage stateful workloads
It’s best to ask another question first: can you even run a database in Docker? In general, Docker is not designed for stateful services. One of the main selling points of containers is that they can be stopped and started at will, usually by connecting to an authoritative data source, such as a database, to store their state. All data in the container is ephemeral and is destroyed when the container is deleted.
This makes running stateful workloads especially difficult, but luckily Docker has a few tools to handle stateful mounts: volume and link. These allow you to mount a location on the host machine to a location in the container, which will store data even when the container shuts down. This way, you can run long term containers without worrying about data loss.
Volume mounts are the preferred way to handle most scenarios. They allow you to create a volume, which is managed by Docker …
docker volume create my-volume
… To mount this volume to a target location inside the container:
docker run –mount source = my-volume, target = / app
Link mounts are simpler. These are the volumes used under the hood, but they allow you to manually set the location on the host drive rather than managing it through Docker.
docker run ~ / nginxlogs: / var / log / nginx
In practice, the use of these supports can be a little more complicated. Many managed Docker services, like AWS’s ECS or Managed Kubernetes, do not give you direct access to the underlying server, and therefore you will not be able to directly establish link mount connections. Usually this is solved with a service like EFS, which allows mounting on DHW containers, or with an external database, such as a database.
Should you choose Docker for your database?
Docker is generally not ideal for managing condition. Docker-based workloads typically outsource this problem to databases. Since a database is the solution to the problem, is it practical to put your database in Docker?
Overall, the answer is “generally not”. Docker has come a long way since its inception, and it is no longer a terrible or ‘wrong’ idea to containerize databases. It can certainly be done and has some advantages. However, for most general workloads, the benefits do not outweigh the complications.
To understand why, let’s take a look at the benefits Docker brings to the table:
Easy to scale: Servers can be created and destroyed quickly to meet demand
Easier CI / CD tools: automated builds are trivial
Codification of your infrastructure: all the underlying libraries and configuration are managed in the Dockerfile
Most of these don’t exactly translate into database workloads, which are often long-term efforts that primarily promote data integrity. You generally do not want to autoscale most databases; they typically don’t receive regular code updates themselves, and as such don’t benefit as much from running in containers. And, if you’re only mounting a local storage drive anyway, why not run it outside of Docker?
If you are looking to break free from the complexities of database management, Docker is not the ideal tool. This is simply an unnecessary complication for a workload that can easily run on a standard VPS. You are probably much better off using a fully managed database as a service, like AWS RDS. This does a lot of the automation that Docker is good at, without the headache of doing it yourself.
The main place where Docker can be useful for database workloads is in development environments. Docker makes it easy to create new databases with a different configuration, which allows for quick testing. In production, however, the rules are generally stricter.