Docker compose est à la fois un programme docker compose et à la fois un fichier de configuration (en YAML).
L'idée est d'avoir une recette de cuisine contenue dans un fichier pour créer un service (qui peut faire appel à plusieurs containers : serveur web, bdd, … avec des montages de volumes bien définis). ça évite de faire des commandes CLI à rallonge.

Et ça épouse bien le cycle de vie d'un service sous Docker, qui consiste à séparer les données (volumes) de l'application (image), en faisant des containers qui suivent des cycles de création à partir de la dernière image de l'app dispo sur le web et de destruction du container, tout en conservant les données dans les volumes pour avoir une persistance de celles-ci.

Cela permet la manipulation de nombreux container en une simple commande (il faut suivre la recette du Compose file).

doc officielle

Contient les règles pour décrire le service que l'on souhaite. Il peut être composé de plusieurs containers, de volumes et de networks.

Traditionnellement, le nom du fichier est (par ordre de préférence) : compose.yaml, compose.yml, docker-compose.yaml ou docker-compose.yml. L'emploi d'un de ces noms permet d'omettre le Compose file à utiliser lorsqu'on écrit des CLI comme docker compose up.

Il est conseillé d'avoir un dossier avec un Compose file pour chaque application (ensemble de services visant une fonctionnalité, par exemple un serveur web intranet, une station météo auront chacun leur dossier contenant leur Compose file).

On trouve plusieurs infos sur la structure d'un Compose file. La spécification a évoluée, et certains directives (comme top-level version) sont obsolètes. Je ne vais lister ici que ce qui est à jour à la date de création de cet article (2/08/2025).

(/!\ orthographe et casse)

Top-level :

• name : définit le project name. Servira de préfixe à tout le reste (nom des containers, des networks, des volumes…). Si name n'est pas définit, docker prendra le nom du dossier qui contient le Compose file. Limite : si container_name est défini, il n'y a pas de préfixe

• services : (OBLIGATOIRE) A service is an abstract definition of a computing resource within an application which can be scaled or replaced independently from other components. Services are backed by containers.
  • Contient donc des containers, qui sont définis par des arguments:
    • Peut contenir une section build pour construire une image docker.
    • image : spécifie l'image utilisée pour construire le container. Format de l'adresse de l'image : [<registry>/][<project>/]<image>[:<tag>|@<digest>]
    • container-name : définit le nom du container, pour éviter un nom aléatoire (pose de pb en cas de scaling -??-)
    • links : définit les liens / networks pour être réliés à d'autres containers (?? version simplifiée des networks ??)
    • ports : définit le mapping des ports entre l'hôte et les containers. Syntaxe (avec des “ ”): “[HOST:]CONTAINER[/PROTOCOL]”, avec
      • HOST is [IP:](port | range) (optional). If it is not set, it binds to all network interfaces (0.0.0.0).
      • CONTAINER is port | range.
      • PROTOCOL restricts ports to a specified protocol either tcp or udp(optional). Default is tcp.
    • restart : définit la politique de (re)démarrage automatique : “no”, always, unless-stopped, on-failure[:max-retries]
    • secrets : pour définir des accès à des secrets comme des certificats, nécessite aussi une définition de secrets en top-level (comme volumes et networks)

• volumes : permet la configuration de named volumes pour l'application
  • Pour utiliser un volume dans plusieurs services, il faut que chacun l'exprime explicitement dans l'attribut volume de ce service
  • L'attribut external (true/false) indique que le volume existe déjà et est géré à l'extérieur du Compose file

• networks : permet aux services de communiquer entre eux.
  • Par défaut, il y a 1 seul réseau pour toute l'application, nommé default
  • Il faut détailler la config du réseau sous la directive top-level networks
  • à minima il faut donner un nom au réseau
  • Si un service est connectée à un réseau, il faut l'indiquer dans la définition du service par l'attribut networks

name: nom_de_mon_application

services:
    nom_container_1:
        image: example/webapp
        networks:
            - network_name_1
        secrets:
            - secret_name_1
    
    nom_container_2:
        image: example/backapp
        volumes:
            - volume_name_1:/mount/path/inside/container
        ports:
              - "3000"
              - "3000-3005"
              - "8000:8000"
              - "9090-9091:8080-8081"
              - "127.0.0.1:8001:8001"
              - "6060:6060/udp"    

    nom_container_3:
        image: example/mon-image
        links:
            - nom_container_1
        restart: always 

networks:
    network_name_1:
    
volumes:
    volume_name_1:
        external: true

secrets:
    secret_name_1:
        file: /path/to/file

La première version était un executable à part, docker-compose.

Depuis, les fonctionnalités ont été intégrées à l'executable docker (écrit en Go ?), on a donc docker compose.
Etant donné que c'est la version référencée dans les docs officielles de docker, nous utiliserons celle-ci pour la suite).

# Executer les recettes du fichier dpcker-compose.yml du dossier actuel
# Créer et démarrer les containers
docker compose up --detach
# --detach pour lancer en arrière plan
 
# Stop and remove containers, networks
docker compose down
 
# Pour voir le statut des services définis dans le Compose file
docker compose ps
 
# Start/stop services
docker compose start
docker compose stop
 
# -f : pour spécifier un ou plusieurs Compose files
docker compose -f compose_file_1.yaml -f compose_file_2.yml 
 
# -dry-run : pour voir ce que ça donne sans tout exectuer pour de vrai
docker compose --dry-run up

De nombreuses commande de docker sont aussi présentes pour docker compose, elles s'appliquent aux image/container/volume/network listés dans le Compose file (si j'ai bien compris). On listera : ls, logs, rm, volumes etc.