- Un article qui retrace l’histoire du déploiement de serveurs et des problèmes d’isolation des processus, en soulignant que les FreeBSD jails ont concrétisé le concept moderne de conteneur avec 10 ans d’avance sur l’industrie
- Introduits dans FreeBSD 4.0 en 2000, les jails étendent
chroot pour offrir, comme fonctionnalité native du noyau, une isolation complète du système de fichiers, du réseau et des processus
- Linux a atteint les conteneurs via LXC en 2008 puis Docker en 2013, mais au prix d’une accumulation de couches d’abstraction complexes comme les namespaces, les cgroups et l’OCI
- Ce que Docker a bien résolu, c’est le problème du packaging et du déploiement (shipping) des applications ; les jails excellent dans l’isolation, mais leur faiblesse est l’absence de standard natif de déploiement
- La suite abordera la mise en place d’une infrastructure fondée sur les jails, les snapshots ZFS et le provisioning avec Ansible en conditions réelles
Les problèmes du déploiement de serveurs à ses débuts
- Il y a plusieurs décennies, la méthode standard pour déployer quelque chose sur un serveur consistait à copier manuellement des fichiers via FTP avec des outils comme Total Commander, FileZilla ou FAR Manager ; les utilisateurs avancés employaient
scp ou rsync, mais le fond du problème restait le même
- Sur un projet géré seul, une erreur n’était pas forcément dramatique, mais cela devenait critique lorsqu’il fallait administrer des dizaines de projets clients
- Dans une configuration backend classique, plusieurs sites web partageaient la même instance de serveur web Apache et donc le même cycle de vie ; si Apache tombait, tout tombait
- Lors d’un pic de trafic, un site pouvait consommer toutes les ressources, et les autres sites du même serveur s’asphyxiaient en silence
- Les administrateurs système tentaient d’automatiser avec des scripts shell, mais il n’existait aucune méthode standard pour la gestion de versions ou les rollbacks ; on utilisait donc souvent des noms de dossiers de projet avec des numéros incrémentaux ou des horodatages
Deux problèmes fondamentaux à résoudre
- Déploiement (Deployment) : besoin d’une livraison fiable, de prévenir l’erreur humaine, d’implémenter la gestion de versions et les rollbacks, et de disposer d’une solution générique couvrant tous les cas d’usage métier
- Isolation des processus (Process Isolation) : besoin d’une protection mutuelle entre l’application et le système, d’éviter qu’une exigence d’une application ne casse discrètement une autre, et de résoudre les conflits de dépendances
- Les tentatives de résolution du problème de déploiement ont évolué vers les pipelines CI/CD modernes, les standards de packaging et les systèmes de contrôle de version, mais l’histoire du problème d’isolation reste relativement moins connue
De chroot aux machines virtuelles
- Introduit en 1979 par Bell UNIX,
chroot fournissait à un processus une vue isolée du système de fichiers, l’empêchant d’accéder en dehors d’un sous-arbre : une idée primitive mais utile
- Limite : seule la couche système de fichiers est isolée ; il reste possible d’interférer avec le réseau, d’autres processus et les ressources système, et il est aussi possible de s’en échapper
- La première vraie réponse entreprise a été la machine virtuelle (VM), popularisée par VMware à la fin des années 1990
- Elle offrait à chaque application un environnement OS totalement isolé, mais chaque VM embarquait un OS complet, avec un surcoût important et des temps de démarrage de l’ordre de la minute
La naissance des FreeBSD Jails
- En 2000, une révolution discrète s’est produite non pas sur Windows Server ni sur Linux, mais sur FreeBSD
- FreeBSD fonctionne de manière fondamentalement différente de Linux : là où Linux ne fournit que le noyau et s’assemble avec un userland GNU, un écosystème de paquets et des choix propres à chaque distribution, FreeBSD développe, versionne et teste ensemble le noyau, le userland, les outils de base et les bibliothèques comme un OS complet
- La solution construite sur cette base cohérente est celle des jails, présentée par Poul-Henning Kamp et Robert Watson puis intégrée comme fonctionnalité native du noyau dans FreeBSD 4.0 (mars 2000)
- Chaque jail dispose de sa propre vue du système de fichiers, pile réseau et espace de processus, sans visibilité sur le système hôte
- Comme les jails partagent le noyau de l’hôte, ils offrent un surcoût proche de zéro et un démarrage quasi instantané
- FreeBSD a ainsi réalisé en production, avec 10 ans d’avance sur l’industrie, une implémentation pratique de ce qu’on appelle aujourd’hui des conteneurs
Chronologie des technologies d’isolation
- Le véritable parcours d’évolution du problème de l’isolation : serveurs partagés sans isolation → machines virtuelles lourdes mais isolées → conteneurs légers et isolés
- FreeBSD a atteint la troisième étape en 2000, Linux y est parvenu avec LXC en 2008, et Docker est apparu en 2013
- Au moment où Docker était salué comme révolutionnaire, les FreeBSD jails étaient déjà matures et éprouvés en production depuis 13 ans
Pourquoi Linux a gagné
- La supériorité technique ne suffit pas à gagner une guerre d’écosystème
- Linux l’a emporté grâce à une prise de décision rapide, à l’effet viral de la licence GPL et au fort soutien entreprise de Red Hat et IBM
- Ensuite, Google, Facebook et Amazon ont développé des outils pour les datacenters à grande échelle, imposant la direction de l’ensemble de l’industrie
- Linux est passé de « l’OS gratuit pour ceux qui ne peuvent pas acheter de licence commerciale » à « l’unique choix pour les serveurs »
La complexité de l’écosystème des conteneurs Linux
- Pour résoudre les problèmes d’isolation et de déploiement, les ingénieurs Linux ont d’abord construit des primitives noyau comme les namespaces, cgroups et seccomp, puis ont empilé au-dessus des couches d’abstraction complexes : LXC (2008) → OCI/runc (2015) → Docker/Podman (2013/2018) → Docker Hub, etc.
- Le résultat est un amas sur-ingéniéré d’abstractions qui fuient (leaky abstractions) destiné à une infrastructure cloud et dépendante des fournisseurs
- Aujourd’hui, pour exécuter une application dans un système à grande échelle, la valeur par défaut implicite est de la conteneuriser avec Docker puis de l’orchestrer avec Kubernetes ; ce n’est plus présenté comme une option parmi d’autres, mais comme l’évidence
La contribution de Docker et la faiblesse des jails
- Ce que Docker a particulièrement bien résolu, c’est le problème du shipping : empaqueter une application avec toutes ses dépendances, la distribuer via un registre et l’exécuter de façon identique sur n’importe quelle machine, en fournissant un standard universel
- Le format d’image OCI s’est imposé comme standard de fait de l’industrie
- Les jails résolvent remarquablement bien le problème de l’isolation, mais ils n’ont pas de solution native pour le shipping ; c’est l’une des principales raisons pour lesquelles l’écosystème des jails paraît moins mature que celui de Docker
- La communauté a conscience de cet écart, et certains outils (
cbsd, bastille, pot, appjail, etc.) tentent d’imiter l’écosystème moderne des conteneurs ; il existe aussi d’autres approches exploitant les primitives natives de FreeBSD
Aperçu de la suite
- La prochaine partie traitera de la simplicité et de l’élégance d’une infrastructure basée sur FreeBSD, des bases des jails et de leur fonctionnement, de la réduction du boilerplate via un gestionnaire de jails, du provisioning et du déploiement avec Ansible, de la puissance des snapshots ZFS, et de la manière de combiner tout cela pour construire une infrastructure robuste et scalable pour Hypha
Aucun commentaire pour le moment.