Most of the articles online regarding setting up Docker containers seem to be written around the idea of breaking an application into micro services and allocating them into various containers and deploying them into a cluster.
I would like to find out the best way to handle databases (e.g. mySQL) for multiple unrelated applications, written for different clients, deployed into the same cluster.
Say I have 10 unrelated small applications (like wordpress), all requiring access to mySQL database. I could:
Deploy the applications as containers into the cluster, containing just the application code, and setting up a dedicated mySQL server or a Google Cloud SQL instance and asking each of the application containers to connect to the database as 3rd party services.
Deploy the applications as containers into the cluster. For each applications, also deploy a separate database container into the cluster and linking the two.
Deploy a separate database container into the cluster and link this container to the various application containers in the cluster.
Which of these solutions is the best in turns of application architecture design and which of these is best use of computer resources? I have the feeling that while deploying multiple mysql containers (one for each application) maybe the best design but it might not be the most resource efficient as we will have a bunch of mySQL containers running.
Containerising db for each app seems to be "the docker way" and provide better isolation and portability
The docker way isn't a db per app but a service per container. MySQL is a service at soon as you don't run in the mysql container an another service (app/ssh/monitoring...) it's the way to go.
So the decision between one db per app or one db for all is up to you.
My personal choice is the third:
- Deploy a separate database container into the cluster and link this container to the various application containers in the cluster.
I'm using kubernetes with a postgres container that is used as a DB server for all applications.
I prefer this choice because it's easier as an OP point of view to backup/replicate/apply maintenance than having 30 differents db servers + 30*slaves + 30*external pool + 30*monitoring tools etc... Also in my case I have a better hw resources usage.
But I conserve the possibility to move a database to another dedicated db-server container in case an application is using too much resource or if too many app are already using the DB.