Microservices and database

Question

What is the best practice for deploying a database in a microservice architecture, more specifically in a distributed environment such as docker? The principles of microservices state that each service must be idle in order to provide scalability. Since the database obviously has a state, should it work in a fixed position outside the cluster, deployed and configured before the cluster is initialized?

I got confused because all the docker examples include the database container in the service definition. But it’s not so simple. Often a database needs a lot of configuration before it is ready for use. In addition, the docker sucks in when coordinating the order in which the service starts.

If it’s really good practice to deploy a database along with docker-docker services, how to ensure consistency and consistency of critical data?

Answer 1

This is a good question, and I think many people still think about best practices. The answer really depends on your needs. There are several ways to crack this nut, but these are the ones I'm using right now:

• Starting the database in typical mode on dedicated machines (machines) with replication, etc.
• I am currently experimenting with starting a database as a service in a Docker Swarm cluster with data stored in the cluster using GlusterFS
  • ,
  • GlusterFS, GlusterFS
    • GlusterFS , , node. , node , , node, node. GlusterFS .

, , , " " . .