3

Having the following architecture:

  • 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?

  1. 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.
  2. 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.

Improve this question

1 Answer 1

Reset to default
4

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.

Improve this answer
2
  • Thank you very much for the reply, @taleodor. And the case of using networks, when would it be more advisable? If you want to use docker-compose (an assumption) to deploy multiple microservices, wouldn't the second option be better? Using the first one would be difficult to handle, in my opinion.
    – Mr. Mars
    Commented Mar 11, 2020 at 10:49
  • 1
    @Mr.Mars As I mentioned in the answer, I'd say if you find yourself in the situation where using networks is beneficial - you might as well migrate your stack to k8s and it would likely be most reasonable thing to do. Where you would may use networks in compose - is if you have Docker Swarm cluster and you're testing it on compose. Other than that I don't see real use case nowadays.
    – taleodor
    Commented Mar 11, 2020 at 23:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.