Aller au contenu
Réussir mon BTS SIO

Tape une notion, une commande ou le nom d'une épreuve.

Par exemple

Chapitre 213 minIntermédiaire

Installer Docker Engine sur Debian 13

Par Josselyn C., prof de BTS SIO. Mis à jour le .

À la fin de ce chapitre, tu sauras

  • installer Docker Engine et Compose depuis le dépôt officiel de Docker ;
  • vérifier le service et lancer un premier conteneur ;
  • régler la rotation des journaux et les plages réseau dans daemon.json ;
  • expliquer pourquoi le groupe docker et les ports publiés sont des risques.

3 exercices corrigés

Installer Docker sur un serveur, c'est ajouter le dépôt officiel de Docker au gestionnaire de paquets, installer le moteur (Docker Engine) et ses extensions (Buildx, Compose), puis régler le service et les droits. Ce chapitre installe Docker Engine 29 sur srv-gestion, une VM Debian 13 « Trixie », règle la rotation des journaux, explique le piège du groupe docker et celui du pare-feu, et présente Docker Desktop pour ton poste de travail.

Quel paquet installer ?

PaquetOrigineQuand l'utiliser
docker-ce et ses compagnonsDépôt officiel de Docker (download.docker.com)Sur un serveur : version récente, mises à jour de sécurité rapides, Compose et Buildx à jour. C'est le choix de ce cours.
docker.ioDépôt de DebianPossible, mais la version est celle figée à la sortie de Debian, avec des extensions plus anciennes. Ne mélange jamais les deux.
Docker DesktopSite de DockerSur ton poste Windows ou macOS, pour développer ; pas sur un serveur.
Script get.docker.comSite de DockerPratique pour un essai jetable ; Docker le déconseille en production.

Préparer la machine

Chez Sorbier, srv-gestion est une VM Proxmox VE : 2 processeurs virtuels, 4 Go de mémoire, un disque système de 32 Go et un second disque de 50 Go monté sur /var/lib/docker, là où Docker range images, conteneurs et volumes. Séparer ce dossier évite qu'une image trop grosse ou des journaux qui débordent remplissent la partition système. L'adresse est fixe : 192.168.10.179/28, passerelle 192.168.10.190, DNS 192.168.10.177 et 192.168.10.181, ceux de l'annuaire, pour que les conteneurs résolvent aussi les noms internes en ad.sorbier.example.

Ajouter le dépôt officiel et installer

Commence par retirer d'éventuels paquets non officiels qui entreraient en conflit (la commande ne fait rien s'ils sont absents) :

bash
sudo apt remove $(dpkg --get-selections docker.io docker-compose docker-doc docker-buildx podman-docker containerd runc | cut -f1)

Installe les outils nécessaires et la clé qui signe les paquets de Docker :

bash
sudo apt update
sudo apt install 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

Déclare le dépôt dans un fichier au format DEB822, le format des sources de Debian 13 :

bash
sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/debian
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

Sur srv-gestion, le shell remplace $(…) au moment de l'écriture : le fichier obtenu contient Suites: trixie et Architectures: amd64. Installe enfin le moteur et ses extensions :

bash
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
PaquetContenu
docker-ceLe démon dockerd
docker-ce-cliLe client docker
containerd.iocontainerd et runc
docker-buildx-pluginBuildx, le moteur de construction des images (BuildKit)
docker-compose-pluginCompose, la commande docker compose

Vérifier l'installation

Sur Debian, le service démarre tout seul et il est activé au démarrage :

bash
sudo systemctl status docker
text
● docker.service - Docker Application Container Engine
     Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-11-03 09:14:22 CET; 2min ago

Les versions du client et du serveur :

bash
sudo docker version --format '{{.Client.Version}} / {{.Server.Version}}'
docker compose version
text
29.9.3 / 29.9.3
Docker Compose version v5.6.0

Le premier conteneur, l'image de test officielle :

bash
sudo docker run --rm hello-world
text
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
...
Hello from Docker!
This message shows that your installation appears to be working correctly.

Docker n'avait pas l'image : il l'a téléchargée depuis Docker Hub, a créé un conteneur, l'a lancé, puis l'option --rm l'a supprimé à la fin.

Le groupe docker et ses dangers

Le socket du démon appartient à root et au groupe docker. Sans sudo, un utilisateur ordinaire reçoit un refus d'accès qui contient permission denied et le chemin unix:///var/run/docker.sock.

La documentation propose d'ajouter l'utilisateur au groupe docker (puis de se reconnecter) :

bash
sudo usermod -aG docker chloe.lambert

Régler le démon : /etc/docker/daemon.json

Le démon lit ses réglages dans /etc/docker/daemon.json (absent par défaut). Chez Sorbier, on fixe quatre choses :

json
{
  "log-driver": "local",
  "log-opts": {
    "max-size": "20m",
    "max-file": "5"
  },
  "live-restore": true,
  "bip": "172.17.0.1/16",
  "default-address-pools": [
    { "base": "172.20.0.0/14", "size": 24 }
  ]
}
RéglageEffet
log-driver: local et log-optsLes journaux de chaque conteneur tournent : au plus 5 fichiers de 20 Mo, compressés. Avec le pilote par défaut json-file sans rotation, les journaux grossissent jusqu'à remplir le disque (chapitre 10).
live-restore: trueLes conteneurs continuent de tourner pendant un redémarrage ou une mise à jour du démon.
bipFixe l'adresse du pont par défaut docker0 (172.17.0.1/16) ; sans ce réglage, Docker la prendrait dans default-address-pools.
default-address-poolsLes réseaux que Docker crée prennent des sous-réseaux en /24 dans 172.20.0.0/14 (de 172.20.0.0 à 172.23.255.255), une plage que Sorbier n'utilise nulle part (ses réseaux sont en 192.168.10.0/24, 192.168.20.0/24 pour l'entrepôt de Mâcon et 10.8.0.0/24 pour le VPN). Docker ne risque plus de choisir une plage qui masquerait un réseau de l'entreprise.

Applique et vérifie :

bash
sudo systemctl restart docker
sudo docker info --format '{{.LoggingDriver}}'
text
local

Docker et le pare-feu

Quand tu publies un port (-p 8080:80), Docker ajoute lui-même des règles de filtrage et de NAT au noyau. Ces règles passent avant celles d'ufw ou de firewalld : un port publié est joignable depuis le réseau même si ton pare-feu local semble le bloquer. La documentation de Docker le dit noir sur blanc : les ports exposés contournent les règles d'ufw et de firewalld.

Trois parades, à combiner :

  • ne publier que ce qui doit l'être, et sur la bonne adresse : -p 127.0.0.1:8080:80 n'écoute que sur la boucle locale, inaccessible depuis le réseau (chapitre 7) ;
  • placer tes règles locales dans la chaîne DOCKER-USER, que Docker consulte avant ses propres règles et ne modifie jamais ;
  • filtrer surtout en amont, sur le pare-feu de l'entreprise : chez Sorbier, le pfSense ne laisse entrer dans le VLAN serveurs que les flux prévus (cours Cybersécurité des infrastructures).

Mettre à jour Docker

Docker Engine se met à jour comme n'importe quel paquet :

bash
sudo apt update && sudo apt upgrade

Avec live-restore, les conteneurs ne s'arrêtent pas pendant le redémarrage du démon. Lis tout de même les notes de version avant une nouvelle version majeure (29 → 30) : chaque version majeure retire des fonctions dépréciées.

Docker Desktop sur ton poste

Pour développer sur Windows 11 ou macOS, installe Docker Desktop depuis le site de Docker.

  • Windows : Docker Desktop s'appuie sur WSL 2 (le sous-système Linux de Windows). L'installeur l'active si besoin ; la virtualisation doit être activée dans le BIOS ou l'UEFI. Tape ensuite tes commandes dans PowerShell ou dans ta distribution WSL : elles sont identiques.
  • macOS : Docker Desktop lance une petite VM Linux grâce au framework de virtualisation d'Apple. Sur un Mac à processeur Apple Silicon, les images sont construites pour l'architecture arm64 : pense à --platform linux/amd64 si l'image doit tourner sur un serveur x86-64 (chapitre 12).

Dans les deux cas, docker run démarre des conteneurs Linux, dans la VM cachée. C'est pourquoi une image construite sur ton poste tourne à l'identique sur srv-gestion.

Exercices

Exercice 1 sur 3 Lire un fichier de dépôt Réussi À revoir

Un collègue a écrit à la main ce fichier /etc/apt/sources.list.d/docker.sources sur une VM Debian 13. apt update échoue sur ce dépôt. Trouve les deux erreurs.

text
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: bookworm
Components: stable
Signed-By: /etc/apt/keyrings/docker.asc
Voir la réponseMasquer la réponse de l'exercice 1
  1. L'adresse vise le dépôt Ubuntu : il faut https://download.docker.com/linux/debian.
  2. La suite est bookworm, le nom de Debian 12 : sur Debian 13, c'est trixie. La commande $(. /etc/os-release && echo "$VERSION_CODENAME") évite justement de se tromper.

La ligne Architectures est absente, ce qui n'est pas une erreur : APT prend alors l'architecture du système. La documentation l'ajoute pour être explicite.

Tu avais trouvé ?

Exercice 2 sur 3 Le stagiaire et le groupe docker Réussi À revoir

Pour éviter de taper sudo, un stagiaire propose d'ajouter au groupe docker le compte svc-deploy, utilisé par un script de déploiement dont le mot de passe est partagé par trois personnes. Explique le risque à Antoine Mercier et propose deux solutions.

Voir la réponseMasquer la réponse de l'exercice 2

Le groupe docker donne un accès équivalent à root : n'importe quel membre peut lancer un conteneur qui monte la racine de l'hôte, lire /etc/shadow ou ajouter une clé SSH à root, sans passer par sudo, donc sans trace dans ses journaux. Un compte au mot de passe partagé ne permet en plus d'imputer aucune action à une personne.

Solutions possibles :

  • garder sudo, avec une règle sudoers qui n'autorise au compte de déploiement que la commande précise dont il a besoin (par exemple docker compose dans le dossier de l'application), et des comptes nominatifs pour les humains ;
  • faire tourner l'application en mode rootless sous un compte dédié, dont le démon n'a pas les droits root ;
  • à terme, déployer depuis la CI avec une clé SSH dédiée et restreinte, plutôt qu'avec un mot de passe partagé.

Tu avais trouvé ?

Exercice 3 sur 3 Le port qui ne devait pas être ouvert Réussi À revoir

Sur srv-gestion, ufw est actif et n'autorise que SSH (22) et HTTPS (443). Un technicien lance un outil d'administration de base de données avec docker run -d -p 8081:8080 adminer. Depuis un poste du VLAN 10, http://192.168.10.179:8081 répond. Explique pourquoi et corrige.

Voir la réponseMasquer la réponse de l'exercice 3

Un port publié par Docker est traité par les règles que Docker ajoute lui-même au noyau, avant celles d'ufw : le refus d'ufw ne s'applique pas. Le port 8081 est donc ouvert à tout le réseau.

Corrections, de la plus simple à la plus complète :

  • publier sur la boucle locale seulement, -p 127.0.0.1:8081:8080, et y accéder par un tunnel SSH depuis le poste d'administration ;
  • ne pas publier du tout, et passer par le reverse proxy avec une authentification ;
  • ajouter une règle dans la chaîne DOCKER-USER, et vérifier que le pfSense ne laisse arriver sur srv-gestion que le port 443 depuis les postes.

Un outil d'administration de base de données n'a de toute façon rien à faire en écoute permanente sur un serveur de production.

Tu avais trouvé ?

Chapitre terminé !

Fais les 3 exercices avant de passer à la suite : c'est en t'entraînant que tout se fixe.

chapitres
–
de série
–
du cours
–
Chapitre suivant : Les commandes Docker essentielles : run, ps, logs, execRevoir le sommaire du cours