- 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
1 commentaires
Commentaires sur Hacker News
La supériorité technique seule n’a pas suffi pour gagner la guerre des écosystèmes
Au milieu des années 90, Linux a grandi grâce à une prise de décision rapide, au caractère viral de la licence GPL, ainsi qu’au soutien des entreprises comme Red Hat et IBM
J’ai installé Linux en 1994, mais dans la communauté FreeBSD, on a méprisé mon PC à 3 500 $ en le jugeant « pas terrible »
Il y avait un bug sur l’interface IDE, mais Linux a proposé une parade en quelques jours, alors que côté BSD on me disait simplement d’acheter du matériel SCSI
J’étais étudiant à l’époque, je n’avais pas d’argent, et Linux a donc été le choix réaliste
J’ai réessayé FreeBSD plus tard, mais Linux faisait déjà tout ce dont j’avais besoin
Le bug concerné est documenté dans l’article wiki sur le CMD640
Malgré tout, j’apprécie chez FreeBSD sa plus grande cohérence du système, ainsi que la stabilité de composants clés comme le son ou les API d’événements
La prise en charge des pilotes pour le matériel récent reste meilleure sous Linux, mais j’espère que FreeBSD ne deviendra pas trop « linuxisé »
En réalité, avec un *nix moderne, on peut presque tout faire dans les deux camps. Ce n’est plus une question de performances, mais plutôt de préférences et d’habitudes
À l’inverse, BSD souffrait du procès avec AT&T, ce qui rebutait les entreprises, et pendant ce temps Linux a conquis le marché
On voit encore aujourd’hui des textes qui défendent FreeBSD, mais il est difficile de renverser une dynamique figée depuis les années 90
Cela dit, je pense que le support matériel a encore aujourd’hui une bonne marge de progression
L’article était intéressant
Je ne suis pas d’accord avec l’idée que les primitives du noyau Linux comme namespaces, cgroups, seccomp auraient fini par créer un écosystème d’abstractions complexes
Linux est devenu complexe parce qu’il a réussi, pas à cause d’une conception ratée
Si BSD était devenu dominant, il aurait fait émerger exactement le même type d’écosystème « sur-ingénieré »
Au fond, les conteneurs ne sont que des VM légères, donc autant utiliser de vraies VM
Si Docker est populaire, c’est à cause de la réutilisabilité et de l’écosystème, pas de l’isolation de sécurité
Les jails de FreeBSD sont simples et élégantes, mais les conteneurs OCI de Linux sont bien plus faciles à utiliser
Les conteneurs ne sont pas une fonctionnalité autonome du noyau, mais une illusion créée en combinant plusieurs espaces de noms, montages et mécanismes d’isolation des processus
La conception de Linux est intentionnelle, et cgroups comme seccomp sont largement utilisés au-delà des conteneurs, notamment dans systemd ou flatpak
La philosophie « bétail vs animal de compagnie » peut s’appliquer au niveau des VM et de l’orchestration
Dire que les jails sont meilleurs ne me semble pas très crédible dans la pratique
Si Docker a gagné, ce n’est pas grâce à l’isolation technique, mais grâce à l’écosystème
Avec des outils comme Dockerfile, les registres publics et compose, on pouvait créer un environnement exécutable en 30 secondes
Les jails FreeBSD étaient excellentes techniquement, mais la barrière à l’entrée était élevée
Récemment, on observe aussi un mouvement de retour vers des jails ou VM plus simples, en réaction à la complexité des stacks de conteneurs
Mais il ne s’agit pas vraiment de concurrence, chacun a simplement un rôle différent
FreeBSD n’a rien de comparable, et manque aussi d’un vrai système d’images
Si FreeBSD avait investi dans l’UX et l’écosystème comme Docker, sa base d’utilisateurs aurait probablement été multipliée plusieurs fois
Vers 2005, nous faisions tourner toute l’entreprise sur FreeBSD
Mais avec le temps, Linux a fini par s’imposer aussi bien dans le personnel que dans le professionnel
Aujourd’hui, même Docker est suffisamment satisfaisant, et il n’y a plus de raison rationnelle d’y revenir
Mais il a tardé à s’adapter à l’ère des CPU multicœurs, et s’est fait distancer par Linux et Windows
Les performances se sont rétablies depuis, mais le manque de pilotes et le nombre limité de développeurs restent des handicaps
J’utilise Linux là où il faut des GPU ou CUDA, et FreeBSD pour des serveurs stables
L’UX de FreeBSD est plus cohérente, mais dans la pratique Linux est devenu le « chemin heureux »
Les articles qui présentent FreeBSD me font toujours plaisir
FreeBSD a introduit les jails en 2000, mais Linux disposait déjà de technologies similaires comme OpenVZ et VServer
Ce n’est qu’avec l’arrivée de LXC à la fin des années 2000 qu’est apparue l’idée que « FreeBSD était en avance »
Je me demande s’il existe un bon texte expliquant techniquement la mise en œuvre de l’isolation dans les conteneurs et les VM
Pas seulement au niveau du cliché « c’est plus faible parce que ça partage le même noyau », mais avec de vrais détails d’implémentation
Ces derniers temps, des fonctions comme systemd-oomd me donnent envie de revenir à FreeBSD
Avant, je lançais plusieurs processus dans le terminal en laissant des logs pendant que je développais,
mais désormais systemd tue des groupes entiers de processus au niveau du cgroup, ce qui fait disparaître mon travail
Ce type de changement système incompatible casse le flux de développement, et c’est frustrant de devoir utiliser systemd-run ou Docker à chaque fois juste pour isoler les processus
La clé du succès de Linux, c’était le caractère contagieux de la GPL et les effets de réseau
À partir du moment où les utilisateurs ont perçu Linux comme le standard, les fabricants de matériel ont naturellement commencé à publier des pilotes pour Linux
Grâce à la souplesse du noyau, l’écosystème de pilotes open source a connu une croissance explosive