Docker (2/9) — Le conteneur, par la preuve

L’idée reçue

« Un conteneur, c’est une petite machine virtuelle. »

C’est l’image qu’on a presque tous au début. Le souci : elle est fausse — et elle te poussera à de mauvaises décisions plus tard (sécurité, taille des images, réseau…). Plutôt que de te le dire, on va le démonter ensemble, commande par commande.

À la fin de ce module, tu sauras…

Lancer un conteneur et entrer dedans
Prouver, sans me croire sur parole, qu’un conteneur n’est pas une VM
Expliquer « noyau partagé » et « userspace isolé » concrètement
Comprendre pourquoi un conteneur « meurt » quand son processus principal s’arrête

01Entre dans le conteneur

Expérience 1

Ouvre une porte et regarde à l’intérieur

Manipule

docker run -it debian bash

Observe

root@3f9a1c2b7d04:/#

Tu es maintenant root dans un Debian. Tape cat /etc/os-release : tu lis « Debian ». C’est un système complet, en apparence — et il a démarré instantanément.

Comprends ouvre après avoir essayé

Tu viens de créer un conteneur à partir de l’image debian, et d’y ouvrir un shell interactif (-it = interactive + terminal). L’environnement « ressemble » à un Debian complet. Garde cette impression en tête — on l’explique dans deux expériences.

02Est-ce vraiment une machine ?

Expérience 2

Compte les processus qui tournent

Manipule

ps aux

Observe

USER   PID  %CPU %MEM   COMMAND
root     1   0.0  0.1   bash
root    10   0.0  0.1   ps aux

Deux processus. C’est tout. Une vraie machine en aurait des dizaines : systemd, services réseau, journaux… Ici, rien de tout ça.

Comprends qu’est-ce que ça révèle ?

Un conteneur ne démarre pas un système d’exploitation. Il lance un seul processus (ici bash), qui porte le PID 1. Pas de boot, pas de ribambelle de services. Première grande différence avec une VM.

03À qui appartient le noyau ?

Expérience 3

Compare le noyau, dedans puis dehors

Manipule

uname -r

Note la version, tape exit pour sortir, puis relance uname -r sur la VM hôte.

Observe

6.12.x-amd64    # dans le conteneur
6.12.x-amd64    # sur l'hôte  ->  IDENTIQUE

Le conteneur et l’hôte affichent exactement le même noyau. Ce n’est pas une coïncidence.

Comprends le cœur du module

Un conteneur n’a pas son propre noyau. Il emprunte celui de l’hôte. C’est la différence fondamentale avec une VM : une VM embarque son propre noyau (et un OS complet) au-dessus d’un hyperviseur ; un conteneur partage le noyau de l’hôte. D’où son démarrage en une fraction de seconde et son poids de quelques mégaoctets.

04Alors pourquoi « Debian » à l’intérieur ?

Expérience 4

Résous l’étrangeté de l’Expérience 1

Même noyau que l’hôte… mais à l’intérieur, tout ressemblait à un système complet. Comment ? Et surtout : essaie docker run -it alpine sh — un autre « système », minuscule, sur le même noyau.

Comprends noyau partagé + userspace isolé

Le « système » que tu vois dans un conteneur (fichiers, /etc, commandes) s’appelle le userspace. Il vient de l’image. Le noyau, lui, vient de l’hôte et il est partagé par tous les conteneurs. Une image Debian te donne le userspace de Debian ; une image Alpine, celui d’Alpine — sur le même noyau.

05Pourquoi le conteneur « meurt »

Expérience 5

Lie la vie du conteneur à son processus

Manipule

docker run -it debian bash

Tape exit, puis liste tous les conteneurs :

Manipule

docker ps -a

Observe

CONTAINER ID   IMAGE    STATUS                    NAMES
3f9a1c2b7d04   debian   Exited (0) 5 seconds ago  brave_kepler

Dès le exit, le conteneur est passé en Exited. Lance-en un qui « occupe » son processus : docker run -d debian sleep 60, puis docker ps — il est « Up ».

Comprends la règle d’or du cycle de vie

Un conteneur vit tant que son processus principal (PID 1) vit. bash se termine → le conteneur s’arrête. sleep 60 occupe PID 1 pendant 60 s → le conteneur reste « Up » 60 s. Un conteneur n’est pas une machine qu’on « éteint » : c’est un processus.

→Maintenant, la définition

Tu l’as vu de tes propres yeux, on peut donc le dire simplement :

Un conteneur est un processus isolé qui partage le noyau de l’hôte, porte son propre système de fichiers (venu de l’image), et dont la durée de vie est celle de son PID 1.

	Conteneur	Machine virtuelle
Noyau	celui de l’hôte (partagé)	le sien (séparé)
Contenu	un processus + son userspace	un OS complet
Démarrage	quasi-instantané	lent (boot d’un OS)
Poids	léger (Mo)	lourd (Go)

✓Ce que tu retiens

Un conteneur n’est pas une machine. C’est un processus qui emprunte le noyau de l’hôte, porte son propre système de fichiers, et vit tant que son PID 1 vit. Tu ne l’as pas appris : tu l’as prouvé.

Mini-projet

Prouve l’isolation de tes propres mains

Démontre toi-même que deux conteneurs ne se voient pas, bien qu’ils partagent le même noyau.

À faire

Terminal A : docker run -it –name boite-a debian bash, puis echo “coucou A” > /secret.txt
Terminal B : docker run -it –name boite-b debian bash, puis ls / → pas de secret.txt
Dans B : ps aux → tu ne vois pas le bash de la boîte A
En 3–4 lignes : pourquoi B ne voit ni le fichier ni le processus de A, alors qu’ils partagent le même noyau ?

Fil rouge — Ce que tu crées dans un conteneur lui est propre, et il meurt avec son processus. Au module suivant, on manipule le cycle de vie pour de vrai : entrer dans un conteneur qui tourne, le lancer en arrière-plan, le gérer.

?Auto-évaluation

1. Un conteneur a-t-il son propre noyau ?

Non. Il partage le noyau de l’hôte. C’est une VM qui a son propre noyau.

2. D’où vient le « système » qu’on voit dans le conteneur ?

De l’image : c’est le userspace, isolé. Le noyau vient de l’hôte.

3. Pourquoi un conteneur lancé avec bash s’arrête-t-il au exit ?

Parce que la vie du conteneur = la vie de son PID 1. bash est PID 1 ; il se termine → le conteneur s’arrête.