Menu
I have a server running 5 or 6 small Rails apps. All their attached files are on S3 and they all use MySQL as database. Each app has its own user and runs some thins. There is an nginx server doing the load balancing and domain routing.
I plan to replace this server by a Docker installation : one server with one container per app, with a nginx in front.
My question is : where would you put the database part ?
I mainly see 4 possibilities :
1) One Mysql server inside of each app container. This seams not to be Docker's philosophy I think. It would require each container's data to be backuped individually.
2) A unique MySQL container for all apps.
3) A standard MySQL installation on the host Docker server.
4) A separate MySQL server for all apps.
What would you do ?
PS : I know Docker is not production ready yet, I plan to use it for staging at the moment and switch if I'm happy with it.
280
Docker is great for running databases in a development environment! You can even use it for databases of small, non-critical projects which run on a single server.
It's ok to have multiple processes, but to get the most benefit out of Docker, avoid one container being responsible for multiple aspects of your overall application. You can connect multiple containers using user-defined networks and shared volumes.
First, we have to install Docker Desktop. Then, we should find an existing image of our database from the Docker Hub. Once we find it, we'll pick the docker pull command from the top right corner of the page. Next, we'll test our database container connection.
Docker architecture. Docker uses a client-server architecture. The Docker client talks to the Docker daemon, which does the heavy lifting of building, running, and distributing your Docker containers. The Docker client and daemon can run on the same system, or you can connect a Docker client to a remote Docker daemon.
It depends on several factors. Here are some questions to help you to decide.
Are the 5-6 apps very similar (i.e., in Docker terms, you could base them on a common image), and are you thinking about deploying more of them, and/or migrating some of them to other servers?
YES: then it makes sense to embed the MySQL server in each app, because it will "stick around" with the app, with minimal configuration effort.
NO: then there is no compelling reason to embed the MySQL server.
Do you want to be able to scale those apps (i.e. load balance requests for a single app on multiple containers), or to scale the MySQL server (to e.g. a master/slave replicated setup) ?
YES: then you cannot embed the MySQL server, otherwise, scaling one tier would scale the other tier, which will lead to though headaches.
NO: then nothing prevents you from embedding the MySQL server.
Do you think that there will be a significant database load on at least one of those apps?
YES: then you might want to use separate MySQL servers, because a single app could impede the others.
NO: then you can use a single MySQL server.
Embedding the MySQL server is fine if you want a super-easy-to-deploy setup, where you don't need scalability, but you want to be able to spin up new instances super easily, and you want to be able to move instances around without difficulty.
The most flexible setup is the one where you deploy one app container + one MySQL container for each app. If you want to do that, I would suggest to wait for Docker 0.7, which will implement links, which will let you have a basic service discovery mechanism, so that each app container can easily discover the host/port of its database container.
I wouldn't deploy MySQL on the host; if you want a single MySQL install, you can achieve the same result by running a single MySQL container and running it with -p 3306:3306 (it will route the host's 3306/tcp port to the MySQL container's 3306/tcp port).
126
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
