Use mysql in docker container in production or not?

Question

MySQL

The task was to transfer sites from shared hosting to VPS and run them in isolated docker containers.
I didn't deal with docker before, so I came up with this solution:
nginx (proxy) -> [container 1(apache + php + mysql)] <= volume(site 1 + database1)
nginx (proxy) -> [container 2(apache + php + mysql)] <= volume(site2 + base2
)
Tell me, what are the problems / pitfalls of placing mysql in a container, despite the fact that the database itself will be located on the docker host.

Answer 1

mysql in a production container. Here's some advice for you.
You will only have 4 containers (assuming there is only one host):
Only questions for you are:
- what for do you need Apache here?
- why do these sites need isolated containers?

Answer 2

Wrapping a LAMP/LEMP stack in docker is stupid. It is not a problem to make different versions of PHP, MySQL is quite fresh version 5.6 or 5.7.

Answer 3

Don't go until you're experienced in understanding what it is and how to kick it to take off at 3am.

Answer 4

changes to files (databases) are not saved in the container, after restarting the container, your entire database will be reset to its original state, which is convenient, for example, when testing, but not when working.
in order to save data changes, you need to carry out certain operations, and in order for the data in the database to be consistent with your container, you will need to constantly monitor and update the container immediately after making changes to the database, such a procedure creates a serious load and unnecessary gimor.

Answer 5

A couple of tips:
1. Consider abandoning Apache - it doesn't give you anything in 2018. Perhaps you have some routing rules tied to it - try switching them to nginx
2. Don't run everything in one container: make one container per process (separately in PHP, separately in nginx). This will give you the option to use standard images. If you still leave Apache, then you will have a container with Apache + PHP, since most likely you are using the doctor module, but I repeat - try to refuse Apache.
3. Try to avoid volumes in production for code. Build your image based on the standard image with your code added to it at the build stage. Look at this article. So you will have the opportunity to deploy the container as a whole, and not put a folder with the code on it. This will make the system more stable and portable.
4. You don't need MySql in a container: firstly, it's an overhead to have a separate MySql instance for each site. Second, you need to ensure data persistence, which means using volume. This is more complicated and has its drawbacks: slower, etc. Run MySql on a separate server or even on the same one where the docker is, but not in a container - save resources and nerves. When you figure it out, look at the dockerization of the database again.

Answer 6

Tell me, what are the problems / pitfalls of placing mysql in a container, despite the fact that the database itself will be located on the docker host.

Be prepared that it will eat disk space like a pistol. Otherwise, there are no problems. A possible overhead from using the base in a container is compensated by the base server settings (you didn’t profile the server for the current load profile?) And the curvature of the base itself (did anyone debug queries in the scheduler?). Therefore, you should not worry.
Best practice says not to store data in containers, so the database file must be placed outside the container using the volume mechanism.