Container : définition, fonctionnement et différences avec une VM

Un container est un processus, ou un groupe de processus, que le noyau du système d'exploitation exécute dans un environnement isolé. Vu de l'intérieur, il croit disposer de sa propre machine : son système de fichiers, ses processus, son interface réseau, son nom d'hôte. Vu de l'hôte, c'est un processus presque ordinaire, simplement cloisonné et limité en ressources.

L'idée est ancienne. L'appel système chroot, apparu sur Unix en 1979, isolait déjà l'arborescence de fichiers d'un processus. Les FreeBSD Jails (2000) puis les Solaris Zones (2004) ont étendu ce cloisonnement aux processus et au réseau. Sous Linux, les namespaces et les cgroups, ces derniers proposés par des ingénieurs de Google et intégrés au noyau en 2008, ont permis l'apparition de LXC. C'est en 2013 que Docker rend le conteneur accessible à tous les développeurs, en y ajoutant un format d'image simple et partageable. En 2015, l'Open Container Initiative (OCI) est créée sous l'égide de la Linux Foundation pour standardiser ces formats.

Le conteneur se situe entre le simple processus et la machine virtuelle. Il isole l'application et ses dépendances sans virtualiser le matériel ni démarrer un second système d'exploitation. C'est ce qui le rend léger, rapide et portable, et ce qui en a fait l'unité de base des architectures Cloud natives, orchestrées par Kubernetes.

À retenir : un conteneur n'est pas une petite machine virtuelle. C'est un processus de l'hôte, que le noyau isole et limite. Docker, Podman ou containerd ne sont que des outils pour en créer.

Deux familles de mécanismes du noyau Linux font l'essentiel du travail.

Les namespaces contrôlent ce qu'un processus voit. Chaque type de namespace isole une ressource :

• PID : une arborescence de processus propre, où l'application est le PID 1.
• mount : ses propres points de montage, donc son propre système de fichiers racine.
• network : ses interfaces, adresses IP, tables de routage et ports.
• UTS : son nom d'hôte.
• IPC : ses files de messages et sa mémoire partagée.
• user : une correspondance entre l'utilisateur root du conteneur et un utilisateur sans privilège sur l'hôte.
• cgroup et time : sa vue de la hiérarchie des cgroups et de certaines horloges.

Les cgroups (control groups) contrôlent ce qu'un processus consomme : quota de CPU, plafond de mémoire, débit disque, nombre maximal de processus. Si un conteneur dépasse sa limite mémoire, le noyau l'arrête sans affecter ses voisins.

Il est possible d'observer ces mécanismes sans aucun outil de conteneurisation, avec la commande unshare :

# Ouvrir un shell dans de nouveaux namespaces PID, mount, UTS et réseau
sudo unshare --pid --fork --mount-proc --uts --net bash

hostname demo-conteneur   # ne modifie que le namespace UTS
ps aux                    # le shell est le PID 1 et ne voit que ses enfants
ip link                   # seule l'interface loopback existe
ls -l /proc/$$/ns         # identifiants des namespaces du processus

Un runtime comme runc fait exactement cela, en plus complet : il crée les namespaces, rattache le processus à un cgroup, change sa racine vers le système de fichiers de l'image, retire les privilèges inutiles, puis lance la commande prévue.

Image et conteneur

L'image est le paquet livrable : une pile de couches de fichiers en lecture seule et un manifeste qui décrit la configuration. Elle est identifiée par une empreinte (digest) SHA-256 et, pour les humains, par un nom et un tag, comme python:3.12-slim. Le conteneur est une instance vivante de cette image, avec une couche inscriptible au-dessus. Une image est au conteneur ce qu'une classe est à un objet.

Les trois spécifications OCI

L'Open Container Initiative maintient trois spécifications qui garantissent l'interopérabilité :

• image-spec : le format des images, de leurs couches et de leur manifeste ;
• runtime-spec : la façon d'exécuter un conteneur à partir d'un système de fichiers et d'une configuration ;
• distribution-spec : l'API HTTP des registres pour pousser et tirer des images.

Grâce à elles, une image construite avec Docker s'exécute avec Podman, containerd ou CRI-O, et se stocke dans n'importe quel registre conforme.

Runtimes haut niveau et bas niveau

L'exécution est découpée en deux étages. Un runtime haut niveau (containerd, CRI-O) gère les images, le stockage, le réseau et le cycle de vie des conteneurs. Il délègue la création effective du processus isolé à un runtime bas niveau conforme à l'OCI : runc, l'implémentation de référence, ou crun, écrit en C. Kubernetes dialogue avec le runtime haut niveau via la Container Runtime Interface (CRI) ; depuis la version 1.24 (2022), il n'utilise plus Docker Engine comme intermédiaire, ce qui ne change rien pour les images construites avec Docker.

Les registres

Un registre stocke et distribue les images : Docker Hub, GitHub Container Registry, Amazon ECR, Google Artifact Registry, Azure Container Registry, ou un registre auto-hébergé comme Harbor, qui ajoute contrôle d'accès, réplication et scan de vulnérabilités.

La machine virtuelle virtualise le matériel ; le conteneur virtualise le système d'exploitation. Notre article Virtualisation : tout comprendre détaille le fonctionnement des hyperviseurs.

Les deux se combinent. Dans le Cloud, les conteneurs tournent presque toujours dans des machines virtuelles : la VM isole les clients entre eux, le conteneur découpe les applications à l'intérieur.

Partager le noyau impose une discipline particulière. Les bonnes pratiques relèvent de la démarche DevSecOps et portent sur trois niveaux.

• L'image : partir d'une image de base minimale (slim, Alpine, distroless), la reconstruire régulièrement, la scanner avec un outil comme Trivy et la signer, par exemple avec cosign du projet Sigstore.
• Les privilèges : ne pas exécuter le processus en root, retirer les capabilities inutiles, conserver le profil seccomp par défaut, monter le système de fichiers racine en lecture seule et bannir le mode privilégié.
• L'isolation : activer les user namespaces ou le mode rootless, et réserver un runtime sandboxé (gVisor, Kata Containers) aux charges qui exécutent du code non fiable.

Ces règles s'automatisent : un pipeline CI/CD peut refuser une image vulnérable, et un orchestrateur peut interdire les conteneurs privilégiés par politique.