Certaines personnes disent que les distributions Linux n'ont plus d'importance avec les conteneurs. Les approches alternatives, comme les conteneurs distroless et scratch, semblent faire fureur. Il semble que nous envisagions et prenions des décisions technologiques davantage basées sur le sens de la mode et la gratification émotionnelle immédiate que sur les effets secondaires de nos choix. Nous devrions nous poser des questions telles que :Comment ces choix affecteront-ils la maintenance dans six mois ? Quels sont les compromis d'ingénierie? Comment ce changement de paradigme affecte-t-il nos systèmes de build à grande échelle ?
C'est frustrant à regarder. Si nous oublions que l'ingénierie est un jeu à somme nulle avec des compromis mesurables - avantages et inconvénients, avec des coûts et des avantages de différentes approches - nous nous rendons un mauvais service, nous rendons un mauvais service à nos employeurs et nous rendons nos collègues qui finiront par maintenir notre coder un mauvais service. Enfin, nous rendons un mauvais service à tous les mainteneurs (salut les mainteneurs !) en n'appréciant pas le travail qu'ils font.
Comprendre le problème
Pour comprendre le problème, nous devons rechercher pourquoi nous avons commencé à utiliser les distributions Linux en premier lieu. Je regrouperais les raisons en deux catégories principales :les noyaux et les autres packages. La compilation des noyaux est en fait assez facile. Slackware et Gentoo (j'ai toujours un faible dans mon cœur) nous l'ont appris.
D'un autre côté, l'énorme quantité de logiciels de développement et d'exécution qui doivent être empaquetés pour un système Linux utilisable peut être intimidante. De plus, la seule façon de vous assurer que des millions de permutations de packages peuvent être installées et fonctionner ensemble est d'utiliser l'ancien paradigme :compilez-le et expédiez-le ensemble comme une chose (c'est-à-dire une distribution Linux). Alors, pourquoi les distributions Linux compilent-elles les noyaux et tous les packages ensemble ? Simple :pour s'assurer que les choses fonctionnent ensemble.
Parlons d'abord des noyaux. Le noyau est spécial. Démarrer un système Linux sans noyau compilé est un peu un défi. C'est le cœur d'un système d'exploitation Linux, et c'est la première chose sur laquelle nous nous appuyons lorsqu'un système démarre. Les noyaux ont de nombreuses options de configuration différentes lorsqu'ils sont compilés, ce qui peut avoir un effet considérable sur la façon dont le matériel et les logiciels s'exécutent sur un noyau. Un problème secondaire dans ce compartiment est que les logiciels système, tels que les compilateurs, les bibliothèques C et les interpréteurs, doivent être réglés pour les options que vous avez intégrées au noyau. Gentoo nous l'a appris de manière viscérale, ce qui a transformé tout le monde en un mainteneur de distribution miniature.
De manière embarrassante (parce que j'ai travaillé avec des conteneurs au cours des cinq dernières années), je dois admettre que j'ai compilé des noyaux assez récemment. Je devais faire fonctionner KVM imbriqué sur RHEL 7 afin de pouvoir exécuter OpenShift sur des machines virtuelles OpenStack, dans une machine virtuelle KVM sur mon ordinateur portable, ainsi que notre kit de développement de conteneurs (CDK). #justsayin Qu'il suffise de dire que j'ai lancé RHEL7 sur un tout nouveau noyau 4.X à l'époque. Comme tout bon administrateur système, j'étais un peu inquiet de manquer des options de configuration et des correctifs importants. Et, bien sûr, j'avais raté certaines choses. Le mode veille a cessé de fonctionner correctement, ma station d'accueil a cessé de fonctionner correctement et il y a eu de nombreuses autres petites erreurs aléatoires. Mais cela a assez bien fonctionné pour une démonstration en direct d'OpenShift sur OpenStack, dans une seule machine virtuelle KVM sur mon ordinateur portable. Allez, c'est plutôt amusant, non ? Mais je m'égare…
Parlons maintenant de tous les autres packages. Bien que le noyau et le logiciel système associé puissent être difficiles à compiler, le problème bien plus important du point de vue de la charge de travail consiste à compiler des milliers et des milliers de packages pour nous donner un système Linux utilisable. Chaque package nécessite une expertise en la matière. Certains logiciels ne nécessitent l'exécution que de trois commandes :./configure , faire , et faire installer . D'autres nécessitent une grande expertise dans le domaine, allant de l'ajout d'utilisateurs à la configuration de paramètres par défaut spécifiques dans etc pour exécuter des scripts de post-installation et ajouter des fichiers unitaires systemd. L'ensemble des compétences nécessaires pour les milliers de logiciels différents que vous pourriez utiliser est intimidant pour une seule personne. Mais, si vous voulez un système utilisable avec la possibilité d'essayer de nouveaux logiciels quand vous le souhaitez, vous devez apprendre à compiler et à installer le nouveau logiciel avant même de commencer à apprendre à l'utiliser. C'est Linux sans distribution Linux. C'est le problème d'ingénierie que vous acceptez lorsque vous renoncez à une distribution Linux.
Le fait est que vous devez tout construire ensemble pour vous assurer qu'il fonctionne avec n'importe quel niveau de fiabilité raisonnable, et il faut une tonne de connaissances pour construire une cohorte utilisable de packages. C'est plus de connaissances que n'importe quel développeur ou administrateur système ne pourra raisonnablement apprendre et conserver. Chaque problème que j'ai décrit s'applique à votre hôte de conteneur (noyau et logiciel système) et à votre image de conteneur (logiciel système et tous les autres packages) - notez le chevauchement ; il y a aussi des compilateurs, des bibliothèques C, des interpréteurs et des JVM dans l'image du conteneur.
La solution
Vous le savez déjà, mais les distributions Linux sont la solution. Arrêtez de lire et envoyez à votre responsable de paquet le plus proche (encore une fois, saluez les responsables !) une carte électronique (attendez, ai-je juste donné mon âge ?). Sérieusement, ces gens font une tonne de travail, et c'est vraiment sous-estimé. Kubernetes, Istio, Prometheus et Knative :je vous regarde. Votre temps vient aussi, quand vous serez en mode maintenance, surutilisé et sous-estimé. J'écrirai à nouveau ce même article, probablement à propos de Kubernetes, dans environ sept à dix ans.
Premiers principes avec les builds de conteneurs
Il y a des compromis entre la construction à partir de rien et la construction à partir d'images de base.
Construire à partir d'images de base
La construction à partir d'images de base présente l'avantage que la plupart des opérations de construction ne sont rien de plus qu'une installation ou une mise à jour de package. Il repose sur une tonne de travail effectué par les mainteneurs de paquets dans une distribution Linux. Il a également l'avantage qu'un événement de correction dans six mois, voire 10 ans, à partir de maintenant (avec RHEL) est un événement d'administrateur des opérations/systèmes (yum update), et non un événement de développeur (qui nécessite de choisir le code pour comprendre pourquoi certains l'argument de la fonction ne fonctionne plus).
Double-cliquons un peu dessus. Le code d'application s'appuie sur de nombreuses bibliothèques allant des bibliothèques munging JSON aux mappeurs relationnels objet. Contrairement au noyau Linux et à Glibc, ces types de bibliothèques changent sans tenir compte de la rupture de la compatibilité des API. Cela signifie que dans trois ans, votre événement de mise à jour deviendra probablement un événement de changement de code, et non un événement de mise à jour. Compris, laissez-le entrer. Développeurs, vous êtes averti à 2 heures du matin si l'équipe de sécurité ne trouve pas de piratage de pare-feu pour bloquer l'exploit.
Construire à partir d'une image de base n'est pas parfait; il y a des inconvénients, comme la taille de toutes les dépendances qui sont entraînées. Cela rendra presque toujours vos images de conteneur plus grandes que la construction à partir de zéro. Un autre inconvénient est que vous n'aurez pas toujours accès au dernier code en amont. Cela peut être frustrant pour les développeurs, en particulier lorsque vous voulez simplement sortir quelque chose, mais pas aussi frustrant que d'être appelé pour regarder une bibliothèque à laquelle vous n'avez pas pensé depuis trois ans et que les responsables en amont ont changé tout le temps. .
Si vous êtes un développeur Web et que vous roulez des yeux vers moi, j'ai un mot pour vous :DevOps. Cela signifie que vous portez un téléavertisseur, mon ami.
Construire à partir de zéro
Les builds Scratch ont l'avantage d'être vraiment petits. Lorsque vous ne comptez pas sur une distribution Linux dans le conteneur, vous avez beaucoup de contrôle, ce qui signifie que vous pouvez tout personnaliser selon vos besoins. Il s'agit d'un modèle best-of-breed, et il est valable dans certains cas d'utilisation. Un autre avantage est que vous avez accès aux derniers packages. Vous n'avez pas besoin d'attendre une distribution Linux pour mettre à jour quoi que ce soit. Vous avez le contrôle, c'est donc vous qui décidez quand passer le travail d'ingénierie pour intégrer un nouveau logiciel.
N'oubliez pas qu'il y a un coût à tout contrôler. Souvent, la mise à jour vers de nouvelles bibliothèques avec de nouvelles fonctionnalités entraîne des modifications indésirables de l'API, ce qui signifie corriger les incompatibilités dans le code (en d'autres termes, raser les yaks). Raser les yacks à 2 heures du matin lorsque l'application ne fonctionne pas n'est pas amusant. Heureusement, avec les conteneurs, vous pouvez revenir en arrière et raser les yacks le jour ouvrable suivant, mais cela vous prendra encore du temps pour apporter une nouvelle valeur à l'entreprise, de nouvelles fonctionnalités à vos applications. Bienvenue dans la vie d'un administrateur système.
OK, cela dit, il y a des moments où construire à partir de zéro a du sens. Je concéderai complètement que les programmes Golang compilés statiquement et les programmes C sont deux candidats décents pour les versions scratch/distroless. Avec ces types de programmes, chaque construction de conteneur est un événement de compilation. Vous devez toujours vous inquiéter de la rupture de l'API dans trois ans, mais si vous êtes un magasin Golang, vous devriez avoir les compétences nécessaires pour réparer les choses au fil du temps.
Conclusion
Fondamentalement, les distributions Linux font une tonne de travail pour vous faire gagner du temps, sur un système Linux standard ou avec des conteneurs. Les connaissances des mainteneurs sont énormes et tellement exploitées sans être vraiment appréciées. L'adoption de conteneurs a aggravé le problème car il est encore plus abstrait.
Avec les hôtes de conteneurs, une distribution Linux vous offre un accès à un vaste écosystème matériel, allant des minuscules systèmes ARM aux boîtiers géants 128 CPU x86, en passant par les machines virtuelles de fournisseur de cloud. Ils offrent des moteurs de conteneurs fonctionnels et des durées d'exécution de conteneurs prêtes à l'emploi, de sorte que vous pouvez simplement lancer vos conteneurs et laisser quelqu'un d'autre s'occuper de faire fonctionner les choses.
Pour les images de conteneurs, les distributions Linux vous offrent un accès facile à une tonne de logiciels pour vos projets. Même lorsque vous construisez à partir de zéro, vous regarderez probablement comment un responsable de paquet construit et expédie les choses - un bon artiste est un bon voleur - donc, ne sous-estimez pas ce travail.
Donc, merci à tous les mainteneurs de Fedora, RHEL (Frantisek, tu es mon héros), Debian, Gentoo et toutes les autres distributions Linux. J'apprécie le travail que vous faites, même si je suis un "gars des conteneurs".