Utiliser docker-compose

Soumis par lulu le lun 20/02/2023 - 21:39

Qu'est-ce que docker-compose ?

Compose est un outil (écrit essentiellement en Python) permettant de définir et d'exécuter des applications Docker multi-conteneurs. Avec Compose, vous utilisez un fichier YAML pour configurer les services de votre application. Ensuite, avec une seule commande, vous créez et démarrez tous les services à partir de votre configuration.

Compose fonctionne dans tous les environnements : production, staging, développement, test, ainsi que dans les flux de travail CI.

L'utilisation de Docker Compose est essentiellement un processus en trois étapes :

Définissez l'environnement de votre application avec un Dockerfile pour qu'elle puisse être reproduite partout.
Définissez les services qui composent votre application dans un fichier docker-compose.yaml, afin qu'ils puissent être exécutés ensemble dans un environnement isolé.
Enfin, exécutez docker-compose up et Compose démarrera et exécutera l'ensemble de votre application.

docker-compose up : Construit, (re)crée, démarre et attache les conteneurs d'un service. À moins qu'ils ne soient déjà en cours d'exécution, cette commande démarre également tous les services liés. La commande docker-compose up regroupe la sortie de chaque conteneur (essentiellement en exécutant docker-compose logs --follow). Lorsque la commande se termine, tous les conteneurs sont arrêtés.

L'exécution de la commande docker-compose up --detach démarre les conteneurs en arrière-plan et les laisse fonctionner.

Un fichier docker-compose.yml ressemble à ceci :

$ vi docker-compose.yml

version: "3.9"  # optional since v1.27.0
services:
  web:
    build: .
    ports:
      - "5000:5000"
    volumes:
      - .:/code
      - logvolume01:/var/log
    links:
      - redis
  redis:
    image: redis
volumes:
  logvolume01: {}

Compose dispose de commandes permettant de gérer l'ensemble du cycle de vie de votre application :

Démarrer, arrêter et reconstruire les services ;
Afficher l'état des services en cours d'exécution ;
Stream de la sortie du journal des services en cours d'exécution ;
Exécuter une commande ponctuelle sur un service.

Installer Docker Compose

Vous pouvez exécuter Compose sur macOS, Windows et Linux 64 bits. Docker Compose s'appuie sur Docker Engine pour tout travail significatif, alors assurez-vous que Docker Engine est installé localement ou à distance, selon votre configuration.

Sous Linux, vous pouvez télécharger le binaire Docker Compose depuis la page de publication du dépôt Compose sur GitHub. Suivez les instructions du lien, qui impliquent l'exécution de la commande curl dans votre terminal pour télécharger les binaires. Ces instructions étape par étape sont également incluses ci-dessous.

Exécutez cette commande pour télécharger la version stable actuelle de Docker Compose :

# Pour installer une autre version de Compose, remplacez 1.29.2 par la version de Compose que vous souhaitez utiliser.
# La commande suivante installe l'exécutable "docker-compose" dans le répertoire "/usr/local/bin"
$sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

Appliquez les permissions d'exécution au binaire :

$ sudo chmod +x /usr/local/bin/docker-compose

Installez la complétion de commande pour les shells bash et zsh.

# Placez le script de complétion dans /etc/bash_completion.d/.
$ sudo curl \
    -L https://raw.githubusercontent.com/docker/compose/1.29.2/contrib/completion/bash/docker-compose \
    -o /etc/bash_completion.d/docker-compose

Pensez à rechargez votre terminal. Vous pouvez fermer puis ouvrir un nouveau terminal, ou recharger vos paramètres avec la commande source ~/.bashrc dans votre terminal actuel.

Vous pouvez maintenant tester votre installation :

$ docker-compose --version
docker-compose version 1.29.2, build 5becea4c

Pour désinstaller Docker Compose, si vous avez utilisé curl, il suffit de faire :

$ sudo rm /usr/local/bin/docker-compose
$ sudo rm /etc/bash_completion.d/docker-compose

Éléments du fichier docker-compose.yml

docker-compose permet de réaliser une application, conçue comme un ensemble de conteneurs qui doivent fonctionner ensemble avec des ressources partagées et des canaux de communication adéquats.

Les composants informatiques d'une application sont définis comme des services. Un service est un concept abstrait mis en œuvre sur des plateformes en exécutant une ou plusieurs fois la même image de conteneur (et la même configuration).

Les services communiquent entre eux par le biais de réseaux. Dans cette spécification, un réseau est une abstraction de capacité de plate-forme pour établir une route IP entre les conteneurs dans les services connectés ensemble. Les options de mise en réseau de bas niveau, spécifiques à la plate-forme, sont regroupées dans la définition du réseau et PEUVENT être partiellement mises en œuvre sur certaines plates-formes.

Voyons maintenant quelques-unes des options que l'on peut trouver dans un fichier docker-compose.yml (voir aussi documentation complète : https://github.com/compose-spec/compose-spec/blob/master/spec.md) :

services

Un service est une définition abstraite d'une ressource informatique (au sein d'une application), qui peut être modifiée ou remplacée indépendamment des autres composants. Les services s'appuient sur un ensemble de conteneurs, exécutés par la plate-forme en fonction des exigences de réplication et des contraintes de placement ; ils sont donc définis par une image Docker et un ensemble d'arguments d'exécution (runtime). Tous les conteneurs d'un service sont créés de manière identique avec ces arguments.

Un fichier Compose DOIT déclarer un élément racine services sous la forme d'une map dont les clés sont les noms de services, et les valeurs sont des définitions de services. Une définition de service contient la configuration qui est appliquée à chaque conteneur démarré pour ce service.

Chaque service PEUT également inclure une section Build, qui définit comment créer l'image Docker pour le service. Les implémentations Compose PEUVENT prendre en charge la construction d'images Docker à l'aide de cette définition de service. Si elle n'est pas implémentée, la section Build DOIT être ignorée et le fichier Compose DOIT toujours être considéré comme valide (la prise en charge de Build est un aspect FACULTATIF de la spécification Compose).

Chaque service définit les contraintes et les exigences d'exécution de ses conteneurs. La section deploy regroupe ces contraintes et permet à la plateforme d'ajuster la stratégie de déploiement pour faire correspondre au mieux les besoins des conteneurs aux ressources disponibles. La prise en charge de Deploy est un aspect OPTIONNEL de la spécification Compose. Si elle n'est pas implémentée, la section Deploy DOIT être ignorée et le fichier Compose DOIT toujours être considéré comme valide.

Voici un exemple de déclaration de services:

# Élément racine "services" (obligatoire)
services:

  # Nom du premier service
  # (ici "redis" : système de gestion de base de données clé-valeur extensible)
  redis:

    # Définition du service "redis"
    # (ici, on indique l'image qui sera utilisée pour ce service,
    # ainsi que des éléments de configuration de celui-ci)
    image: "redis:alpine"
    configs:
      source: my_config
      target: /redis_config
      uid: "103"
      gid: "103"
      mode: 0440    

  # Nom du deuxième service
  web:

    # Définition du service "web"
    # (ici, on indique où trouver le Dockerfile pour construire l'image
    # et on indique que le service"web" doit être créé après le service "redis")
    build: .docker/web_dir
    depends_on:
      - redis

build

La spécification Compose est étendue pour supporter une sous-section OPTIONNELLE de construction sur les services. Cette section définit les exigences de build pour l'image du conteneur de service. Lorsqu'une sous-section Build est présente pour un service, le fichier Compose peut ne pas avoir d'attribut Image pour le service correspondant, car l'implémentation Compose peut construire l'image à partir du Dockerfile spécifié dans la section Build (dans ce cas, l'image construite portera un nom automatiquement défini). Si les sous-sections build et image sont présentes toutes les deux pour le même service, Compose construit l'image à partir du fichier Dockerfile dont le chemin est indiqué dans build, et nomme cette image d'après le nom trouvé dans la sous-section image.

build spécifie les options de configuration qui sont appliquées au moment de la construction de l'image.

build peut être spécifié comme une chaîne contenant un chemin vers le contexte de build (un Dockerfile canonique est alors recherché à la racine du contexte) ou une url vers un dépôt git. Le chemin du contexte peut être absolu ou relatif, et dans ce cas, le chemin relatif DOIT être résolu à partir du dossier parent du fichier Compose. Comme un chemin absolu empêche le fichier Compose d'être portable, l'implémentation de Compose DEVRAIT en avertir l'utilisateur.

version: "3.9"
services:
  webapp:
    # Un fichier "Dockerfile" doit être présent dans le le répertoire "dir", sous-répertoire relatif au dossier du fichier Compose
    build: ./dir

build peut également être spécifié comme une définition détaillée de la construction. Dans ce cas, des arguments de construction peuvent être spécifiés, y compris un emplacement alternatif pour le fichier Dockerfile. Celui-ci peut être un chemin absolu ou relatif. Si le chemin du fichier Docker est relatif, il DOIT être résolu à partir du chemin du contexte. Comme un chemin absolu empêche la portabilité du fichier Compose, la mise en œuvre de Compose DOIT avertir l'utilisateur si un chemin alternatif absolu du fichier Docker est utilisé.

Les arguments du build sont indiqués dans la sous-section args, ils peuvent ensuite être récupérés dans un fichier Dockerfile. Prenons l'exemple d'un fichier Dockerfile contenant les instructions suivantes :

ARG GIT_COMMIT
RUN echo "Based on commit: $GIT_COMMIT"

Dans ce cas, la valeur de GIT_COMMIT peut être déclarée dans la sous-section args du fichier docker-compose.yml de la manière suivante :

version: "3.9"
services:
  webapp:
    build:
      context: ./dir
      dockerfile: Dockerfile-alternate
      args:
        GIT_COMMIT: cdc3b19

Si vous spécifiez image ainsi que build, alors Compose nomme l'image construite avec la webapp et la balise optionnelle spécifiée dans image :

# Il résulte du code ci-dessous une image nommée webapp et étiquetée tag, construite à partir de ./dir.
version: "3.9" 
services: 
  webapp:
    build: ./dir
    image: webapp:tag

container_name

Spécifiez un nom de conteneur personnalisé, plutôt qu'un nom généré par défaut.

container_name: my-web-container

Comme les noms de conteneurs Docker doivent être uniques, vous ne pouvez pas faire évoluer un service au-delà d'un conteneur si vous avez spécifié un nom personnalisé. Si vous tentez de le faire, vous obtiendrez une erreur.

S'il est présent, le nom du conteneur DOIT suivre le format regex [a-zA-Z0-9][a-zA-Z0-9_.-]+.

restart

no est la politique de redémarrage par défaut, et elle ne redémarre un conteneur en aucune circonstance. Lorsque always est spécifié, le conteneur redémarre toujours. La stratégie on-failure redémarre un conteneur si le code de sortie indique une erreur on-failure. unless-stopped redémarre toujours un conteneur, sauf si le conteneur est arrêté (manuellement ou autrement).

restart: "no"
restart: always
restart: on-failure
restart: unless-stopped

ports

Expose les ports du conteneur. Le mappage des ports NE DOIT PAS être utilisé avec network_mode : host, ce qui entraînerait une erreur d'exécution.

Syntaxe courte

La syntaxe courte est une chaîne séparée par des virgules pour définir l'IP de l'hôte, le port de l'hôte et le port du conteneur sous la forme suivante :

[HÔTE :]CONTAINER[/PROTOCOL]

HOST est de la forme [IP :](port | plage)
CONTAINER est de la forme port | plage
PROTOCOL permet de restreindre le port au protocole spécifié. Les valeurs tcp et udp sont définies par la spécification, les implémentations Compose PEUVENT offrir une prise en charge des noms de protocole spécifiques à la plate-forme.

L'IP de l'hôte, si elle n'est pas définie, DOIT être liée à toutes les interfaces réseau (la valeur de l'IP par défaut, si non définie, est 0.0.0.0, ce qui signifie toutes les interfaces). Le port peut être une valeur unique ou une plage. L'hôte et le conteneur DOIVENT utiliser des plages équivalentes.

Vous pouvez spécifier les deux ports (HÔTE:CONTENEUR) ou seulement le port du conteneur. Dans ce dernier cas, l'implémentation Compose DEVRAIT allouer automatiquement tout port hôte non attribué.

HOST:CONTAINER DOIT toujours être spécifié sous la forme d'une chaîne de caractères (entre guillemets), afin d'éviter les conflits avec le flottant yaml base-60.

Note : Lorsque vous mappez des ports au format HOST:CONTAINER, vous pouvez obtenir des résultats erronés si vous utilisez un port de conteneur inférieur à 60, car YAML analyse les nombres au format xx:yy comme une valeur en base 60. Pour cette raison, nous vous recommandons de toujours spécifier explicitement vos mappages de ports sous forme de chaînes de caractères (avec des guillemets).

ports:
  - "3000"
  - "3000-3005"
  - "8000:8000"
  - "9090-9091:8080-8081"
  - "49100:22"
  - "127.0.0.1:8001:8001"
  - "127.0.0.1:5000-5010:5000-5010"
  - "127.0.0.1::5000
  - "6060:6060/udp"
  - "12400-12500:1240"

Syntaxe longue

La syntaxe longue permet de configurer des champs supplémentaires qui ne peuvent pas être exprimés dans la forme courte.

target : le port du conteneur
published : le port exposé publiquement
host_ip : le mappage de l'IP de l'hôte, non spécifié signifie toutes les interfaces réseau (0.0.0.0)
protocol : le protocole du port (tcp ou udp), non spécifié signifie tout protocole.
mode : host pour publier un port d'hôte sur chaque noeud, ou ingress pour un port à équilibrer en charge.

ports:
  - target: 80
    host_ip: 127.0.0.1
    published: 8080
    protocol: tcp
    mode: host

volumes

volumes permet de monter des chemins d'accès aux hôtes ou des volumes nommés, qui DOIVENT être accessibles par les conteneurs de services.

Si le montage est un chemin sur un hôte et qu'il n'est utilisé que par un seul service, il PEUT être déclaré comme faisant partie de la définition du service au lieu de la clé de volumes de premier niveau.

Pour réutiliser un volume dans plusieurs services, un volume nommé DOIT être déclaré dans la clé de volumes de premier niveau.

La syntaxe courte utilise le format générique [SOURCE :]TARGET[:MODE], où SOURCE peut être un chemin d'accès à l'hôte ou un nom de volume. TARGET est le chemin du conteneur où le volume est monté. Les modes standard sont ro pour "lecture seule" et rw pour "lecture-écriture" (par défaut).

Vous pouvez monter un chemin relatif sur l'hôte, qui se développe relativement au répertoire du fichier de configuration Compose utilisé. Les chemins relatifs doivent toujours commencer par . ou ...

volumes:
  # Spécifier juste un chemin et laisser le moteur créer un volume.
  - /var/lib/mysql

  # Spécifier un mappage de chemin absolu
  - /opt/data:/var/lib/mysql

  # Chemin sur l'hôte, relatif au fichier Compose
  - ./cache:/tmp/cache

  # Chemin relatif à l'utilisateur
  - ~/configs:/etc/configs/:ro

  # Volume nommé
  - datavolume:/var/lib/mysql

La syntaxe de la forme longue (ajoutée dans le format de fichier de la version 3.2) permet de configurer des champs supplémentaires qui ne peuvent pas être exprimés dans la forme courte :

type : le type de montage volume, bind, tmpfs ou npipe
source : la source du montage, un chemin sur l'hôte pour un montage bind, ou le nom d'un volume défini dans la clé des volumes de premier niveau. Non applicable pour un montage tmpfs.
target : le chemin dans le conteneur où le volume est monté.
read_only : flag pour définir le volume comme étant en lecture seule
bind : configure des options de liaison supplémentaires
- propagation : le mode de propagation utilisé pour la liaison
volume : configure des options de volume supplémentaires
- nocopy : flag pour désactiver la copie des données d'un conteneur lorsqu'un volume est créé
tmpfs : configure des options tmpfs supplémentaires
- size : la taille pour le montage tmpfs en octets

version: "3.9"
services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      # volume nommé "mydata"
      - type: volume
        source: mydata
        target: /data
        volume:
          nocopy: true
      # bind mount (répertoire "./static" sur l'hôte)
      - type: bind
        source: ./static
        target: /opt/app/static

networks:
  webnet:

# 'mydata' est également déclaré dans la clé des volumes de premier niveau,
# ainsi le volume peut être utilisé par d'autres services
volumes:
  mydata:

volumes_from

volumes_from monte tous les volumes d'un autre service ou conteneur, en spécifiant éventuellement un accès en lecture seule (ro) ou en lecture-écriture (rw). Si aucun niveau d'accès n'est spécifié, l'accès en lecture-écriture DOIT être utilisé.

La valeur de la chaîne définit un autre service du modèle d'application Compose à partir duquel monter des volumes. Le préfixe container :, s'il est pris en charge, permet de monter des volumes à partir d'un conteneur qui n'est pas géré par l'implémentation Compose.

volumes_from:
  - service_name
  - service_name:ro
  - container:container_name
  - container:container_name:rw

volumes (clé de premier niveau)

La section volumes permet de configurer des volumes nommés qui peuvent être réutilisés par plusieurs services. Voici un exemple d'une configuration à deux services où le répertoire de données d'une base de données est partagé avec un autre service en tant que volume afin qu'il puisse être sauvegardé périodiquement :

services:
  backend:
    image: awesome/database
    volumes:
      - db-data:/etc/data

  backup:
    image: backup-service
    volumes:
      - db-data:/var/lib/backup/data

volumes:
  db-data:

Une entrée sous la clé volumes de premier niveau peut être vide, auquel cas elle utilise la configuration par défaut de la plate-forme pour créer un volume. En option, vous pouvez la configurer avec les clés suivantes : driver, driver_opts, external, labels, name.

image

Spécifiez l'image à partir de laquelle démarrer le conteneur. Il peut s'agir d'un repository/tag ou d'un ID d'image partiel.

image: redis

image: ubuntu:18.04

image: tutum/influxdb

image: example-registry.com:4000/postgresql

image: a4bc65fd

Si l'image n'existe pas, Compose tente de la récupérer, à moins que vous n'ayez également spécifié build, auquel cas il la construit en utilisant les options spécifiées et la marque avec la balise spécifiée.

environment

environment définit les variables d'environnement définies dans le conteneur. environment peut être déclaré via un tableau ou une map. Toute valeur booléenne (true, false, yes, no) DOIT être placée entre guillemets pour éviter qu'elle ne soit convertie en True ou False par l'analyseur YAML.

Les variables d'environnement PEUVENT être déclarées par une seule clé (sans valeur au signe égal). Dans ce cas, les implémentations Compose DEVRAIENT compter sur une interaction de l'utilisateur pour résoudre la valeur. Si elles ne le font pas, la variable est désactivée et sera supprimée de l'environnement du conteneur.

Syntaxe map :

environment :
  RACK_ENV : development
  SHOW : "true"
  USER_INPUT :

Syntaxe tableau :

environment :
  - RACK_ENV=development
  - SHOW=true
  - USER_INPUT

Lorsque env_file et environment sont tous deux définis pour un service, les valeurs définies par environment ont la priorité.

depends_on

depends_on exprime les dépendances de démarrage et d'arrêt entre les services.

Syntaxe courte

La variante de syntaxe courte spécifie uniquement les noms de service des dépendances. Les dépendances de services entraînent les comportements suivants :

Les implémentations Compose DOIVENT créer les services dans l'ordre des dépendances. Dans l'exemple suivant, db et redis sont créés avant web.
Les implémentations Compose DOIVENT supprimer les services dans l'ordre des dépendances. Dans l'exemple suivant, web est supprimé avant db et redis.

Exemple simple :

services:
  web:
    build: .
    depends_on:
      - db
      - redis
  redis:
    image: redis
  db:
    image: postgres

Les implémentations de Compose DOIVENT garantir que les services de dépendance ont été démarrés avant de démarrer un service dépendant.
Les implémentations Compose PEUVENT attendre que les services de dépendance soient "prêts" avant de démarrer un service dépendant.

Syntaxe longue

La syntaxe longue permet de configurer des champs supplémentaires qui ne peuvent pas être exprimés dans la forme courte.

condition : condition sous laquelle la dépendance est considérée comme satisfaite
- service_started : est un équivalent de la syntaxe courte décrite ci-dessus
- service_healthy : spécifie qu'une dépendance doit être "saine" (comme indiqué par healthcheck) avant de démarrer un service dépendant.
- service_completed_successfully : spécifie qu'une dépendance doit être exécutée avec succès avant de démarrer un service dépendant.

Les dépendances de services entraînent les comportements suivants :

Les implémentations Compose DOIVENT créer les services dans l'ordre des dépendances. Dans l'exemple suivant, db et redis sont créés avant web.
Les implémentations Compose DOIVENT attendre que les healthchecks soient passés sur les dépendances marquées avec service_healthy. Dans l'exemple suivant, db est censé être "sain" avant que web ne soit créé.
Les implémentations Compose DOIVENT supprimer les services dans l'ordre des dépendances. Dans l'exemple suivant, web est supprimé avant db et redis.

Exemple simple :

services:
  web:
    build: .
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_started
  redis:
    image: redis
  db:
    image: postgres

Les implémentations Compose DOIVENT garantir que les services de dépendance ont été démarrés avant de démarrer un service dépendant.
Les implémentations de Compose DOIVENT garantir que les services de dépendance marqués avec service_healthy sont "sains" avant de démarrer un service dépendant.

links

links définit un lien réseau vers les conteneurs d'un autre service. Il faut soit spécifier à la fois le nom du service et un alias de lien (SERVICE:ALIAS), soit seulement le nom du service.

web :
  links :
    - db
    - db:database
    - redis

Les conteneurs pour le service lié DOIVENT être accessibles à un nom d'hôte identique à l'alias, ou au nom du service si aucun alias n'a été spécifié.

Les liens ne sont pas nécessaires pour permettre aux services de communiquer - lorsqu'aucune configuration réseau spécifique n'est définie, tout service DOIT être capable d'atteindre tout autre service à son nom sur le réseau par défaut. Si les services déclarent les réseaux auxquels ils sont rattachés, les liens NE DOIVENT PAS remplacer la configuration du réseau et les services qui ne sont pas rattachés à un réseau partagé NE DOIVENT PAS être en mesure de communiquer. Les implémentations de Compose PEUVENT NE PAS avertir l'utilisateur de ce décalage de configuration.

Les liens expriment également une dépendance implicite entre les services de la même manière que depends_on, ils déterminent donc l'ordre de démarrage des services.

networks

networks définit les réseaux auxquels les conteneurs de services sont rattachés, en faisant référence aux entrées de la clé de premier niveau networks.

services:
  some-service:
    networks:
      - some-network
      - other-network

aliases

aliases déclare des noms d'hôtes alternatifs pour ce service sur le réseau. D'autres conteneurs sur le même réseau peuvent utiliser soit le nom du service, soit cet alias pour se connecter à l'un des conteneurs du service.

Puisque les alias sont adaptés au réseau, le même service peut avoir différents alias sur différents réseaux.

Remarque : Un alias à l'échelle du réseau peut être partagé par plusieurs conteneurs, et même par plusieurs services. Si c'est le cas, il n'est pas garanti de savoir exactement à quel conteneur le nom se résout.

Le format général est présenté ici :

services:
  some-service:
    networks:
      some-network:
        aliases:
          - alias1
          - alias3
      other-network:
        aliases:
          - alias2

Dans l'exemple ci-dessous, le service frontend pourra atteindre le service backend au nom d'hôte backend ou database sur le réseau back-tier, et le service monitoring pourra atteindre le même service backend à db ou mysql sur le réseau admin.

services:
  frontend:
    image: awesome/webapp
    networks:
      - front-tier
      - back-tier

  monitoring:
    image: awesome/monitoring
    networks:
      - admin

  backend:
    image: awesome/backend
    networks:
      back-tier:
        aliases:
          - database
      admin:
        aliases:
          - mysql

networks:
  front-tier:
  back-tier:
  admin:

networks (clé de premier niveau)

Les networks sont la couche qui permet aux services de communiquer entre eux. Le modèle de réseau exposé à un service est limité à une simple connexion IP avec les services cibles et les ressources externes, tandis que la définition du réseau permet d'affiner l'implémentation réelle fournie par la plate-forme.

Les réseaux peuvent être créés en spécifiant le nom du réseau dans une section de réseaux de premier niveau. Les services peuvent se connecter aux réseaux en spécifiant le nom du réseau dans la sous-section des réseaux de services.

Dans l'exemple suivant, au moment de l'exécution, les réseaux front-tier et back-tier seront créés et le service frontend sera connecté au réseau front-tier et au réseau back-tier.

services:
  frontend:
    image: awesome/webapp
    networks:
      - front-tier
      - back-tier

networks:
  front-tier:
  back-tier:

driver

driver indique quel pilote doit être utilisé pour ce réseau. Les implémentations Compose DOIVENT renvoyer une erreur si le pilote n'est pas disponible sur la plate-forme.

driver: overlay

Les valeurs par défaut et disponibles sont spécifiques à la plate-forme. La spécification Compose DOIT prendre en charge les pilotes spécifiques suivants : none et host

host utilise la pile réseau de l'hôte
none désactive la mise en réseau

La syntaxe d'utilisation des réseaux intégrés tels que host et none est différente, car ces réseaux existent implicitement en dehors de la portée de l'implémentation Compose. Pour les utiliser, on DOIT définir un réseau externe avec le nom host ou none et un alias que l'implémentation Compose peut utiliser (hostnet ou nonet dans les exemples suivants), puis accorder au service l'accès à ce réseau en utilisant son alias.

services:
  web:
    networks:
      hostnet: {}

networks:
  hostnet:
    external: true
    name: host

services:
  web:
    ...
    networks:
      nonet: {}

networks:
  nonet:
    external: true
    name: none

La spécification Compose fournit également par défaut les drivers bridge et overlay :

bridge : Le pilote réseau par défaut. Si vous ne spécifiez pas de pilote, il s'agit du type de réseau que vous créez. Les réseaux bridge sont généralement utilisés lorsque vos applications s'exécutent dans des conteneurs autonomes qui doivent communiquer.
overlay : Les réseaux superposés connectent plusieurs démons Docker ensemble et permettent aux services de l'essaim (swarm services) de communiquer entre eux. Vous pouvez également utiliser les réseaux superposés pour faciliter la communication entre un service d'essaimage et un conteneur autonome, ou entre deux conteneurs autonomes sur différents démons Docker. Cette stratégie supprime la nécessité d'effectuer un routage au niveau du système d'exploitation entre ces conteneurs.
host : pour les conteneurs autonomes, supprimez l'isolation réseau entre le conteneur et l'hôte Docker, et utilisez directement le réseau de l'hôte.
none : Pour ce conteneur, désactivez tous les réseaux. Généralement utilisé en conjonction avec un pilote réseau personnalisé. none n'est pas disponible pour les services swarm.

networks:
  my-network:
    driver: bridge

user

user remplace l'utilisateur utilisé pour exécuter le processus du conteneur. La valeur par défaut est celle définie par l'image (c'est-à-dire Dockerfile USER), si elle n'est pas définie, c'est root.

Quelques commandes utiles

docker-compose up : démarre les services décrits dans mon docker-compose.yml et ne me rend pas la main.
docker-compose up -d : fait la même chose mais me rend la main une fois que les services sont démarrés (-d : detached mode).
docker-compose stop : permet de stopper l'ensemble des services en cours d'exécution (utile lorsque compose a été lancé en mode détaché, comme indiqué ci-dessus).
docker-compose ps : liste les conteneurs en cours d'exécution.

$ docker-compose ps

       Name                      Command               State                    Ports                  
-------------------------------------------------------------------------------------------------------
composetest_redis_1   docker-entrypoint.sh redis ...   Up      6379/tcp                                
composetest_web_1     flask run                        Up      0.0.0.0:5000->5000/tcp,:::5000->5000/tcp

docker-compose up --build : reconstruit les images avant de lancer les conteneurs.
docker-compose down : stoppe les services et supprime les ressources.
docker-compose restart : redémarre l’ensemble des services.
docker-compose restart nginx : redémarre un des services (ici nginx).
docker-compose exec rails bash : me fournit une console bash au sein du conteneur rails (exec exécute une commande dans un conteneur en cours d'exécution).
docker-compose exec rails bin/rails db:migrate : effectue un rails db:migrate au sein du conteneur rails.
docker-compose exec redis env : exécute la commande env sur le service redis en cours d'exécution

$ docker-compose exec redis env

REDIS_VERSION=6.2.5
REDIS_DOWNLOAD_URL=http://download.redis.io/releases/redis-6.2.5.tar.gz
REDIS_DOWNLOAD_SHA=4b9a75709a1b74b3785e20a6c158cab94cf52298aa381eea947a678a60d551ae

docker-compose run redis env : permet d'exécuter la commande env sur le service redis alors que celui-ci est arrêté.

$ docker-compose run redis env

Creating network "composetest_default" with the default driver
Creating composetest_redis_run ... done
REDIS_DOWNLOAD_SHA=4b9a75709a1b74b3785e20a6c158cab94cf52298aa381eea947a678a60d551ae
REDIS_DOWNLOAD_URL=http://download.redis.io/releases/redis-6.2.5.tar.gz
REDIS_VERSION=6.2.5

docker-compose logs : me retourne l’ensemble des logs des services depuis le dernier démarrage et me rend la main.
docker-compose logs -f : affiche les logs des services et continue à les « écouter » sans me rendre la main.
docker-compose logs -f rails : fait la même chose pour le conteneur rails uniquement.