Conteneurisation (Docker, OCI)

La conteneurisation consiste à exécuter une application dans un environnement isolé qui embarque toutes ses dépendances — bibliothèques, binaires, configuration — sous forme d’une image portable. Contrairement à une machine virtuelle, un conteneur n’embarque pas de système d’exploitation : c’est un processus ordinaire du noyau Linux hôte, isolé par des mécanismes natifs du kernel.

Ce qu’il y a dessous

Deux mécanismes du noyau font l’essentiel du travail. Les namespaces cloisonnent ce que le processus voit : son propre arbre de processus, ses interfaces réseau, ses points de montage, ses utilisateurs. Les cgroups bornent ce qu’il consomme : CPU, mémoire, entrées-sorties. Un conteneur est la combinaison des deux, appliquée à un processus lancé depuis une image. C’est pourquoi il démarre en quelques dizaines de millisecondes là où une VM démarre un OS complet — et pourquoi tous les conteneurs d’un hôte partagent le même noyau.

L’image, elle, est un empilement de couches en lecture seule : chaque instruction de construction ajoute une couche, et les couches communes sont partagées entre images, ce qui rend le stockage et la distribution économes. Une image se référence par tag (mutable) ou par digest (immuable) ; en production, le digest est la seule référence qui garantit de déployer exactement ce qui a été testé.

Le standard OCI

L’Open Container Initiative normalise le format d’image, le runtime et la distribution via les registres. Concrètement : une image construite avec n’importe quel outil s’exécute avec n’importe quel runtime conforme (runc, containerd, CRI-O) et se stocke dans n’importe quel registre. Docker a popularisé le modèle, mais n’est plus un passage obligé — Kubernetes parle directement à containerd. C’est cette interopérabilité qui fait de l’image OCI l’unité de livraison logicielle par défaut, et le prérequis de toute migration vers Kubernetes : on conteneurise d’abord, on orchestre ensuite.

Les limites à connaître

L’isolation d’un conteneur est plus faible que celle d’une VM : le noyau est partagé, et une faille kernel expose tous les conteneurs de l’hôte. Les images sont un inventaire logiciel à maintenir — chaque couche fige des paquets qui accumulent des CVE, d’où la nécessité de scanner et de reconstruire régulièrement, même sans changement applicatif. Enfin, conteneuriser une application legacy qui suppose un état local, des chemins en dur ou un démarrage lent est un travail d’adaptation réel, pas un simple changement d’emballage.