Should I use a Docker-Compose.yml or multiple

Asked

Viewed 99 times

2

Good morning,

The architecture of my project is micro-services that are in Docker containers. In which I have a Docker-Compose.yml file for all micro-services.

My question is this: It’s best to have a Docker-Compose.yml file for all micro-services or I should have a Docker-Compose file for each micro-service?

Thank you

docker docker-compose microservices

  • I especially prefer the idea of each service having its own Compose, up to pq, everything together kind of hurts the idea of micro services, but has the problem of repeating several shared infrastructures, and the answer of tvdias gives a good solution to this

2 answers

3


Although I think it’s the kind of response that will be based on opinions, I believe it can be useful for many people if suggestions for this problem are shared.

I’ve been through this situation, where I have an environment with more than 30 services. In this case I chose to have several docker-composes. In each of the files I have only the service specified in the Compose name and dependencies exclusive of this service. An example of unique dependency are data boot services for testing and DB Migration, as we have this outside of our services.

As each service has its database, initially we created a DB in each yml, along with the service, however, as they all use the same database server, we later chose to create a "base" (or "infrastructure" Compose)where we add services such as message bus and Dbs. This base pose even serves as a "starting point" for when we execute docker-compose up.

This approach was chosen because it was simple and "modular". Since we hardly have the need to have all services running at the same time (we use this framework for developing tests). This way any developer can run only the Compose that interests him and the Compose settings themselves will indicate the necessary dependencies for that service and the developer can then easily add the other composes to the command.

Example of docker-compose up:

docker-compose -f docker-compose.yml `
               -f part_servico_a.yml `
               -f part_servico_b.yml `
               up -d

In this example we have all part of infrastructure in the docker-compose.yml and the applications in part_servico_X.yml. If one of these services depends on another service the command will present the error clearly and then we can add -f part_servico_X.yml at the helm.

Example of docker-compose.yml groundwork:

version: '3.4'

services:
  cassandra:
    image: cassandra
    ports:
      - "9042:9042"

  zookeeper:
    image: wurstmeister/zookeeper
    ports:
     - 2181

  kafka:
    image: wurstmeister/kafka
    ports:
      - "9092:9092"

  rabbitmq:
    image: rabbitmq:3-management
    ports:
      - "15672:15672"

  mongo:
    image: mongo
    ports:
      - "27017:27017"

Example of part_servico_X.yml:

version: '3.4'

services:
  servico-X:
    image: <IMAGEM>
    restart: on-failure
    deploy:
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3
        window: 60s
    depends_on:
      - cassandra
      - cassandra-migration-servico-X
      - servico-Y
      - servico-Z

  cassandra-migration-servico-X:
    image: <IMAGEM>
    depends_on:
      - cassandra

-3

Maintaining multiple . yml you can maintain the principle of micro-service cohesion, that is, you will only be in . yml the necessary for execution. You can orchestrate multiple micro-services going up as @tvdias quoted and thinking about using a service mesh like Istio, it makes even more sense to keep it separate.

Either way, this is a conceptual design decision, both ways would work, but it’s probably easier to keep isolating these. ymls.

Browser other questions tagged docker docker-compose microservices

You are not signed in. Login or sign up in order to post.