B2-23 Conteneurs en production : Docker, Compose, Podman

1. Conteneur ou machine virtuelle ?

Une machine virtuelle simule un ordinateur complet : l'hyperviseur lui donne un processeur, de la mémoire et un disque virtuels, et elle démarre son propre système, avec son propre noyau. Un conteneur, lui, n'est qu'un groupe de processus isolés qui tournent directement sur le système hôte et partagent son noyau Linux. L'isolement est assuré par deux mécanismes du noyau : les namespaces, qui cloisonnent ce que le conteneur voit, et les cgroups, qui limitent ce qu'il consomme.

2. Images, couches et registres

Un conteneur est toujours lancé à partir d'une image : un modèle en lecture seule qui contient l'application, ses bibliothèques et la commande à exécuter au démarrage. Une image n'est pas un gros fichier unique, mais un empilement de couches : chaque couche ne contient que les fichiers ajoutés ou modifiés par rapport à la précédente.

2.1 Lire le nom complet d'une image

Le nom docker.io/library/mariadb:11.4 se décompose en quatre morceaux, souvent abrégés : mariadb:11.4 suffit, car Docker Hub et l'organisation library (images officielles) sont pris par défaut.

• docker.ioLe registre, serveur qui stocke et distribue les images : Docker Hub (docker.io), GitHub (ghcr.io), Red Hat (quay.io) ou un registre privé de l'entreprise (Harbor, GitLab).
• library/mariadbLe dépôt : organisation puis nom. library regroupe les images officielles, maintenues et analysées régulièrement.
• :11.4Le tag, une étiquette de version choisie par l'éditeur. Il peut être déplacé : 11.4 pointe toujours vers la dernière correction de la 11.4.
• @sha256:…Le digest, empreinte du contenu exact. Contrairement au tag, il ne change jamais : on l'utilise pour figer une version de façon certaine.

2.2 Construire sa propre image : le Dockerfile

Un Dockerfile décrit la construction d'une image. Le plus souvent, on utilise des images toutes faites ; on écrit un Dockerfile pour empaqueter une application maison.

FROM debian:13-slim
RUN apt-get update && apt-get install -y --no-install-recommends nginx \
    && rm -rf /var/lib/apt/lists/*
COPY site/ /var/www/html/
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

• FROML'image de départ. On choisit une image officielle et légère (-slim, -alpine) : moins de fichiers, moins de failles.
• RUNUne commande exécutée pendant la construction ; elle crée une couche. On enchaîne avec && et on nettoie dans la même ligne pour garder la couche petite.
• COPYCopie des fichiers du projet dans l'image.
• EXPOSEDocumente le port écouté par l'application. N'ouvre rien : la publication se fait au lancement (-p).
• CMDLa commande lancée au démarrage du conteneur. Elle doit rester au premier plan : quand elle s'arrête, le conteneur s'arrête.

3. Installer Docker et lancer un premier conteneur

3.1 Installation sur Debian 13

Debian fournit un paquet docker.io, mais en production on installe le plus souvent Docker Engine depuis le dépôt officiel de Docker, plus à jour, avec le greffon Compose. On ajoute la clé de signature du dépôt, puis le dépôt lui-même :

Le démon dockerd tourne en root et reçoit les ordres de la commande docker par un socket, /var/run/docker.sock. Sans droits sur ce socket, la commande répond permission denied while trying to connect to the Docker daemon socket : on la lance avec sudo. On verra en partie 8 pourquoi ajouter un utilisateur au groupe docker n'est pas anodin.

3.2 Les commandes de base

• -dDétaché : le conteneur tourne en arrière-plan et la commande rend la main.
• --name webUn nom choisi, plus pratique que l'identifiant aléatoire pour logs, exec, stop.
• -p 127.0.0.1:8080:80Publication de port : adresse de l'hôte : port de l'hôte : port du conteneur. Sans adresse, le port est ouvert sur toutes les interfaces de l'hôte.
• --restart unless-stoppedRedémarre le conteneur après un plantage ou un redémarrage de la machine, sauf si on l'a arrêté volontairement.
• nginx:1.28-alpineL'image et son tag, toujours en dernier ; ce qui suit l'image remplace la commande CMD. Vérifie sur le registre la version stable du moment.

3.3 La vie d'un conteneur

Un conteneur ne vit que tant que son processus principal tourne. S'il s'arrête aussitôt démarré, docker ps -a le montre en Exited avec un code de sortie, et docker logs donne presque toujours la raison : variable obligatoire manquante, port déjà pris, fichier de configuration invalide.

4. Garder les données : volumes et montages

Un conteneur est jetable : pour le mettre à jour, on ne le modifie pas, on le supprime et on en recrée un depuis la nouvelle image. Tout ce qu'il a écrit dans sa couche d'écriture disparaît alors. Les données qui doivent durer (base de données, fichiers envoyés par les utilisateurs, configuration) sont donc rangées en dehors du conteneur, dans un volume monté à l'intérieur.

5. Les réseaux des conteneurs

Chaque conteneur reçoit une interface réseau et une adresse privée (par défaut dans 172.17.0.0/16), reliée à un bridge sur l'hôte. Deux règles organisent les échanges :

• Entre conteneurs : sur un réseau créé par l'administrateur (ou par Compose), un DNS interne résout le nom de chaque conteneur. WordPress joint la base par le nom db, jamais par une adresse qui change à chaque recréation. Sur le réseau bridge par défaut, ce DNS n'existe pas.
• Depuis l'extérieur : un conteneur n'est joignable que par les ports publiés (-p). Une base de données ne se publie jamais : seuls les conteneurs de son réseau y accèdent.

6. Docker Compose : décrire une application complète

Avec docker run, une application à deux conteneurs demande deux longues commandes, deux volumes et un réseau à créer dans le bon ordre. Compose décrit tout cela dans un seul fichier YAML, compose.yaml, que l'on range dans un dossier par application (par exemple /opt/actus) et que l'on versionne dans Git. Une seule commande crée ou met à jour l'ensemble.

name: actus
services:
  db:
    image: mariadb:11.4
    restart: unless-stopped
    environment:
      MARIADB_DATABASE: wordpress
      MARIADB_USER: wp
      MARIADB_PASSWORD: ${DB_PASSWORD}          # lu dans le fichier .env
      MARIADB_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
    volumes:
      - db_data:/var/lib/mysql
    networks: [back]
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 10s
      retries: 5

  web:
    image: wordpress:7-apache
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy              # attend que la base soit prête
    environment:
      WORDPRESS_DB_HOST: db                     # le nom du service, pas localhost
      WORDPRESS_DB_USER: wp
      WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - wp_data:/var/www/html
    ports:
      - "127.0.0.1:8081:80"                     # visible seulement depuis l'hôte (Traefik)
    networks: [front, back]

volumes:
  db_data:
  wp_data:

networks:
  front:
  back:
    internal: true                              # aucun accès vers ou depuis l'extérieur

• servicesUn bloc par conteneur. Le nom du service (db, web) sert aussi de nom DNS sur les réseaux du projet.
• image · restartL'image avec un tag de version précis, et la politique de redémarrage (après un plantage ou un redémarrage de la VM).
• environment · ${…}Variables passées à l'application. Les secrets sont lus dans un fichier .env placé à côté, protégé (chmod 600) et jamais versionné.
• volumesMontages du service, et en bas du fichier la déclaration des volumes nommés. Compose les préfixe avec le nom du projet : actus_db_data.
• depends_on · healthcheckOrdre de démarrage. Avec condition: service_healthy, web ne démarre que lorsque le test de santé de db réussit, et pas seulement quand son conteneur existe.
• ports · networksPublication du seul port utile, sur la boucle locale ; deux réseaux : front pour sortir, back interne pour la base.

DB_PASSWORD=mot-de-passe-long-et-aleatoire
DB_ROOT_PASSWORD=autre-mot-de-passe-long-et-aleatoire

7. Publier l'application derrière Traefik

Les utilisateurs ne doivent pas taper http://172.16.50.11:8081 : ils ouvrent https://actus.broceliande.lan. C'est le rôle du reverse proxy Traefik vu en B2-12 : il reçoit les connexions HTTPS, présente le certificat, ajoute les en-têtes de sécurité et transmet à l'application. Comme pour tous les services de Brocéliande, on le configure uniquement par des fichiers dynamiques (file provider) : un fichier par service publié.

http:
  routers:
    actus:
      rule: "Host(`actus.broceliande.lan`)"
      entryPoints: [websecure]
      service: actus
      middlewares: [securite]            # défini dans intranet.yml (B2-12)
      tls: {}

  services:
    actus:
      loadBalancer:
        servers:
          - url: "http://127.0.0.1:8081"   # le port publié par Compose

tls:
  certificates:
    - certFile: /etc/traefik/certs/actus.crt
      keyFile: /etc/traefik/certs/actus.key

Tous les fichiers du dossier forment une seule configuration : un middleware déclaré dans intranet.yml est utilisable dans actus.yml. WordPress sait qu'il est servi en HTTPS grâce à l'en-tête X-Forwarded-Proto: https que Traefik ajoute.

7.1 Variante : Traefik lui-même en conteneur

Si Traefik n'est pas installé sur l'hôte, on peut l'ajouter comme service du projet, toujours avec le file provider. Il rejoint le réseau front et joint l'application par son nom de service : le port de web n'a alors plus besoin d'être publié.

  traefik:
    image: traefik:v3
    restart: unless-stopped
    ports: ["80:80", "443:443"]
    volumes:
      - ./traefik/traefik.yml:/etc/traefik/traefik.yml:ro   # providers.file.directory: /etc/traefik/dynamic
      - ./traefik/dynamic:/etc/traefik/dynamic:ro
      - ./traefik/certs:/etc/traefik/certs:ro
    networks: [front]
# dans ./traefik/dynamic/actus.yml : url: "http://web:80"

8. Sécuriser des conteneurs en production

Un conteneur isole une application, mais il ne la rend pas sûre : il partage le noyau de l'hôte, il tourne souvent en root à l'intérieur, et son image peut contenir des failles connues. La sécurité se joue à quatre niveaux : qui pilote le moteur, d'où viennent les images, comment chaque service est lancé, et comment on l'entretient.

8.1 Qui pilote le moteur ?

Le démon Docker tourne en root. Toute personne qui peut lui parler (membre du groupe docker, ou programme qui a accès à /var/run/docker.sock) peut lancer un conteneur qui monte la racine de l'hôte, et devenir root sur la machine en une ligne :

8.2 Des images de confiance et à jour

• Origine : images officielles (library/) ou d'éditeurs vérifiés ; pour une image maison, un Dockerfile relu, construit à partir d'une image officielle.
• Version : un tag de version précis, jamais latest en production ; on lit les notes de version avant de changer de version majeure.
• Failles connues : on analyse les images avec un scanner, par exemple trivy image wordpress:7-apache ou docker scout cves wordpress:7-apache, qui liste les CVE par gravité.
• Mises à jour : un conteneur ne se met pas à jour avec apt upgrade à l'intérieur (perdu à la recréation). On télécharge la nouvelle image et on recrée : docker compose pull && docker compose up -d, puis docker image prune pour supprimer les anciennes.

8.3 Lancer chaque service avec le minimum de droits

8.4 Secrets et journaux

Les mots de passe ne s'écrivent pas dans compose.yaml : ils vont dans .env (droits 600, listé dans .gitignore), ou mieux dans des secrets Compose, des fichiers montés dans /run/secrets/ que lisent les images officielles grâce aux variables …_FILE (MARIADB_PASSWORD_FILE, WORDPRESS_DB_PASSWORD_FILE). Côté journaux, Docker garde par défaut toute la sortie de chaque conteneur dans un fichier qui grossit sans limite : on fixe une rotation pour tout l'hôte.

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" }
}

9. Podman, l'alternative sans démon

Podman lance les mêmes images OCI avec presque les mêmes commandes, mais sans démon central : chaque conteneur est un processus lancé directement par l'utilisateur qui tape la commande, et supervisé par systemd. Par défaut, il fonctionne en rootless : le root d'un conteneur n'est qu'un utilisateur ordinaire sur l'hôte. C'est l'outil par défaut de Red Hat, AlmaLinux et Rocky Linux, et il est disponible dans Debian 13.

Pour qu'un conteneur Podman démarre avec la machine, on le confie à systemd avec un fichier Quadlet : une unité .container que systemd transforme en service.

[Container]
Image=docker.io/library/nginx:1.28-alpine
PublishPort=127.0.0.1:8082:80
Volume=site:/usr/share/nginx/html:ro

[Service]
Restart=always

[Install]
WantedBy=default.target

10. Dépanner une application conteneurisée

10.1 La boîte à outils

10.2 Le chemin de diagnostic

10.3 Entraîne-toi : les tickets du support

L'application d'actualités est en service depuis un mois. Six tickets arrivent : lis le message, observe le relevé et choisis la cause.

docker run -d --name db --network back -e MARIADB_ROOT_PASSWORD=… mariadb:11.4
docker rm -f db
docker run -d --name db --network back -e MARIADB_ROOT_PASSWORD=… mariadb:11.8

    environment:
      WORDPRESS_DB_HOST: localhost
      WORDPRESS_DB_USER: wp

Error response from daemon: driver failed programming external
connectivity on endpoint actus-web-1: failed to bind host port
0.0.0.0:80/tcp: address already in use

NAMES        IMAGE          PORTS
actus-db-1   mariadb:11.4   0.0.0.0:3306->3306/tcp
actus-web-1  wordpress:7…   127.0.0.1:8081->80/tcp

level=error msg="502 Bad Gateway" error="dial tcp: lookup web on
172.16.50.10:53: no such host" routerName=actus@file

MariaDB [wordpress]> SELECT option_name, option_value FROM wp_options
    -> WHERE option_name IN ('siteurl','home');
siteurl   http://127.0.0.1:8081
home      http://127.0.0.1:8081

11. À l'examen et en entreprise

12. L'essentiel

1. Un conteneur est un groupe de processus isolés (namespaces, cgroups) qui partage le noyau de l'hôte ; une VM a son propre noyau.
2. Une image est un empilement de couches en lecture seule ; le conteneur ajoute une couche d'écriture, perdue à sa suppression.
3. Nom d'image : registre/dépôt:tag ; en production, un tag de version précis, jamais latest.
4. docker run -d --name … -p … -v … image:tag, puis ps, logs, exec, stop, rm.
5. Les données à garder vont dans un volume nommé ; la configuration de l'administrateur dans un montage en :ro.
6. Sur un réseau créé par Compose, les services se joignent par leur nom ; localhost désigne le conteneur lui-même.
7. Publier le minimum, sur 127.0.0.1 derrière un reverse proxy : un port publié contourne le pare-feu de l'hôte.
8. Compose décrit l'application dans compose.yaml + .env ; up -d crée ou met à jour, down -v efface les volumes.
9. Publication par Traefik en fichiers dynamiques : jamais d'étiquettes ni de docker.sock monté.
10. Sécurité : groupe docker = root, images officielles analysées, no-new-privileges, mises à jour par pull + up -d ; Podman offre le mode rootless.

Les commandes clés

Tout cela tient sur une page : utilise le bouton Mémo à imprimer en haut de la fiche.

13. Quiz noté

14. Exercices : à toi de répondre

Écris ta réponse sous chaque énoncé et envoie-la à ton professeur. Quand il l'a validée, le corrigé s'affiche à la place du cadenas ; s'il te la renvoie « à revoir », lis son commentaire et corrige.

services:
  wiki:
    image: requarks/wiki:latest
    ports: ["80:3000"]
    environment:
      DB_HOST: localhost
      DB_PASS: Wiki2026!
  db:
    image: postgres
    ports: ["5432:5432"]
    environment:
      POSTGRES_PASSWORD: Wiki2026!
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

15. Au labo : publier une application web et sa base avec Compose

    security_opt: ["no-new-privileges:true"]
    mem_limit: 512m