Docker Compose : tout savoir

Dans le monde du DevOps, les conteneurs sont rapidement devenus des incontournables, aussi important que les machines virtuelles. Des plateformes de conteneurisation comme Docker ont permis de simplifier et d'accélérer la création d'image et l'exécution de conteneurs sur différents systèmes, à portée de tous. Seulement, avec les nouvelles architectures modernes des micro-services, plusieurs conteneurs doivent souvent s'orchestrer en parallèle ou de manière séquencée, avec une gestion des dépendances et de cycle de vie.

Des plateformes d'orchestration de conteneurs comme Kubernetes ont notamment vu le jour pour permettre de mettre à l'échelle un nombre quasi infini de conteneurs Docker. Mais elle reste une plateforme qui demande de la maintenance et des compétences avancées en DevOps. N'y aurait-il pas un outil qui permette également d'orchestrer des conteneurs Docker, en utilisant une seule machine et sans passer par Kubernetes ?

C'est justement la promesse de Docker Compose : cet outil permet d'exécuter en même temps des applications qui nécessitent plusieurs conteneurs, le tout orchestré de manière déclarative par un fichier de configuration YAML. Dans cet article, nous allons voir les principales fonctionnalités de Docker Compose, et en quoi il peut se révéler très utile.

Docker Compose

Docker Compose est un outil permettant d'orchestrer plusieurs applications exécutées dans des conteneurs Docker. Cela permet notamment d'écrire l'ensemble des paramètres et dépendances des applications, ainsi que la manière dont elles interagissent entre-elles dans un fichier YAML appelé docker-compose.yml.

Puisque les applications sont exécutées dans des conteneurs Docker, il est possible de spécifier un grand nombre de paramètres pour chacune d'entre-elles, comme les services nécessaires, les volumes attachés ou encore les propriétés réseaux.

À lire : découvrez notre formation DevOps Engineer

Quand utiliser Docker Compose ?

Du fait de sa capacité à exécuter des conteneurs Docker et à les orchestrer très facilement, il y a plusieurs situations où Docker Compose trouve une très grande utilité.

• Dépendances d'applications : il n'est pas rare pour des applications de nécessiter des services connexes ou des initialisations à effectuer en amont. Par exemple, si une application a besoin d'une base PostgreSQL pour fonctionner, cela permet d'exécuter dans un première temps PostgreSQL dans un conteneur, puis une fois que nous sommes assurés que ce conteneur est parfaitement initialisé, nous pouvons ensuite lancer l'application principale. Cette situation est l'une des plus fréquentes dans la plupart des projets intègrant Docker Compose.
• Environnements de tests : l'autre situation où Docker Compose excelle, c'est dans sa capacité à répliquer des environnements. En effet, puisque tout l'orchestration est définie au manière d'un fichier YAML, rien n'empêche de modifier des variables ou paramètres globaux afin que ceux-ci soient répliqués dans chaque conteneur. Si un projet nécessite d'avoir un environnement de test ou de pré-production similaire à l'environnement de production, cela permet de répliquer très facilement ce dernier en changeant uniquement quelques variables ou paramètres.
• Ré-utilisabilité des configurations : si plusieurs projets partagent plus ou moins la même architecture de conteneurs, la puissance du côté déclaratif des fichiers YAML permet ainsi de répliquer très facilement une configuration d'un projet vers un autre. Cela simplifie et accélère grandement les étapes de configuration, notamment lorsque de nouveaux projets sont régulièrement créés.
• Interopérabilité : enfin, on retrouve la plupart des paramètres de Docker Compose dans les plateformes d'orchestration à grande échelle comme Kubernetes. S'il y a un besoin de mettre à l'échelle et de basculer sur une autre plateforme, les mêmes modes opératoires d'orchestration pourront être réutilisés sur cette nouvelle plateforme.

Exemple Docker Compose

Au même titre qu'un Dockerfile permettait de définir les spécifications d'une image, un fichier docker-compose.yml permet de définir l'ensemble des services (conteneurs) qui seront exécutés. Pour qu'un fichier docker-compose.yml puisse être utilisé, ce dernier doit comporter au moins deux champs.

• La version de Docker Compose avec version, la plus récente pour l'instant étant la version 3.
• Au moins un service, c'est-à-dire un conteneur dans le champ services.

Prenons un exemple simple : nous allons lancer une base PostgreSQL dans un conteneur Docker. Mais plutôt que d'utiliser docker run ..., nous allons utiliser Docker Compose, car nous allons par la suite y rajouter de nouveaux services.

version: '3'
services:
  postgres:
    image: postgres:13
    environment:
      POSTGRES_DB: main
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: blentdevops
    volumes:
      - pg_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "main"]
      interval: 10s
      retries: 5
      start_period: 5s
    ports:
      - "5432:5432"
volumes:
  pg_data:

Tout d'abord, on y décrit un service nommé postgres, qui est basé sur l'image Docker postgres:13. Ce service correspond à l'instance de base de données PostgreSQL.

Ensuite, le service postgres est configuré avec plusieurs variables d'environnement, notamment :

• POSTGRES_DB, qui est défini sur main pour spécifier le nom de la base de données à créer.
• POSTGRES_USER, défini sur postgres pour indiquer le nom de l'utilisateur de la base de données.
• POSTGRES_PASSWORD, qui est défini sur blentdevops pour spécifier le mot de passe de l'utilisateur de la base de données.

De plus, un volume nommé pg_data est monté depuis le conteneur postgres vers le chemin /var/lib/postgresql/data à l'intérieur du conteneur. Cela permet de stocker les données de la base de données de manière persistante, même lorsque le conteneur est arrêté.

Le service postgres est également configuré avec un healthcheck, ce qui signifie qu'il vérifie régulièrement l'état de santé du conteneur en exécutant la commande pg_isready -U postgres. Le succès de cette commande est utilisé pour déterminer si le conteneur est en bon état de fonctionnement. Les autres paramètres de configuration du healthcheck incluent l'intervalle de vérification, le nombre de tentatives et la période de démarrage.

À découvrir : notre formation DevOps Engineer

Enfin, le service postgres expose le port 5432 à l'extérieur du conteneur, ce qui signifie que l'utilisateur peut accéder à la base de données PostgreSQL en utilisant le port 5432 sur l'hôte Docker.

En dehors de la section services, il y a une section volumes qui définit le volume nommé pg_data. Ce volume est utilisé pour stocker de manière persistante les données de la base de données PostgreSQL. On peut notamment y ajouter ici des paramètres spécifiques au volume, comme sa taille, son système de fichier ou encore le pilote de stockage utilisé.

Maintenant, exécutons notre service avec la commande docker compose up. L'argument -d permet d'exécuter les conteneurs en daemon comme ce fut le cas pour les conteneurs.

docker compose up

[+] Running 2/0
 ✔ Volume "blent_pg_data"      Created        0.0s 
 ✔ Container blent-postgres-1  Recreated      0.0s 
Attaching to blent-postgres-1
blent-postgres-1  | The files belonging to this database system will be owned by user "postgres".
blent-postgres-1  | This user must also own the server process.
blent-postgres-1  | 
blent-postgres-1  | The database cluster will be initialized with locale "en_US.utf8".
blent-postgres-1  | The default database encoding has accordingly been set to "UTF8".
blent-postgres-1  | The default text search configuration will be set to "english".
blent-postgres-1  | 
blent-postgres-1  | Data page checksums are disabled.
blent-postgres-1  | 
blent-postgres-1  | fixing permissions on existing directory /var/lib/postgresql/data ... ok
blent-postgres-1  | creating subdirectories ... ok
blent-postgres-1  | selecting dynamic shared memory implementation ... posix
blent-postgres-1  | selecting default max_connections ... 100
blent-postgres-1  | selecting default shared_buffers ... 128MB
blent-postgres-1  | selecting default time zone ... Etc/UTC
blent-postgres-1  | creating configuration files ... ok
blent-postgres-1  | running bootstrap script ... ok
blent-postgres-1  | performing post-bootstrap initialization ... ok
blent-postgres-1  | syncing data to disk ... ok
blent-postgres-1  | 
blent-postgres-1  | 
blent-postgres-1  | Success. You can now start the database server using:
blent-postgres-1  | 
blent-postgres-1  |     pg_ctl -D /var/lib/postgresql/data -l logfile start
blent-postgres-1  | 
blent-postgres-1  | initdb: warning: enabling "trust" authentication for local connections
blent-postgres-1  | You can change this by editing pg_hba.conf or using the option -A, or
blent-postgres-1  | --auth-local and --auth-host, the next time you run initdb.
blent-postgres-1  | waiting for server to start....2023-10-12 06:33:18.072 UTC [48] LOG:  starting PostgreSQL 13.12 (Debian 13.12-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
blent-postgres-1  | 2023-10-12 06:33:18.074 UTC [48] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
blent-postgres-1  | 2023-10-12 06:33:18.078 UTC [49] LOG:  database system was shut down at 2023-10-12 06:33:17 UTC
blent-postgres-1  | 2023-10-12 06:33:18.082 UTC [48] LOG:  database system is ready to accept connections
blent-postgres-1  |  done
blent-postgres-1  | server started
blent-postgres-1  | CREATE DATABASE
blent-postgres-1  | 
blent-postgres-1  | 
blent-postgres-1  | /usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
blent-postgres-1  | 
blent-postgres-1  | waiting for server to shut down...2023-10-12 06:33:18.276 UTC [48] LOG:  received fast shutdown request
blent-postgres-1  | .2023-10-12 06:33:18.277 UTC [48] LOG:  aborting any active transactions
blent-postgres-1  | 2023-10-12 06:33:18.279 UTC [48] LOG:  background worker "logical replication launcher" (PID 55) exited with exit code 1
blent-postgres-1  | 2023-10-12 06:33:18.279 UTC [50] LOG:  shutting down
blent-postgres-1  | 2023-10-12 06:33:18.289 UTC [48] LOG:  database system is shut down
blent-postgres-1  |  done
blent-postgres-1  | server stopped
blent-postgres-1  | 
blent-postgres-1  | PostgreSQL init process complete; ready for start up.
blent-postgres-1  | 
blent-postgres-1  | 2023-10-12 06:33:18.398 UTC [1] LOG:  starting PostgreSQL 13.12 (Debian 13.12-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
blent-postgres-1  | 2023-10-12 06:33:18.398 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
blent-postgres-1  | 2023-10-12 06:33:18.398 UTC [1] LOG:  listening on IPv6 address "::", port 5432
blent-postgres-1  | 2023-10-12 06:33:18.400 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
blent-postgres-1  | 2023-10-12 06:33:18.404 UTC [63] LOG:  database system was shut down at 2023-10-12 06:33:18 UTC
blent-postgres-1  | 2023-10-12 06:33:18.408 UTC [1] LOG:  database system is ready to accept connections

Conclusion

Avec sa possibilité d'orchestrer plusieurs conteneurs localement et sa facilité d'implémentation, Docker Compose est un outil très pratique lorsqu'il faut développer sur des applications micro-services. Il s'agit d'une véritable alternative à d'autres plateformes comme Kubernetes, en particulier lorsque les conteneurs sont exécutés sur une seule machine.