Devops - A la recherche d'un système d'exploitation immutable !

Dans le meilleur des mondes :

• Nous n’avons plus de serveurs physiques toute infrastructure est provisionné dans le cloud via un système d’Infra As Code.
• Nos administrateurs systèmes ne connectent plus sur les serveurs physiques pour lancer des upgrades ou modifier des fichiers de configuration. Tout est pris en charge par notre gestionnaire de configuration.
• Toutes nos applications sont déployées sur des clusters Kubernetes, via des images où nous maîtrisons le versioning de toutes les dépendances et librairies.

Mais voilà, une partie de nos applications sont installées sur des serveurs physiques, sur lesquels il est difficile de tout maîtriser.

Alors pourquoi pas utilisé un système d’exploitation immutable ou tout est configuré via du code. Mais Existe-t-il de tels OS ?

Avant d’attaquer dans le vif du sujet, commençons par définir ce qu’est un système immutable.

Qu’est-ce qu’un système immutable ?

Pour définir immutable, je vais parler de son contraire.

Un système mutable est un système qui évolue par modification. Sur une VM, les librairies changent à chaque appel aux commandes d’installation ou d’upgrade de packages.

Donc un système immutable est un système ou tout est figé après leur provisioning. Si quelque chose doit être changé il faut qu’une nouvelle image du système soit produite. A tout moment, nous devons pouvoir revenir à un état antérieur sans complication.

Bien sûr, pour obtenir une infrastructure immutable, il faut que tout soit automatisé depuis le provisioning de celle-ci jusqu’à la livraison des applications sur les environnements de production. Mais le résultat obtenu est une infrastructure plus fiable ou tout devient plus prévisible.

Pourquoi chercher des systèmes d’exploitations immutables

Mes objectifs sont de pouvoir :

• Créer des images de système d’exploitation ou tout est versionné.
• Gérer facilement les rollbacks en cas d’erreurs ou de plantages.
• Les fichiers de configurations doivent être stocké dans un gestionnaire de source.

Des systèmes d’exploitations immutables

Si on recherche sur Google système d'exploitation immutable, on va obtenir une liste de système d’exploitation surtout destiné à héberger des conteneurs. Mais toutes nos applications ne peuvent pas être déployé ainsi, car elles ne sont pas Cloud Native.

J’ai donc retenu pour le moment que deux systèmes :

• Fedora CoreOS
• Flatcar
• Nixos

Fedora CoreOS

CoreOS à la base est une société qui a porté entre autre le projet Container Linux, un système d’exploitation léger conçu pour héberger des conteneurs et n’intégrant aucun gestionnaire de packages. RedHat a acheté cette société début 2018 pour développer un nouveau système d’exploitation appelé Redhat CoreOS. Ce nouvel OS est donc la fusion de Atomic Host avec Container Linux. Atomic Host apporte son gestionnaire de package rpm-ostree à Container Linux qui lui apporte l’outil Ignition.

Rpm-ostree est un système de packages qui permet de gérer les paquets comme des images de conteneurs. Il utilise les même repositories rpm que les OS classiques.

Ignition est une technologie similaire à cloud-init qui permet de démarrer et de configurer le serveur lors de son démarrage à partir d’un fichier déclaratif. Par contre, contrairement à cloud-init il ne permet pas d’installer des packages supplémentaires.

Il est a priori possible de construire ses propres images pour ajouter des packages supplémentaires.

Flatcar

Suite à un commentaire sur linkedin, j’ajoute à ma liste FlatCar qui est aussi un fork de Container Linux de CoreOS. Mais contrairement à Fedora CoreOS elle utilise Gentoo comme base. Gros point positif une documentation de qualité sur la partie ajout de packages.

Nixos

Nixos est une distribution Linux basée sur le gestionnaire de packages Nix. Pour créer un serveur tournant sous Nixos, il faut utiliser des fichiers de configurations déclaratifs pour tout configurer : le noyau, les applications, les services, les groupes, les utilisateurs, etc.

Il est possible de mettre à jour le système en modifiant ces fichiers de configuration. Il est possible de revenir à l’état antérieur à tout moment.

D’autres solutions ?

J’aurais pu envisager d’autres solutions comme :

• L’utilisation d’images construites avec packer, mais j’ai du mal à garantir la reproductibilité des images produites, surtout si elles sont faites à des dates différentes. Vous me direz, il suffit juste de les stocker.
• L’utilisation d’ignite mais pour le moment, c’est encore un peu jeune. De plus, le projet ne semble pas évolué, la dernière version date de juillet 2021 au moment où j’écris ces lignes.

Je vais tester les solutions Fedora CoreOS et Nixos dans les prochaines semaines et cela fera l’objet de billets dédiés. Je le ferai en utilisant des machines virtuelles provisionnées avec du Terraform.

Si vous connaissez d’autres solutions je suis preneur. Laissez un commentaire ci-dessous ou laissez-moi un message sur Linkedin.