Qu’est-ce qu’une infrastructure immuable?

introduction

Dans une infrastructure de serveur mutable traditionnelle, les serveurs sont mis à jour et modifiés en permanence. Les ingénieurs et les administrateurs travaillant avec ce type d'infrastructure peuvent utiliser SSH sur leurs serveurs, mettre à niveau ou rétrograder manuellement les packages, ajuster les fichiers de configuration serveur par serveur et déployer le nouveau code directement sur les serveurs existants. En d'autres termes, ces serveurs sont mutables; ils peuvent être changés après leur création. Une infrastructure composée de serveurs mutables peut elle-même être appelée mutable, traditionnelle ou (de façon désavantageuse) artisanale.

Unimmutable infrastructure est un autre paradigme d’infrastructure dans lequel les serveurs ne sont jamais modifiés après leur déploiement. Si quelque chose doit être mis à jour, corrigé ou modifié de quelque manière que ce soit, de nouveaux serveurs construits à partir d'une image commune avec les modifications appropriées sont configurés pour remplacer les anciens. Une fois validés, ils sont mis en service et les anciens sont mis hors service.

Une infrastructure immuable présente les avantages suivants: plus de cohérence et de fiabilité dans votre infrastructure, ainsi qu'un processus de déploiement plus simple et plus prévisible. Il atténue ou empêche totalement les problèmes courants dans les infrastructures mutables, telles que les serveurs à configuration dérivée et les serveurs flocon de neige. Cependant, son utilisation efficace inclut souvent une automatisation complète du déploiement, une mise en service rapide des serveurs dans un environnement informatique en nuage et des solutions de traitement des données dynamiques ou éphémères, telles que les journaux.

Le reste de cet article va:

Expliquer les différences conceptuelles et pratiques entre une infrastructure modifiable et immuable
Décrire les avantages d'utiliser une infrastructure immuable et contextualiser les complications
Donner une vue d'ensemble des détails de la mise en œuvre et des composants nécessaires pour une infrastructure immuable

Différences entre les infrastructures modifiables et immuables

La différence la plus fondamentale entre les infrastructures mutables et immuables réside dans leur politique centrale: les composants de la première sont conçus pour être modifiés après le déploiement; les composants de ce dernier sont conçus pour rester inchangés et finalement être remplacés. Ce tutoriel se concentre sur ces composants en tant que serveurs, mais il existe d'autres moyens d'implémenter une infrastructure immuable, comme avec les conteneurs, qui appliquent les mêmes concepts de haut niveau.

Pour aller plus en profondeur, il existe des différences à la fois pratiques et conceptuelles entre les infrastructures mutables et immuables basées sur serveur.

Conceptuellement, les deux types d’infrastructures varient considérablement en ce qui concerne le traitement des serveurs (par exemple, créé, maintenu, mis à jour, détruit). Ceci est généralement illustré par une analogie «animaux domestiques contre bétail».

Sur le plan pratique, l'infrastructure mutable est un paradigme d'infrastructure beaucoup plus ancien qui précède les technologies de base, telles que la virtualisation et l'informatique en nuage, qui permet de réaliser des infrastructures immuables. Connaître cette histoire aide à contextualiser les différences conceptuelles entre les deux et les implications de l’utilisation de l’une ou l’autre dans les infrastructures modernes.

Les deux prochaines sections traiteront de ces différences plus en détail.

Différences pratiques: embrasser le nuage

Avant que la virtualisation et l'informatique en nuage ne deviennent possibles et largement disponibles, l'infrastructure de serveur était centrée sur les serveurs physiques. Ces serveurs physiques étaient coûteux et longs à créer; la configuration initiale peut prendre des jours ou des semaines en raison du temps nécessaire pour commander un nouveau matériel, configurer la machine, puis l'installer dans uncolo ou un emplacement similaire.

L'infrastructure modifiable a ses origines ici. Le coût du remplacement d'un serveur étant si élevé, il était très pratique de continuer à utiliser les serveurs que vous avez exécutés aussi longtemps que possible, avec le moins de temps d'arrêt possible. Cela signifiait qu'il y avait beaucoup de changements en place pour les déploiements et les mises à jour réguliers, mais aussi pour les correctifs, ajustements et correctifs ad-hoc lorsque quelque chose n'allait pas. Les modifications manuelles fréquentes ont pour conséquence que la réplication des serveurs peut devenir difficile, faisant de chacun d'eux un élément unique et fragile de l'infrastructure globale.

L'avènement devirtualization and on-demand/cloud computing a représenté un tournant dans l'architecture des serveurs. Les serveurs virtuels étaient moins coûteux, même à grande échelle, et ils pouvaient être créés et détruits en quelques minutes au lieu de plusieurs jours ou de plusieurs semaines. Cela a rendu possible pour la première fois de nouveaux flux de travail de déploiement et de nouvelles techniques de gestion de serveur, comme l'utilisation deconfiguration management oucloud APIs pour provisionner de nouveaux serveurs rapidement, par programme et automatiquement. C'est la rapidité et le faible coût de création de nouveaux serveurs virtuels qui rendent le principe d'immutabilité pratique.

Les infrastructures mutables traditionnelles se développaient à l'origine lorsque l'utilisation de serveurs physiques dictaient ce qu'il était possible de gérer, et continuaient à se développer à mesure que la technologie évoluait. Le paradigme de la modification des serveurs après le déploiement est encore courant dans l'infrastructure moderne. En revanche, les infrastructures immuables ont été conçues dès le départ pour s’appuyer sur des technologies basées sur la virtualisation pour un provisioning rapide de composants d’architecture, tels que les serveurs virtuels du cloud computing.

Différences conceptuelles: animaux domestiques vs bovins, flocons de neige vs phénix

Le changement conceptuel fondamental de l'informatique en nuage avancé était que les serveurs pouvaient être considérés comme jetables. Il est extrêmement irréaliste d’envisager de supprimer et de remplacer des serveurs physiques, mais avec les serveurs virtuels, il est non seulement possible, mais facile et efficace de le faire.

Les serveurs des infrastructures mutables traditionnelles étaient irremplaçables et constituaient des systèmes uniques qui devaient continuer à fonctionner en permanence. De cette façon, ils ressemblaient à des animaux domestiques: uniques, inimitables et tendus à la main. En perdre un pourrait être dévastateur. Les serveurs dans des infrastructures immuables, par contre, sont jetables et faciles à reproduire ou à faire évoluer avec des outils automatisés. C’est ainsi qu’ils ressemblent à du bétail: l’un des nombreux animaux d’un troupeau où aucun individu n’est unique ou indispensable.

Pour citerRandy Bias, qui a d'abord appliqué les animaux vs. Analogie avec le cloud computing:

Dans l'ancienne façon de faire, nous traitions nos serveurs comme des animaux domestiques, par exemple Bob le serveur de messagerie. Si Bob tombe, tout est sur le pont. Le PDG ne peut pas recevoir son courrier électronique et c’est la fin du monde. À la nouvelle manière, les serveurs sont numérotés, comme du bétail dans un troupeau. Par exemple, www001 à www100. Lorsqu'un serveur tombe en panne, il est retiré, abattu et remplacé sur la ligne.

Une autre manière similaire d’illustrer les conséquences de la différence entre le traitement des serveurs consiste à utiliser les concepts de serveur flocon de neige et de serveur phoenix.

Snowflake servers sont similaires aux animaux de compagnie. Ce sont des serveurs gérés à la main, fréquemment mis à jour et mis au point, créant ainsi un environnement unique. Phoenix servers sont similaires aux bovins. Ce sont des serveurs toujours construits à partir de zéro et faciles à recréer (ou «renaître de leurs cendres») grâce à des procédures automatisées.

Les infrastructures immuables sont presque entièrement constituées de serveurs de bétail ou de phénix, alors que les infrastructures mutables permettent à certains (ou à plusieurs) animaux domestiques ou serveurs de flocon de neige. La section suivante traite des implications des deux.

Avantages de l'infrastructure immuable

Pour comprendre les avantages des infrastructures immuables, il est nécessaire de contextualiser les inconvénients des infrastructures mutables.

Les serveurs d’infrastructures mutables peuvent être affectés par la dérive de la configuration, ce qui se produit lorsque des modifications imprévues et non documentées entraînent une divergence croissante des configurations de serveurs, ainsi que de la configuration révisée, approuvée et déployée à l’origine. Ces serveurs, de plus en plus semblables à des flocons de neige, sont difficiles à reproduire et à remplacer, ce qui rend difficile la mise à l’échelle et la récupération des problèmes. Même la réplication de problèmes pour les déboguer devient difficile en raison de la difficulté de créer un environnement de transfert qui correspond à l'environnement de production.

Après de nombreuses modifications manuelles, l’importance ou la nécessité des différentes configurations d’un serveur devient floue. Par conséquent, la mise à jour ou la modification de celle-ci peut avoir des effets secondaires non souhaités. Même dans le meilleur des cas, il n’est pas garanti que les modifications apportées à un système existant fonctionnent, ce qui signifie que les déploiements reposant sur cette opération risquent d’échouer ou de placer le serveur dans un état inconnu.

En gardant cela à l'esprit, les principaux avantages de l'utilisation d'une infrastructure immuable sont la simplicité, la fiabilité et la cohérence du déploiement, qui minimisent ou éliminent en fin de compte de nombreux problèmes et points de défaillance courants.

État du serveur connu et bon et moins d'échecs de déploiement

Tous les déploiements dans une infrastructure immuable sont exécutés en mettant à disposition de nouveaux serveurs sur la base d'une image validée et contrôlée par la version. Par conséquent, ces déploiements ne dépendent pas de l'état précédent d'un serveur et, par conséquent, ne peuvent pas échouer - ou ne se terminer que partiellement - à cause de cela.

Lorsque de nouveaux serveurs sont mis en service, ils peuvent être testés avant leur mise en service, ce qui réduit le processus de déploiement réel à une seule mise à jour pour rendre le nouveau serveur disponible, comme pour la mise à jour d'un équilibreur de charge. En d'autres termes, les déploiements deviennentatomic: soit ils se terminent avec succès, soit rien ne change.

Cela rend le déploiement beaucoup plus fiable et garantit également que l'état de chaque serveur de l'infrastructure est toujours connu. De plus, ce processus facilite l'implémentation d'unblue-green deployment ourolling releases, ce qui signifie pas de temps d'arrêt.

Aucun serveur de dérive de configuration ou de flocon de neige

Toutes les modifications de configuration dans une infrastructure immuable sont implémentées en vérifiant une image mise à jour dans le contrôle de version avec documentation et en utilisant un processus de déploiement automatisé et unifié pour déployer des serveurs de remplacement avec cette image. L'accès Shell aux serveurs est parfois totalement limité.

Cela évite les configurations compliquées ou difficiles à reproduire en éliminant le risque de flocon de neige et de dérive de la configuration. Cela évite également les situations dans lesquelles une personne doit modifier un serveur de production mal compris, ce qui présente un risque d'erreur élevé et entraîne un temps d'arrêt ou un comportement imprévu.

Environnements de transfert cohérents et mise à l'échelle horizontale facile

Étant donné que tous les serveurs utilisent le même processus de création, il n'y a pas de cas d'extrémité de déploiement. Cela évite les environnements de transfert désordonnés ou incohérents en rendant simple la duplication de l'environnement de production, et simplifie égalementhorizontal scaling en vous permettant de manière transparente d'ajouter des serveurs identiques à votre infrastructure.

Processus simples de restauration et de restauration

L'utilisation du contrôle de version pour conserver l'historique des images facilite également la gestion des problèmes de production. Le même processus que celui utilisé pour déployer de nouvelles images peut également être utilisé pour revenir à des versions plus anciennes, en renforçant la résilience et en réduisant le temps de récupération lors de la gestion des temps d'arrêt.

Détails d'implémentation d'infrastructure immuable

Une infrastructure immuable comporte des exigences et des nuances dans ses détails de mise en œuvre, notamment par rapport aux infrastructures mutables traditionnelles.

Il est techniquement possible de mettre en place une infrastructure immuable, indépendante de tout principe d'automatisation, d'outillage ou de conception de logiciel, en adhérant simplement au principe clé de l'immutabilité. Cependant, les composants ci-dessous (à peu près par ordre de priorité) sont fortement recommandés pour des raisons pratiques à l'échelle:

Servers in a cloud computing environment, ou un autre environnement virtualisé (like containers, bien que cela modifie certaines autres exigences ci-dessous). La clé ici est d'avoir des instances isolées avec un provisionnement rapide à partir d'images personnalisées, ainsi qu'une gestion automatisée pour la création et la destruction via une API ou similaire.
Full automation of your entire deployment pipeline, incluant idéalement la validation d'image post-création. La configuration de cette automatisation augmente considérablement le coût initial de la mise en œuvre de cette infrastructure, mais il s’agit d’un coût ponctuel qui s’amortit rapidement.
Unservice-oriented architecture, séparant votre infrastructure en unités modulaires et logiquement discrètes qui communiquent sur un réseau. Cela vous permet de tirer pleinement parti des offres de cloud computing, qui sontsimilarly service-oriented (par exemple IaaS, PaaS).
Unstateless, volatile application layer qui inclut vos serveurs immuables. Tout ce qui se trouve ici peut être détruit et reconstruit rapidement à tout moment (volatil) sans aucune perte de données (sans état).
Unpersistent data layer qui comprend:
- Centralized logging avec des détails supplémentaires sur le déploiement d'un serveur, comme l'identification d'image via une version ou un commit Git SHA. Les serveurs étant jetables (et fréquemment éliminés) dans cette infrastructure, le stockage externe des journaux et des métriques permet le débogage même lorsque l'accès au shell est restreint ou après la destruction d'un serveur.
- External data stores pour les bases de données et toutes autres données avec état ou éphémères, telles queDBaaS/cloud databases etobject or block storage (fournies par le cloud ou autogérées). Vous ne pouvez pas compter sur le stockage local lorsque les serveurs sont volatils. Vous devez donc stocker ces données ailleurs.
Dedication from engineering and operations teams pour collaborer et s'engager dans la démarche. Malgré la simplicité du produit final, une infrastructure immuable comporte de nombreuses pièces en mouvement, et personne ne le saura tout. De plus, certains aspects du travail au sein de cette infrastructure peuvent être nouveaux ou situés en dehors des zones de confort des personnes, comme le débogage ou la réalisation de tâches uniques sans accès au shell.

Il existe de nombreuses façons d'implémenter chacun de ces composants. Le choix dépend en grande partie de vos préférences personnelles et de votre familiarité, et de la part de votre infrastructure que vous souhaitez construire vous-même par rapport à un service payant.

CI/CD tools peut être un bon point de départ pour l'automatisation du pipeline de déploiement; Compose est une option pour une solution DBaaS; rsyslog etELK sont des choix populaires pour la journalisation centralisée; Netflix’s Chaos Monkey, qui tue aléatoirement les serveurs de votre environnement de production, est une véritable épreuve par le feu pour votre configuration finale.

Conclusion

Cet article traite de ce qu'est une infrastructure immuable, des différences conceptuelles et pratiques entre cette infrastructure et une infrastructure mutable de style plus ancien, des avantages de son utilisation et des détails sur sa mise en œuvre.

Il peut être difficile de savoir si ou quand vous devriez envisager de passer à une infrastructure immuable, et il n’existe aucun point de coupure ou d’inflexion clairement défini. Pour commencer, appliquez certaines des pratiques de conception recommandées dans cet article, telles que la gestion de la configuration, même si vous travaillez toujours dans un environnement largement modifiable. Cela facilitera la transition vers l'immutabilité à l'avenir.

Si vous avez une infrastructure avec la plupart des composants ci-dessus et que vous vous retrouvez confronté à des problèmes de dimensionnement ou que vous vous sentez frustré par la lourdeur de votre processus de déploiement, cela peut être un bon moment pour commencer à évaluer comment une immuabilité pourrait améliorer votre infrastructure.

Vous pouvez en apprendre davantage sur plusieurs entreprises (dontCodeship,Chef,Koddi etFugue) qui ont écrit sur leurs implémentations d'infrastructure immuable.

TOC