Jour de sortie : Automatiser la distribution Linux (avec Ubuntu 20.04)

Bonjour à tous ! Je suis Brad, ingénieur système chez Linode. Aujourd'hui marque une journée riche en événements dans le monde Linux avec la sortie de Ubuntu 20.04, la prochaine version LTS (support à long terme) de l'une des distributions les plus populaires. Comme pour Ubuntu 18.04 il y a deux ans, nous nous attendons à ce que cette version devienne notre image la plus largement déployée, qui est déjà disponible pour tous les clients Linode.

La disponibilité des distributions le jour même est devenue la norme chez Linode, grâce à l'automatisation que nous avons développée autour de la construction, du test et du déploiement de nouvelles images. Mais qu'est-ce qu'une image (ou un modèle, comme on les appelle parfois), et que fait-on pour les créer ? Pour répondre à cette question, nous allons commencer par examiner comment les installations de systèmes d'exploitation fonctionnent généralement.

Installation d'un système d'exploitation

Vous connaissez peut-être le processus d'installation manuelle d'un système d'exploitation sur un ordinateur personnel ou un serveur. Il s'agit généralement de télécharger un fichier ISO d'installation, de le graver sur un CD ou une clé USB et de démarrer le système à partir de ce fichier. À partir de là, vous passez généralement par une série de menus (ou parfois de commandes manuelles) qui vous permettent de contrôler divers aspects de l'installation, tels que le disque dur sur lequel l'installation doit être effectuée, les logiciels/paquets que vous souhaitez inclure, et éventuellement quelques personnalisations telles que la définition d'un nom d'utilisateur et d'un mot de passe. Une fois l'installation terminée, vous disposez d'un système d'exploitation (espérons-le) entièrement fonctionnel, dans lequel vous pouvez démarrer et commencer à l'utiliser.

Ce processus fonctionne assez bien pour les utilisateurs individuels effectuant des installations ponctuelles, mais si vous devez installer plus d'une poignée de systèmes, le processus d'installation manuelle n'est tout simplement pas réalisable. C'est là que les images entrent en jeu.

Qu'est-ce qu'une image ?

Une image est essentiellement un système d'exploitation préinstallé que vous pouvez déployer sur autant de systèmes que nécessaire. Elle fonctionne en effectuant une installation normale une fois, puis en faisant une copie de cette installation que vous pouvez ensuite "coller" sur un autre système. Les images peuvent être stockées de différentes manières et sous différents formats en vue d'une utilisation ultérieure, mais il s'agit le plus souvent de copies exactes, octet par octet, de l'installation d'origine.

Désormais, nous n'avons plus besoin d'effectuer une installation manuelle qu'une seule fois, et nous pouvons la réutiliser partout ailleurs. Mais nous pouvons encore faire mieux. Linode supporte une grande variété de distributions, allant des suspects habituels (Debian, Ubuntu, CentOS, OpenSUSE) à certaines que vous ne trouverez pas chez d'autres fournisseurs (Alpine, Arch, et même Gentoo). Chacune d'entre elles a son propre calendrier de publication et sa propre durée de vie. Effectuer des installations manuelles pour toutes les distros supportées (ne serait-ce qu'une fois) et prendre le temps de s'assurer que les images résultantes fonctionnent et ne contiennent pas d'erreurs prendrait énormément de temps et serait sujet à de nombreux accidents. Nous avons donc choisi d'automatiser le processus de création d'images, à l'aide d'un merveilleux outil appelé Packer, créé par HashiCorp.

Automatiser la construction

Même si toutes les distributions Linux partagent une base commune (à savoir le noyau Linux), elles sont toutes très différentes les unes des autres, notamment en ce qui concerne la manière dont elles sont installées. Certaines distributions utilisent des instructions en ligne de commande, d'autres utilisent des interfaces de menu, et d'autres encore incluent des moyens de naviguer automatiquement et de fournir des réponses à ces menus. Heureusement, Packer est un outil très polyvalent et peut gérer tous ces cas d'utilisation.

La première chose à faire est de demander à Packer de créer une machine virtuelle (ou VM) qui ressemble le plus possible à un Linode. Cela signifie émuler le même "matériel" et les mêmes fonctionnalités que nous utilisons pour les Linodes réels. De cette façon, l'installation sera effectuée dans un environnement qui ressemble étroitement à l'environnement d'exécution final. Imaginez que vous installiez un système d'exploitation sur une clé USB et que vous utilisiez ensuite cette clé pour démarrer un ordinateur complètement différent. Si vous avez de la chance, les choses peuvent fonctionner, mais le plus souvent, un périphérique ne sera pas détecté ou l'ordinateur ne démarrera pas du tout. En ayant un environnement d'installation qui correspond à l'environnement réel, nous éliminons ces problèmes.

Une fois la VM créée, Packer la démarre à partir de l'ISO d'installation de la distribution, qu'il récupère à partir d'une URL spécifiée. Le processus à partir de là varie grandement d'une distribution à l'autre. Pour les distros pilotées par commandes comme Arch, nous lui fournissons un script bash qui effectue une installation de base. Pour les distributions pilotées par menu telles que Ubuntu, nous utilisons la méthode préférée de la distribution pour fournir des réponses à l'installateur (typiquement soit Preseed sur les distributions de type Debian, soit Kickstart sur les distributions de type RHEL). En plus de notre VM, Packer crée également un petit serveur HTTP qui permet de transférer tous les fichiers nécessaires dans la VM.

Tout ceci est contrôlé par un fichier JSON qui définit les paramètres et les options de construction que Packer utilisera. Pour initier un build, il suffit de lancer (par exemple) : packer build ubuntu-20.04.json.

Personnalisation

Dans la plupart des cas, nous effectuons des installations qui sont aussi "vanille" que possible. Cela signifie que nous installons tous les paquets que la distribution considérée considère comme "par défaut" (parfois appelés "base" ou "standard"). En plus de ces paquets par défaut, nous installons également une petite poignée de ce que nous appelons des paquets "support" : des utilitaires de base tels que iotop, mtr, et sysstat qui peuvent aider à déboguer tout problème qui pourrait survenir. Par conséquent, l'équipe d'assistance Linode peut raisonnablement supposer que ces outils sont installés lorsqu'elle assiste les clients.

Une fois l'installation terminée, mais avant que la VM ne soit arrêtée, nous procédons à quelques personnalisations finales afin de garantir le bon fonctionnement de toutes les fonctionnalités de la plateforme Linode. Par exemple, nous nous assurons que le chargeur de démarrage est configuré avec les paramètres corrects pour LISH (notre outil d'accès à la console hors bande). En général, nous essayons de garder les choses aussi proches que possible de leurs valeurs par défaut. De cette façon, un utilisateur qui préfère une distribution spécifique obtiendra ce qui lui est familier et n'aura pas l'impression de conduire la voiture de quelqu'un d'autre.

Emballage

Une fois l'installation et la configuration terminées, Packer ferme la VM et exporte son image disque vers un fichier. On pourrait croire que nous avons terminé, mais il reste encore quelques étapes à franchir. Le disque dur d'un ordinateur typique commence par une table de partition (soit MBR, soit GPT sur les systèmes plus récents). Les Linodes sont un peu uniques en ce sens que le chargeur de démarrage GRUB lui-même vit sur nos hôtes, plutôt que sur chaque Linode (la configuration est toujours lue depuis le Linode cependant). Cela signifie que nous pouvons en fait supprimer complètement la table de partition, nous laissant avec une seule partition.

Pour ce faire, nous lançons fdisk -l disk.img sur l'image du disque pour déterminer où la partition commence et se termine, et quelle est la taille du bloc. Nous utilisons ensuite dd if=disk.img of=part.img bs=### skip=### count=### afin de "déplacer" la partition en utilisant le décalage de départ de notre commande précédente. Plus précisément, chaque "###" de cette commande est remplacé par la sortie de notre commande précédente fdisk commandement.

Comme sur un nouvel ordinateur, la majeure partie de l'espace sur le disque sera vide, ce qui se reflétera dans notre image disque. Il serait stupide de copier tous ces octets "vides", c'est pourquoi la prochaine chose à faire est la suivante déflater l'image (plus tard, lorsque vous déployez une image sur votre Linode, nous regonfler pour remplir l'espace disponible sur votre instance). Puisque toutes nos images utilisent des partitions ext4, nous pouvons exécuter resize2fs -M part.imgqui réduira automatiquement notre image à sa plus petite taille possible en supprimant l'espace vide. Enfin, pour garantir l'intégrité de l'image résultante, nous effectuons un dernier fsck avant de le compresser avec gzip.

Essais

Une fois l'image construite et préparée, l'étape suivante du processus consiste à s'assurer qu'elle fonctionne réellement. Notre nouvelle image est déployée dans un environnement de test, où un certain nombre d'instances Linode sont provisionnées à partir de l'image dans un certain nombre de configurations différentes. Nous avons développé une suite de tests automatisés qui vérifie toutes sortes de choses différentes telles que la connectivité réseau et un gestionnaire de paquets fonctionnel, ainsi que diverses fonctionnalités de la plateforme Linode telles que Backups et le redimensionnement du disque ; nous lançons le livre à ces instances. Si une vérification échoue, le processus est immédiatement interrompu et la construction échoue, avec quelques détails sur la vérification qui a échoué et pourquoi.

Le fait de construire et de tester de manière automatisée permet des cycles de développement rapides qui, à leur tour, nous permettent de publier de meilleures images, plus rapidement. Nous avons structuré notre processus de test de manière à ce que l'ajout de nouvelles vérifications soit trivial. Si un client nous signale un problème avec l'une de nos images, nous pouvons rapidement publier un correctif et ajouter un nouvel élément à notre liste croissante de contrôles,un peu comme un système immunitaire !

Les mêmes, mais différents

Déployer en masse des systèmes à partir d'une image commune est une bonne chose, mais qu'en est-il des éléments propres à une instance spécifique, tels que le mot de passe root ou la configuration du réseau ? Nos images sont configurées pour utiliser le protocole DHCP, ce qui signifie que votre système recevra automatiquement l'adresse IP et le nom d'hôte qui lui ont été attribués par nos serveurs DHCP. Cependant, nous fournissons également une variété d'"aides" telles que Network Helper (qui configurera automatiquement le réseau statique sur votre Linode), et notre outil de réinitialisation du mot de passe racine (qui définit votre mot de passe racine initial et que vous pouvez également utiliser en cas d'urgence si vous avez besoin de le réinitialiser). Ces outils permettent d'appliquer à votre Linode des informations spécifiques à l'instance, en plus de l'image de base.

Bien entendu, toutes les distributions ne gèrent pas ces tâches de la même manière, et nos outils doivent donc savoir comment effectuer ces tâches sur toutes les distributions que nous supportons. Les nouvelles versions majeures d'une distribution nécessiteront généralement des mises à jour de ces systèmes afin que tout fonctionne parfaitement. Par exemple, Debian configure traditionnellement le réseau en /etc/network/interfacesalors que CentOS place les configurations de réseau dans /etc/sysconfig/network-scripts. Heureusement, la plupart des distros fournissent des versions bêta à l'avance, ce qui nous laisse suffisamment de temps pour effectuer ces changements et nous assurer que tout est prêt pour le jour du lancement.

Conclusion

Comme vous pouvez le voir, il y a beaucoup de choses qui entrent en jeu dans le support d'une nouvelle distribution, alors quel est le véritable avantage d'automatiser ce processus ? Eh bien, il y a des années, avant que nous n'ayons le processus que nous avons aujourd'hui, la sortie d'une distribution typique (de la construction à la disponibilité en passant par les tests) prenait au mieux une journée entière, mais généralement plusieurs jours, et de nombreuses personnes étaient impliquées. En comparaison, la sortie aujourd'hui de Ubuntu 20.04 n'a nécessité que 5 lignes de code et a pris moins d'une heure du début à la fin. Cette approche de la création d'images nous fait gagner beaucoup de temps, nous évite bien des tracas et nous permet d'obtenir des versions cohérentes qui sont testées en profondeur et constamment améliorées. Si vous avez des suggestions ou des choses que vous aimeriez voir, faites-le nous savoir ! Je suis sur IRC en tant que blaboon sur OFTC et lblaboon sur Freenode. Si vous souhaitez essayer Packer par vous-même, ils ont une excellente documentation que vous pouvez trouver ici. Nous avons également notre propre Linode builder pour Packer que vous pouvez utiliser pour créer vos propres images personnalisées sur notre plateforme. Vous trouverez de la documentation supplémentaire sur l'utilisation du Linode builder pour Packer dans notre bibliothèque Guides & Tutoriels ici.

Vous n'êtes pas client Linode ? Inscrivez-vous ici avec un crédit de 20 $.