Docker — images, conteneurs et volumes

1Pourquoi des conteneurs

« Ça marche chez moi. » La phrase est une plaisanterie de métier, et elle décrit un vrai problème : un programme ne dépend pas que de son code. Il dépend d'une version de bibliothèque, d'un fichier de configuration, d'une variable d'environnement, d'une version de système. Déplacez-le, il casse.

Conteneur ou machine virtuelle ?

Le chapitre 6 montait des machines virtuelles sous VirtualBox. Ce n'est pas un concurrent : on fait souvent tourner des conteneurs dans une machine virtuelle. Ce qui change, c'est l'unité qu'on déplace.

2Installer Docker

L'installation n'est pas la même selon la machine, et c'est la première chose qui bloque un TP. Choisissez votre système : le reste du chapitre est identique pour tout le monde, parce que les commandes docker sont les mêmes partout.

brew install --cask docker

wsl --install
wsl --set-default-version 2

# 1. retirer d'eventuels paquets concurrents
for p in docker.io docker-doc docker-compose podman-docker containerd runc; do
    sudo apt-get remove -y $p
done

# 2. la cle de signature du depot Docker
sudo apt-get update
sudo apt-get install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# 3. le depot
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
https://download.docker.com/linux/debian $(. /etc/os-release && echo $VERSION_CODENAME) stable" \
| sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# 4. l'installation
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io \
                        docker-buildx-plugin docker-compose-plugin

sudo usermod -aG docker $USER
# il faut FERMER puis rouvrir la session pour que le groupe soit pris en compte
newgrp docker        # ou, pour le terminal courant seulement

sudo systemctl status docker
sudo systemctl enable --now docker   # le demarrer, et au demarrage de la machine

curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh

Vérifier l'installation, partout pareil

docker --version
docker info

docker --version ne prouve qu'une chose : la commande est installée. docker info prouve que le moteur répond — et c'est lui qu'il faut regarder. Deux lignes de sa sortie méritent d'être notées avant de commencer : Containers et Images. Sur une installation neuve, elles valent zéro — et les relever maintenant permet, à la fin, de voir ce qu'on a oublié de nettoyer.

TP d'initiation — question 1.1.

Le premier conteneur

docker run hello-world

La première fois, Docker annonce Unable to find image 'hello-world:latest' locally, puis télécharge l'image. Relancez la même commande : ces lignes disparaissent et l'exécution est instantanée — l'image est désormais dans le cache local.

C'est la première leçon du chapitre, et elle a une conséquence pratique immédiate : le temps de la première exécution est presque entièrement du téléchargement, pas du démarrage. Un conteneur, lui, démarre en quelques dizaines de millisecondes. Sur un serveur, on fait donc le docker pull avant la fenêtre de déploiement, pour que la bascule soit immédiate.

TP d'initiation — question 1.2.

3Image, conteneur, volume

Tout le chapitre tient dans ces trois mots, et une seule propriété les sépare : qu'est-ce qui survit ?

4Les images

docker pull alpine          # telecharger, sans executer
docker pull nginx
docker pull httpd           # le serveur Apache
docker images               # lister celles qui sont ici
docker rmi httpd            # en supprimer une

docker images donne cinq colonnes. Les quatre premières suffisent à identifier une image sans ambiguïté :

Le tag : une image, plusieurs versions

docker pull nginx:1.21      # une version precise et ancienne
docker images               # DEUX lignes « nginx » maintenant

Deux lignes apparaissent, de même REPOSITORY et de TAG différents : latest et 1.21, avec deux IMAGE ID distincts. La leçon tient en une phrase — le tag fait partie de l'identité de l'image. nginx et nginx:1.21 ne désignent pas la même chose, et docker rmi nginx ne supprime que la première.

TP d'initiation — question 2.4.

5Les conteneurs

Entrer dedans

docker run -it alpine sh

-i garde l'entrée ouverte, -t alloue un terminal : ensemble, ils donnent un shell interactif. À l'intérieur, ls et cat /etc/os-release montrent qu'on est bien dans une Alpine, puis exit rend la main — et arrête le conteneur, puisque son processus principal était ce shell.

docker ps        # ceux qui tournent
docker ps -a     # TOUS, y compris les arretes

Le lancer en arrière-plan, et le nommer

docker run -d --name mon-serveur nginx

-d (detached) rend la main immédiatement ; --name donne un nom lisible, qu'on emploiera partout à la place de l'identifiant. Sans lui, Docker invente quelque chose comme nostalgic_hopper.

docker ps -a --filter name=mon-serveur     # son statut, sans lire toute la liste
docker inspect -f '{{.State.Status}}' mon-serveur

La question 3.4 demande le statut « sans utiliser docker ps » : docker inspect est la réponse attendue. Il rend toute la fiche du conteneur en JSON, et -f n'en extrait qu'un champ.

Lire les journaux, et travailler dedans

docker logs mon-serveur            # ce que le conteneur a ecrit
docker logs -f mon-serveur         # et le suivre en direct

docker exec -it mon-serveur bash   # ouvrir un shell DANS un conteneur deja lance

Arrêter, redémarrer, supprimer

docker stop mon-serveur     # demande poliment l'arret, puis force apres 10 s
docker start mon-serveur    # redemarre LE MEME conteneur
docker restart mon-serveur

docker rm mon-serveur       # supprime — le conteneur doit etre arrete
docker rm -f mon-serveur    # ... ou alors on force

6Exposer un port

Un conteneur nginx écoute sur le port 80 — chez lui. Tant qu'on ne publie rien, ce port n'est joignable depuis la machine hôte par aucun navigateur.

docker run -d --name web  -p 8080:80 nginx
docker run -d --name web2 -p 8081:80 nginx

On lit -p hôte:conteneur — de gauche à droite, du dehors vers le dedans. Le premier nombre est celui qu'on tape dans le navigateur, le second celui sur lequel le service écoute à l'intérieur.

curl http://localhost:8080       # ou simplement ouvrir la page

docker: Error response from daemon: driver failed programming external
connectivity on endpoint web3: Bind for 0.0.0.0:8080 failed: port is already allocated.

7Faire survivre les données

Le TP l'a montré à l'étape 3.8 : supprimez le conteneur, et la page d'accueil modifiée disparaît avec lui. C'est le comportement voulu — un conteneur est jetable. Mais une base de données jetable n'a aucun intérêt.

docker volume create donnees-web

docker run -d --name web-persistant -p 8082:80 \
           -v donnees-web:/usr/share/nginx/html nginx

On lit -v nom:/chemin — le volume, puis l'endroit où il est monté dans le conteneur. Tout ce qui est écrit sous /usr/share/nginx/html va désormais dans le volume, pas dans le conteneur.

docker exec -it web-persistant bash
# cd /usr/share/nginx/html && echo "Bonjour NetSolutions" > index.html && exit

docker stop web-persistant && docker rm web-persistant      # on DETRUIT le conteneur

docker run -d --name web-persistant-v2 -p 8082:80 \
           -v donnees-web:/usr/share/nginx/html nginx       # un AUTRE conteneur

La page modifiée est toujours là. C'est la question 5.4, et la démonstration est complète : le volume ne dépend d'aucun conteneur. Il leur survit, et plusieurs conteneurs peuvent monter le même.

docker volume ls
docker volume inspect donnees-web     # ou il est range sur l'hote
docker volume rm donnees-web          # apres avoir supprime les conteneurs qui l'utilisent

8Nettoyer

docker ps -a                       # tout ce qui reste
docker stop $(docker ps -q)        # arreter tout ce qui tourne
docker rm $(docker ps -aq)         # supprimer tous les conteneurs
docker rmi $(docker images -q)     # supprimer toutes les images

-q (quiet) ne rend que les identifiants, un par ligne : c'est ce qui permet de passer la liste à la commande suivante. Sans lui, on passerait aussi les en-têtes de colonnes.

Les commandes de ménage de Docker

docker container prune     # les conteneurs arretes
docker image prune         # les images sans nom (« dangling »)
docker image prune -a      # TOUTES les images inutilisees
docker volume prune        # les volumes qu'aucun conteneur n'utilise
docker system prune        # les trois premiers d'un coup
docker system df           # ce que tout cela occupe

9Le réseau : comment les conteneurs se parlent

Un conteneur seul ne sert presque jamais : il y a un site et sa base, une application et son cache. La question devient alors comment ils se trouvent — et la réponse dépend entièrement d'un choix qu'on fait sans s'en rendre compte, celui du réseau.

Les trois réseaux livrés avec Docker

docker network ls

NETWORK ID     NAME      DRIVER    SCOPE
6bca5b86a5e3   bridge    bridge    local
a647ec3084f5   host      host      local
b002c30b9b60   none      null      local

Le réseau par défaut a deux défauts, et ils vont ensemble

Deux conteneurs lancés sans rien préciser atterrissent sur bridge. Ils se joignent par adresse — et seulement par adresse :

$ docker exec c1 ping -c 2 172.17.0.3
64 bytes from 172.17.0.3: seq=0 ttl=64 time=0.110 ms

$ docker exec c1 ping -c 2 c2
ping: bad address 'c2'

Or ces adresses ne tiennent pas. Arrêtez les deux conteneurs, redémarrez-les dans l'autre ordre : ils échangent leurs adresses. L'adresse ne suit pas le conteneur, elle suit l'ordre de démarrage.

Un réseau qu'on crée soi-même règle les deux

docker network create --subnet 192.168.50.0/24 --gateway 192.168.50.254 reseau-lan
docker run -dit --name c1 --network reseau-lan alpine
docker run -dit --name c2 --network reseau-lan alpine
docker exec c1 ping -c 2 c2

PING c2 (192.168.50.2): 56 data bytes
64 bytes from 192.168.50.2: seq=0 ttl=64 time=0.097 ms

Sur un réseau personnalisé, Docker active un résolveur interne à l'adresse 127.0.0.11, qui connaît le nom de chaque conteneur du réseau. Le nom devient l'identité stable que l'adresse n'était pas. C'est la raison pour laquelle, en production, on ne laisse jamais les conteneurs sur le réseau par défaut.

docker: Error response from daemon: invalid config for network bridge:
user-specified IP address is supported on user-defined networks only

Deux réseaux ne se parlent pas — et un conteneur à deux pattes ne les relie pas

Chaque réseau est un commutateur séparé. Un conteneur de reseau-lan ne joint pas un conteneur de reseau-srv, bien qu'ils soient sur la même machine : il n'a ni route ni routeur. On peut raccorder un conteneur aux deux :

docker network connect reseau-srv passerelle

11: eth0   inet 192.168.50.3/24 ... (reseau-lan)
12: eth1   inet 172.16.10.2/24 ... (reseau-srv)

Il parle alors aux deux côtés. Mais les autres ne passent toujours pas à travers lui : parler n'est pas router. Il faudrait activer le transfert de paquets sur ce conteneur et donner une route au client et une route de retour au serveur. C'est exactement le TP de routage, transposé.

Publier un port, c'est percer une frontière

Un conteneur du même réseau atteint un serveur sans aucune option. Le navigateur de la machine, lui, ne l'atteint pas : il est dehors.

$ docker exec passerelle wget -qO- http://serveur     ->  la page nginx
$ curl http://localhost:8080                          ->  Connection refused

docker run -d --name serveur-pub --network reseau-srv -p 8080:80 nginx

-p ne sert donc jamais à faire communiquer deux conteneurs — seulement à ouvrir un passage depuis la machine. Et ce passage est plus large qu'il n'y paraît :

$ docker port serveur-pub
80/tcp -> 0.0.0.0:8080

Les sept parties du TP réseau corrigé reprennent tout ceci commande par commande, avec les sorties obtenues sur une machine.

10L'aide-mémoire