I’m planning on making my 1st dev environment for Rails app.
I’ll be using mysql as DB.
When using docker, is it a good practice to have separate containers for an app and mysql ?
So, when I’ll docker in production, my understanding I can just replace a docker container for an app with the newer content as a deployment, while keeping mysql container untouched… Is that correct idea?
Let me know if there’s anything missing.
Maybe I will need to separate web server to a different container as well?
I don’t want to re-invent the wheel.
It is indeed best practice to keep processes in their own containers. This allows you to do upgrades for one type of service without affecting others as you mentioned.
For a simple web application setup, I generally prefer to have three services: db, app, load_balancer.
Generally, I’d have one load balancer container that reverse proxies to one or more app containers. Each app container would access the db.
My understanding is 1 service = 1 container.
Maybe I’m mistaken and we have more than 1 services per 1 container, but it maybe a good practice to have 1 service = 1 container?
Yes, in my example I am suggesting that one service is one container.
It is certainly possible to put more than one service into a single container. A common approach is to run something like supervisord in the container, and define multiple supervisord services that all get launched.
Generally speaking one service is a single process. There are some cases where a service might launch multiple subprocesses. Apache’s workers, or postfix’s various processses are examples of this.
Some more information on general deploy design can be found at http://12factor.net/. Docker was designed with many of the 12 factor principles and concepts, so it works really well together.
Usually, I’ll fire up an nginx instance to act as a load balancer. It will then use its proxy_pass feature to route requests to the backend application server(s)
