Un conteneur est un processus ordinaire de votre machine Linux, à qui le noyau donne une vue restreinte du système, des limites de consommation et moins de privilèges. Cette page ouvre la formation Introduction à la conteneurisation, destinée aux débutants qui veulent comprendre ce qu'ils utilisent avant de choisir Docker, Podman ou Kubernetes. Vous y fabriquez un conteneur avec les namespaces et les cgroups, vous ouvrez une image OCI octet par octet, vous l'exécutez avec runc, puis vous situez chaque outil à sa place. Les deux premiers modules se font sans aucun moteur installé.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Expliquer ce qui distingue un conteneur d'une machine virtuelle.
- Fabriquer un conteneur avec les seules primitives du noyau, puis le limiter.
- Ouvrir une image OCI et vérifier chacun de ses digests sans moteur.
- Exécuter un bundle OCI avec un runtime bas niveau.
- Situer runtime, moteur et orchestrateur, puis choisir un moteur.
- Construire une première image avec un Dockerfile.
Qu'est-ce qu'un conteneur, concrètement ?
Section intitulée « Qu'est-ce qu'un conteneur, concrètement ? »Un conteneur n'est pas une petite machine virtuelle : c'est un processus de l'hôte, enfermé par trois mécanismes du noyau Linux et démarré sur le système de fichiers d'une image. Le noyau reste unique et partagé ; ce qui change, c'est ce que le processus voit, ce qu'il peut consommer et ce qu'il a le droit de faire. C'est pour cela qu'un conteneur démarre aussi vite qu'un programme : il n'y a aucun système à amorcer, seulement un processus à lancer.
Les trois mécanismes se répartissent le travail, et chacun a sa leçon dans la formation :
- les namespaces isolent ce que le processus voit : ses numéros de processus, son nom d'hôte, ses points de montage, son réseau. Vous les créez à la main dans Un conteneur à la main avec unshare et nsenter ;
- les cgroups (groupes de contrôle) plafonnent ce qu'il consomme : mémoire, CPU, nombre de processus. Un conteneur qui dépasse sa mémoire est tué par le noyau sans toucher au reste de la machine ;
- les capabilities découpent les pouvoirs de root en une quarantaine de droits séparés, pour qu'un root de conteneur n'ait que ceux dont il a besoin. Cgroups et capabilities se pratiquent dans Limiter un conteneur.
Le quatrième ingrédient n'est pas un mécanisme du noyau : c'est l'image, une archive standardisée par l'OCI (Open Container Initiative) qui fournit le système de fichiers et la configuration de départ. Les mécanismes eux-mêmes sont détaillés, hors formation, dans les guides Linux sur les namespaces, les cgroups et les capabilities.
Quelle différence entre un conteneur et une machine virtuelle ?
Section intitulée « Quelle différence entre un conteneur et une machine virtuelle ? »Une machine virtuelle émule un ordinateur complet avec son propre noyau, alors qu'un conteneur partage le noyau de l'hôte et n'isole qu'une application. La virtualisation passe par un hyperviseur, qui fait tourner plusieurs systèmes d'exploitation indépendants sur la même machine physique. La conteneurisation ne démarre aucun système : elle isole un processus et les fichiers dont il a besoin.
Le schéma ci-dessous met les deux modèles côte à côte : à gauche, chaque machine virtuelle embarque un système d'exploitation complet avec son noyau, au-dessus de l'hyperviseur ; à droite, les conteneurs se posent sur un seul OS hôte, dont ils partagent le noyau. Repérez la couche « OS » : elle est multipliée à gauche, unique à droite.
Le tableau se lit ligne par ligne : chaque critère oppose ce que coûte une machine virtuelle à ce que coûte un conteneur. Retenez surtout la première ligne, l'isolation, car elle explique toutes les autres.
| Critère | Machine virtuelle | Conteneur |
|---|---|---|
| Isolation | système complet, noyau séparé | processus isolé, noyau partagé |
| Taille | plusieurs Go | quelques Mo à quelques centaines de Mo |
| Démarrage | de l'ordre de la minute | de l'ordre de la seconde |
| Ressources | mémoire et CPU réservés à l'invité | partagées, plafonnées par les cgroups |
| Portabilité | dépend de l'hyperviseur | image OCI standard |
| Cas d'usage | plusieurs systèmes, isolation forte | applications, microservices, CI/CD |
Quand garder une machine virtuelle ?
Section intitulée « Quand garder une machine virtuelle ? »La machine virtuelle reste le bon choix quand il faut un autre noyau ou une isolation plus forte que celle d'un noyau partagé. Tester plusieurs systèmes d'exploitation, faire tourner une application ancienne dans son environnement d'origine ou séparer des charges de sensibilité différente sont des cas où le surcoût se justifie. Un conteneur, lui, ne peut pas exécuter un noyau différent de celui de l'hôte : un conteneur Linux tourne sur un noyau Linux.
Les deux techniques ne s'excluent pas : la plupart des conteneurs de production tournent dans des machines virtuelles, et c'est d'ailleurs dans une VM jetable que vous ferez les gestes de cette formation. Côté virtualisation, KVM est l'hyperviseur intégré au noyau Linux.
Qu'apporte la conteneurisation ?
Section intitulée « Qu'apporte la conteneurisation ? »La conteneurisation apporte la portabilité d'une application avec ses dépendances, pour un coût en ressources bien plus faible qu'une machine virtuelle. L'image embarque l'application et tout ce dont elle dépend : elle se comporte de la même façon en développement, en test et en production, ce qui fait disparaître le « ça marche chez moi ». Comme un conteneur se crée et se détruit en quelques secondes, il se prête aux pipelines CI/CD, aux microservices et à la scalabilité automatique, qui ajuste le nombre de conteneurs à la charge.
À qui s'adresse cette formation ?
Section intitulée « À qui s'adresse cette formation ? »Elle s'adresse aux débutants qui doivent utiliser des conteneurs et veulent savoir ce qu'il y a dessous, avant d'apprendre un outil. Les développeurs y comprennent ce que devient leur application une fois empaquetée, les administrateurs ce qu'ils exploitent, et les futurs DevOps le socle commun de Docker, Podman et Kubernetes.
Les prérequis sont ceux d'un utilisateur de Linux : savoir taper une commande, lire sa sortie et naviguer dans l'arborescence. La formation Linux les apporte si besoin. Les gestes se font en root, sur une machine virtuelle jetable Linux avec cgroup v2 (les leçons ont été jouées sur Debian 13), jamais sur votre poste de travail.
Comment la formation est-elle organisée ?
Section intitulée « Comment la formation est-elle organisée ? »La formation tient en trois modules d'enseignement, du noyau vers les outils. Le programme détaillé, avec le suivi de votre progression, se trouve dans Mon parcours.
Isoler un processus
Section intitulée « Isoler un processus »Le premier module fabrique un conteneur à la main avec les namespaces, puis le limite avec les cgroups et les capabilities : ce que fait un moteur, sans moteur. Il compte deux leçons, Un conteneur à la main avec unshare et nsenter et Limiter un conteneur : cgroups v2 et capabilities. À son terme, vous savez dire ce qui isole un conteneur et ce qui ne l'isole pas.
Lire une image
Section intitulée « Lire une image »Le deuxième module ouvre ce que contient une image : couches, configuration, manifeste, index multi-architecture et digest, lus et vérifiés sans moteur. Les images de conteneurs : couches et contenu pose le principe des couches, Comprendre OCI : image, distribution et runtime les spécifications et la différence entre tag et digest, puis Lire une image OCI et vérifier son digest vous fait recalculer chaque empreinte vous-même.
Exécuter et choisir
Section intitulée « Exécuter et choisir »Le troisième module lance une image avec un runtime bas niveau, situe runtime, moteur et orchestrateur, puis aide à choisir un moteur. Exécuter un bundle OCI avec runc montre que le runtime ne fait que les gestes du premier module, pilotés par un fichier. Runtime, moteur, orchestrateur : qui fait quoi relève les arbres de processus de Podman, containerd et Docker. Choisir un moteur de conteneurs aide à décider, et le guide Dockerfile fait enfin construire une image avec Docker : chaque instruction y devient une couche, celles que le deuxième module vous a appris à lire.
Comment les acquis se valident-ils ?
Section intitulée « Comment les acquis se valident-ils ? »Chaque leçon de pratique se termine par un quiz, et chaque geste montré dans les cinq leçons propres à la formation a été rejoué dans une machine virtuelle avant d'être écrit. Le quiz tiré d'une banque vérifie que vous avez compris pourquoi chaque commande produit son résultat, pas que vous l'avez recopiée. Ces leçons indiquent les versions utilisées et les sorties obtenues, pour que vous puissiez comparer les vôtres. Les leçons Choisir un moteur de conteneurs et Les images de conteneurs sont partagées avec d'autres formations ; la première est une page de décision, sans quiz propre.
La formation ne comporte pas encore d'épreuve finale notée sur l'état d'une machine. La meilleure preuve reste de refaire le premier module sans la page sous les yeux : un conteneur Alpine isolé, plafonné à 64 Mio, que vous inspectez depuis l'hôte.
Que laisse-t-elle aux formations Docker, Podman et Kubernetes ?
Section intitulée « Que laisse-t-elle aux formations Docker, Podman et Kubernetes ? »Cette formation explique ce qu'est un conteneur et fait construire une première image ; publier, sécuriser et orchestrer des conteneurs appartiennent aux formations d'outil. Elle s'arrête au premier Dockerfile : elle ne vous apprend ni à pousser une image dans un registre, ni à déployer sur un cluster, ni les outils de build avancés. Chaque sujet a sa formation ou son guide, que vous aborderez mieux armé.
Chaque instruction d'un Dockerfile produit une couche d'image mise en cache, et un registre est l'entrepôt d'où l'on tire et où l'on pousse les images. Ces deux notions sont posées dans le deuxième module ; leur pratique vit ailleurs. Le tableau ci-dessous part d'une situation réelle et donne le guide qui la traite.
| Votre besoin | Où l'apprendre |
|---|---|
| Lancer et gérer des conteneurs au quotidien | la formation Docker ou la formation Podman |
| Aller plus loin dans la construction d'images | les outils de build et le module « Construire » de la formation Docker |
| Stocker et distribuer des images | Registres de conteneurs |
| Décrire plusieurs conteneurs sur un poste | Docker Compose |
| Orchestrer sur plusieurs machines | la formation Kubernetes |
| Sécuriser images et exécution | Sécuriser les conteneurs et Trivy |
| Des conteneurs système, proches d'une VM | la formation Incus |
Par où commencer selon votre situation ?
Section intitulée « Par où commencer selon votre situation ? »Si vous partez de rien, suivez les modules dans l'ordre : chaque leçon réutilise ce que la précédente a fabriqué. Le conteneur Alpine du premier module revient dans le deuxième sous forme d'image, puis dans le troisième sous forme de bundle exécuté par runc.
Deux entrées directes existent si une question précise vous amène. Si vous utilisez déjà Docker et voulez savoir qui fait quoi entre dockerd, containerd et runc, commencez par Runtime, moteur, orchestrateur : qui fait quoi. Si votre question porte sur un digest qui ne correspond pas, commencez par Lire une image OCI et vérifier son digest.
À retenir
Section intitulée « À retenir »- Un conteneur est un processus de l'hôte, isolé par les namespaces, plafonné par les cgroups et privé de pouvoirs par les capabilities.
- Une machine virtuelle a son propre noyau ; un conteneur partage celui de l'hôte, d'où sa légèreté et sa limite.
- L'image OCI fournit le système de fichiers et la configuration ; son digest en garantit le contenu.
- Le runtime (runc, crun) exécute, le moteur (containerd, Podman, Docker) gère images et cycle de vie, l'orchestrateur (Kubernetes) pilote plusieurs machines.
- Un premier Dockerfile se construit ici ; registres, Compose et Kubernetes s'apprennent dans les formations d'outil, après celle-ci.