Conteneurs en production : Docker, Compose, Podman
Comprendre ce qu'est un conteneur, manipuler images, volumes et réseaux, décrire une application complète avec Compose, la publier derrière Traefik et l'exploiter en sécurité, avec Docker ou Podman.
L'essentiel
- 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.
- Une image est un empilement de couches en lecture seule ; le conteneur ajoute une couche d'écriture, perdue à sa suppression.
- Nom d'image :
registre/dépôt:tag; en production, un tag de version précis, jamaislatest. docker run -d --name … -p … -v … image:tag, puisps,logs,exec,stop,rm.- Les données à garder vont dans un volume nommé ; la configuration de l'administrateur dans un montage en
:ro. - Sur un réseau créé par Compose, les services se joignent par leur nom ;
localhostdésigne le conteneur lui-même. - Publier le minimum, sur
127.0.0.1derrière un reverse proxy : un port publié contourne le pare-feu de l'hôte. - Compose décrit l'application dans
compose.yaml+.env;up -dcrée ou met à jour,down -vefface les volumes. - Publication par Traefik en fichiers dynamiques : jamais d'étiquettes ni de
docker.sockmonté. - Sécurité : groupe
docker= root, images officielles analysées,no-new-privileges, mises à jour parpull+up -d; Podman offre le mode rootless.
À retenir : VM et conteneurs se combinent
En entreprise, on ne choisit pas l'un contre l'autre : les conteneurs tournent presque toujours dans des VM. La VM apporte l'isolement fort et la sauvegarde par l'hyperviseur, les conteneurs apportent la légèreté et la reproductibilité des applications. C'est exactement l'architecture du TP : une VM Debian dans Proxmox, et des conteneurs dedans.
Piège classique : le tag latest
latest n'est pas « la dernière version stable » : c'est seulement le tag utilisé quand on n'en précise aucun. Un docker pull peut donc faire passer une base de données à une version majeure sans prévenir. En production, on précise toujours un tag de version (mariadb:11.4), et on décide quand on change.
Piège classique : un port publié contourne le pare-feu
Pour publier un port, Docker écrit ses propres règles de NAT dans le noyau, avant celles de ton pare-feu (nftables, ufw). Un -p 3306:3306 rend donc la base joignable depuis tout le réseau, même si ton pare-feu « bloque » le 3306. Publie le strict nécessaire, et sur 127.0.0.1 quand un reverse proxy local est devant.
Piège classique : down -v efface les données
docker compose down supprime les conteneurs et les réseaux, mais garde les volumes : on relance avec up -d et tout revient. Avec down -v, les volumes du projet sont supprimés aussi : base et fichiers perdus, sans confirmation. À réserver au labo, après une sauvegarde.
Commandes clés
| Pour… | Commandes |
|---|---|
| Images | docker pull mariadb:11.4 · docker image ls · docker build -t nom:1.0 . |
| Lancer | docker run -d --name web -p 127.0.0.1:8080:80 -v data:/chemin nginx:1.28-alpine |
| Observer | docker ps -a · docker logs -f web · docker exec -it web sh |
| Volumes, réseaux | docker volume ls · docker network create back · docker network inspect back |
| Compose | docker compose config · up -d · ps · logs -f · down |
| Mettre à jour | docker compose pull && docker compose up -d · docker image prune |
| Podman | podman run … · podman ps · podman compose up -d · Quadlet .container |