Le conteneur, par la preuve — SORIA Académie

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 ubuntu bash

Observe

root@3f9a1c2b7d04:/#

Tu es maintenant root dans un Ubuntu. Tape cat /etc/os-release : tu lis « Ubuntu ». Pourtant ton hôte est peut-être une Debian. Étrange, non ?

Comprends ouvre après avoir essayé

Tu viens de créer un conteneur à partir de l’image ubuntu, et d’y ouvrir un shell interactif (-it = interactive + terminal). L’environnement « ressemble » à un Ubuntu complet. Garde cette étrangeté 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          # dans le conteneur, note la version
exit              # sors du conteneur
uname -r          # maintenant sur ta machine hôte

Observe

6.1.0-21-amd64    # dans le conteneur
6.1.0-21-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 « Ubuntu » ?

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 à Ubuntu. Comment ?

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.

Donc : noyau de l’hôte (partagé) + userspace de l’image (isolé). Une image Ubuntu te donne le userspace d’Ubuntu ; 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 ubuntu bash   # entre…
exit                         # …puis sors
docker ps -a                 # liste tous les conteneurs

Observe

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

Dès le exit, le conteneur est passé en Exited. Maintenant lance-en un qui « occupe » son processus :

docker run -d ubuntu sleep 60   # tourne 60 s en arrière-plan
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 : il vit, fait son travail, se termine. Au module suivant, ça expliquera pourquoi tes données disparaissent.

→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)
Isolation	namespaces / cgroups	hyperviseur

✓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 n’as pas appris une définition : tu l’as prouvée. Manipuler, observer, conclure — c’est le réflexe qu’on garde tout au long du parcours.

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 ubuntu bash, puis echo “coucou A” > /secret.txt
Terminal B : docker run -it –name boite-b ubuntu 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 ?

Livrable

Un court fichier conteneur-notes.md avec tes observations et ton explication.

Critères de réussite

Tu montres que secret.txt est absent dans la boîte B
Tu montres que les processus de A et B sont séparés
Ton explication emploie « userspace isolé » et « noyau partagé »

Fil rouge — Ce que tu crées dans un conteneur lui est propre, et il meurt avec son processus. Au Module 03, on attaque la persistance : comment ton futur site SORIA Web gardera ses données grâce aux volumes.

?Auto-évaluation

Réponds de tête, puis ouvre pour vérifier.

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.