Qu'est-ce qu'une infrastructure immuable ?

Les entreprises peuvent gérer l'infrastructure selon deux approches : modifiable et non modifiable. L'infrastructure immuable remplace entièrement les serveurs au lieu de les modifier. L’infrastructure modifiable modifie les serveurs en place, applique les mises à jour, les correctifs et les modifications de configuration directement aux serveurs de production.

Parce qu’il s’agit principalement de modifier les serveurs existants, l’infrastructure modifiable peut sembler plus efficace. Cependant, deux facteurs rendent souvent les infrastructures immuables plus pratiques et préférables.

Tout d’abord, le cloud computing et la conteneurisation ont transformé la vitesse de déploiement. Les entreprises peuvent désormais remplacer les machines virtuelles (VM) et les conteneurs en quelques minutes au lieu des heures nécessaires pour les serveurs physiques. Les outils d'automatisation de l'infrastructure permettent d'approvisionner et de configurer de nouveaux serveurs et ressources informatiques et d'appliquer des changements uniformes à grande échelle.

Deuxièmement, l’infrastructure immuable peut réduire considérablement la dérive de configuration, une fonctionnalité courante de l’infrastructure mutable, dans laquelle un système diverge progressivement de son état prévu au fur et à mesure que les modifications s’accumulent. Les écarts de configuration sont particulièrement courants lorsque des problèmes de réseau interrompent le processus de déploiement, entraînant des mises à jour partielles ou un échec. Cela peut entraîner de mauvaises performances, des vulnérabilités en matière de sécurité et des violations de conformité. 

Par exemple, lors du déploiement d’une mise à jour de sécurité sur 100 serveurs de production, les outils d’automatisation peuvent créer 100 nouveaux serveurs avec la mise à jour préinstallée et les valider en isolement. Une fois validés, ils redirigent le trafic et mettent hors service les anciens serveurs, le tout en quelques minutes, sans aucun temps d’arrêt.

L'infrastructure immuable suit un workflow en trois phases : provisionner de nouvelles ressources, les déployer et permettre une restauration instantanée en cas de besoin.

Ce workflow s'applique aux serveurs, aux conteneurs, aux VM, aux fonctions ou à toute autre Ressources d'infrastructure tout au long de son cycle de vie.

Le provisionnement crée automatiquement de nouveaux composants d'infrastructure informatique qui utilisent l'infrastructure sous forme de code (IaC), une pratique qui utilise des modèles déclaratifs ou du code pour définir les états prévus de l'infrastructure.

Pour mettre à jour un environnement immuable, les équipes créent une ressource entièrement nouvelle avec la configuration définie plutôt que d'utiliser SSH (un protocole réseau pour l'accès sécurisé à un serveur à distance) pour modifier les ressources existantes. 

Toutes les modifications apportées à l'infrastructure sont ensuite documentées dans des systèmes de contrôle de version tels que Git, ce qui garantit qu'elles sont testées et reproductibles.

Les outils de provisionnement courants sont les suivants : 

• Terraform : la plateforme d’infrastructure en tant que code de HashiCorp provisionne et gère l’infrastructure sur AWS, Google Cloud, Azure et les environnements sur site via ses API, avec une syntaxe HCL déclarative et des fichiers d’état pour suivre les modifications.

• Docker : crée des images de conteneurs légères basées sur des systèmes de fichiers en couches et une virtualisation au niveau du système d'exploitation, principalement sur les systèmes Linux, mais aussi Windows et macOS, permettant un déploiement plus rapide que les machines virtuelles traditionnelles.

• Packer : l'outil HashiCorp qui crée des images de machine identiques simultanément pour plusieurs fournisseurs de cloud et plateformes (AMIs pour AWS, modèles VMware, conteneurs Docker) à partir d'une seule configuration JSON ou HCL.

• AWS CloudFormation : outil natif d'AWS basé sur des modèles JSON/YAML pour fournir des ressources AWS avec une fonction intégrée de restauration et de détection des dérives. 

• Pulumi : plateforme IaC qui utilise des langages de programmation familiers (Python, TypeScript, Go) au lieu de langages spécifiques à un domaine, en permettant aux développeurs d'utiliser des constructions de programmation standard comme les boucles et les conditionnelles.

Il convient de mentionner que Puppet et Chef ont été conçus à l’origine pour une infrastructure mutable, où ils mettent à jour les serveurs en place, bien que certaines équipes les adaptent désormais aux approches immuables.

Les déploiements dans une infrastructure immuable sont atomiques : soit ils réussissent complètement, soit ils ne se produisent pas du tout. Cette approche s'aligne sur les pratiques DevOps et les pipelines d'intégration continue, qui mettent l'accent sur les tests automatisés, l'itération rapide et les déploiements fiables.

Les outils d'automatisation déploient la nouvelle version de la ressource, redirigent le trafic vers celle-ci, puis désaffectent l'ancienne version. Si des problèmes surviennent pendant le déploiement, l'ancienne ressource reste intacte et opérationnelle, ce qui élimine les temps d'arrêt et les risques de dépendance.

Les outils de déploiement et d'orchestration courants incluent : 

• Kubernetes : plateforme d'orchestration de conteneurs open source qui gère les applications cloud natif à l’échelle grâce à l'auto-réparation, à la mise à l'échelle automatique et aux mises à jour en continu sur des clusters de machines.

• Jenkins : pipelines CI/CD basés sur serveur qui automatisent la construction, les tests et le déploiement grâce à un vaste écosystème de plugins (plus de 1 800 plugins) permettant de personnaliser les pipelines de construction, de test et de déploiement.

• Actions GitHub : plateforme CI/CD pilotée par les événements intégrée aux référentiels GitHub, déclenchée par des validations de code, des pull requests ou des plannings sans avoir besoin de serveurs externes.

• Ansible (Red Hat) : il s'agit principalement d'un outil de gestion de la configuration, mais il est également utilisé pour les déploiements. Il utilise des protocoles YAML pour l'automatisation sans agent et ne nécessite aucune installation de logiciel sur les nœuds gérés, contrairement à Puppet ou Chef. 

Comme les serveurs des infrastructures immuables sont éphémères (ils sont constamment remplacés), les données persistantes doivent être stockées à l'extérieur. Les entreprises utilisent des cloud databases, block storage ou des services object storage pour conserver leurs données séparément des serveurs remplacés. 

Lorsqu'un nouveau serveur est mis en ligne, il se reconnecte aux données existantes par l'intermédiaire de ces systèmes de stockage externes. La configuration et les métadonnées sont souvent stockées dans des systèmes de contrôle de version comme Git. 

Chaque mise à jour crée une nouvelle instance, en conservant une image propre pour la restauration. Les mêmes outils d’automatisation qui provisionnent et déploient peuvent restaurer les versions précédentes en quelques minutes. Les équipes redéploient l'image précédente au lieu de déboguer et de dépanner les serveurs modifiés, ce qui réduit considérablement le travail de détective traditionnellement requis en cas d'échec des modifications de gestion de la configuration.

Les avantages d'une infrastructure immuable sont largement liés au processus de déploiement, que l'immuabilité rend plus simple et plus cohérent.

L’infrastructure immuable élimine les états de serveur ambigus grâce à des déploiements atomiques : les mises à jour réussissent complètement ou ne réussissent pas du tout.

Les infrastructures mutables risquent des mises à jour partielles qui conduisent à des états « intermédiaires » imprévisibles, avec des caractéristiques qui ne sont pas entièrement connues des administrateurs. Cette situation peut compliquer le dépannage et accroître les risques de sécurité.

Avec une infrastructure non modifiable, un tel état est impossible. Si une mise à jour échoue, le serveur reste dans son état bien documenté. En cas de succès, le nouveau serveur arrive entièrement configuré et testé.

Une infrastructure immuable permet une mise à l'échelle horizontale rapide, la pratique qui consiste à répondre à la demande en ajoutant un plus grand nombre de petites machines à un réseau (au lieu d'une seule grande machine). Un système mis à l’échelle horizontalement est plus tolérant aux pannes et peut réduire les goulets d’étranglement de traitement en répartissant sa workload.

Cette approche est réalisée en utilisant des équilibreurs de charge, qui distribuent le trafic réseau sur plusieurs serveurs afin d'améliorer les performances. Des outils comme Nginx et AWS Elastic Load Balancing (ELB) d'Amazon contribuent à cette pratique en utilisant un algorithme pour affecter les demandes des utilisateurs au serveur le plus efficace à un moment donné.

Cette combinaison d'équilibrage de charge et d'orchestration de conteneurs rend l'infrastructure immuable, avec ses modèles reproductibles, essentielle pour mettre en place plusieurs serveurs identiques dans un court délai. Cette configuration peut s'avérer particulièrement utile lorsque les réseaux s'attendent à des pics de trafic massifs, par exemple pendant les vacances ou la vente de billets. Cela facilite également la coordination entre les régions du monde où le trafic augmente à des heures différentes et se chevauche parfois.

L’infrastructure immuable renforce la sécurité en éliminant les « états en flocon de neige » imprévisibles, c’est-à-dire les serveurs dont la configuration est inconnue après l’échec des mises à jour, et en conservant des pistes d’audit complètes de toutes les modifications.

Chaque serveur est exactement conforme au fichier image source qui le décrit, ce qui facilite l'identification des failles de sécurité, telles que les installations logicielles non autorisées ou les élévations de privilèges, et la réalisation d'audits de sécurité. Les systèmes de contrôle de version permettent de suivre chaque modification apportée au système, en précisant qui l'a effectuée, quand et pourquoi. Cet historique immuable permet d'accélérer l'analyse médico-légale et la réponse aux incidents. Les équipes peuvent immédiatement identifier les configurations compromises et revenir à des états dont le fonctionnement a été vérifié si nécessaire.

Une infrastructure immuable élimine également la nécessité d'utiliser des connexions Secure Shell (SSH) pour modifier les serveurs en place, ce qui réduit la surface d'attaque globale du réseau.

L'immutabilité présente également des compromis par rapport à une infrastructure mutable plus traditionnelle, principalement en ce qui concerne le stockage de données.

Dans une infrastructure mutable, un serveur peut écrire des données d'application critiques sur le disque local, ce qui rend la suppression et le remplacement de ce serveur et de ce disque dangereux ou potentiellement destructeur pour le système. Par conséquent, dans une infrastructure non modifiable, les données doivent être magasinées à l'extérieur, ce qui ajoute un niveau de complexité supplémentaire au système.

Cette méthode peut être effectuée en utilisant un stockage de données externe, tel que des cloud databases, le block storage ou l'object storage. Lorsqu'une nouvelle machine virtuelle est mise en ligne, elle peut alors se reconnecter de façon fluide aux données existantes grâce à ce stockage. Les entreprises conservent généralement la configuration et les métadonnées dans des systèmes de contrôle de version comme Git.

Cependant, la véritable « immuabilité » d'une infrastructure non modifiable est parfois contestée. Cette limitation s’explique par le fait que les données des utilisateurs du réseau stockées en externe sont dans un état constant de flux et ne peuvent donc pas être comparées à un état connu.