Docker démystifié : un runtime fait maison
Original : Docker is weird
Pourquoi c'est important
Comprendre les fondations de Docker reste essentiel pour quiconque opère des conteneurs en production.
Un développeur qui construit son propre runtime de conteneurs partage ses découvertes sur Docker : pas de vraie abstraction « conteneur », des images qui sont des dossiers, et un daemon qui tourne en root.
En construisant son propre runtime de conteneurs pour le plaisir, un développeur du blog Code and Cake a mis le doigt sur plusieurs bizarreries de Docker rarement expliquées clairement.
Première surprise : les conteneurs n'existent pas vraiment en tant que primitives Linux. Ce sont des processus ordinaires habillés de cinq fonctionnalités du noyau — namespaces, cgroups, et une couche réseau complexe — plutôt qu'une abstraction unifiée.
Deuxième point : une image Docker n'est qu'un dossier. Docker le place quelque part sur le système, puis appelle chroot ou pivot_root pour en faire la racine du processus. Rien de magique.
Sur le plan des langages, runc, le runtime officiel, est écrit en Go — un choix sous-optimal. Go est nativement multi-threadé, alors que plusieurs syscalls Linux requis par un runtime de conteneurs imposent un environnement mono-thread. Résultat : runc embarque un module C qui s'exécute avant l'initialisation du runtime Go. Et comme Go n'a pas de fork(), runc simule cette opération en s'exécutant lui-même via /proc/self/exe avec un argument spécial.
Enfin, Docker nécessite les droits root pour la plupart des opérations noyau. En mode rootless, le runtime doit réimplémenter toute la pile réseau en espace utilisateur — une complexité considérable souvent invisible pour les utilisateurs macOS.