patterndockerMinor
Multiple apps (microservices) and one proxy (nginx) docker-compose configuration/architecture
Viewed 0 times
architectureproxydockernginxonecomposeappsmicroservicesandmultiple
Problem
Having the following architecture:
Which of the following options would be the best to deploy in the production environment?
The first option is simple, but offers little felxibility when configuring many microservices or applications, since all docker-compose of all applications would need to be merged to generate the final configuration. The second option uses networks, which are a fundamental pillar of Docker. On the other hand, you don't need all docker-compose to be merged.
Of these two options, given the scenario of having several microservices and needing a single proxy to configure access, which would be the best? Why?
Tnahks in advance.
- Microservice 1 + DB (microservice1/docker-compose.yml)
- Microservice 2 + DB (microservice2/docker-compose.yml)
- Proxy (proxy/docker-compose.yml)
Which of the following options would be the best to deploy in the production environment?
- Docker Compose Overriding. Have a docker-compose for each microservice and another docker-compose for the proxy. When the production deployment is done, all the docker-compose would be merged to create only one (with
docker-compose -f microservice1/docker-compose.yml -f microservice2/docker-compose.yml -f proxy/docker-compose.yml up. In this way, the proxy container, for example nginx, would have access to microservices to be able to redirect to one or the other depending on the request.
- Shared external network. Have a docker-compose for each microservice and another docker-compose for the proxy. First, an external network would have to be created to link the proxy container with microservices.
docker network create nginx_network. Then, in each docker-compose file, this network should be referenced in the necessary containers so that the proxy has visibility of the microservices and thus be able to use them in the configuration. An example is in the following link https://stackoverflow.com/a/48081535/6112286.
The first option is simple, but offers little felxibility when configuring many microservices or applications, since all docker-compose of all applications would need to be merged to generate the final configuration. The second option uses networks, which are a fundamental pillar of Docker. On the other hand, you don't need all docker-compose to be merged.
Of these two options, given the scenario of having several microservices and needing a single proxy to configure access, which would be the best? Why?
Tnahks in advance.
Solution
This is going to be an opinionated answer as both options are clearly possible.
I would go with the first option you described for the following reason:
It seems that at the moment you don't have a lot of microservices (otherwise you wouldn't be using docker-compose and would likely be doing k8s or at least docker swarm). Now, if your application grows a lot - you would likely outgrow compose in any case, so it would be wasteful if you optimize for compose at this stage anticipating future complexity.
So my take would be to go with option 1 for now which is much easier to implement. And when you need extra flexibility, likely you'd have other reasons to switch from docker-compose to something else.
I would go with the first option you described for the following reason:
It seems that at the moment you don't have a lot of microservices (otherwise you wouldn't be using docker-compose and would likely be doing k8s or at least docker swarm). Now, if your application grows a lot - you would likely outgrow compose in any case, so it would be wasteful if you optimize for compose at this stage anticipating future complexity.
So my take would be to go with option 1 for now which is much easier to implement. And when you need extra flexibility, likely you'd have other reasons to switch from docker-compose to something else.
Context
StackExchange DevOps Q#11043, answer score: 4
Revisions (0)
No revisions yet.