Que sont les serveurs immuables?

Il y a quelques questions sur les serveurs immuables , telles que:

• Comment implémenter le modèle de serveur immuable sans perdre la possibilité de faire des post-mortems?
• Quel rôle jouent les outils de gestion de la configuration dans une infrastructure immuable?

Il semble évident que cela a à voir avec les serveurs (cette partie que je reçois). Et juste digérer la grammaire de l' immuable , je pense que cela a quelque chose à voir avec "pas possible de couper ". Si cette supposition est proche, je n'aurais aucune idée de ce qui ne peut pas être coupé (et je doute que cela ait à voir avec les cartes son ou quelque chose ...).

Mes questions :

• Qu'est-ce qu'un "serveur immuable" (dans le contexte de DevOps)?
• Pourquoi sont-ils utilisés?

L'immuabilité est un terme souvent utilisé dans les cercles de l'informatique, qui se résume généralement à "impossible à changer après la création". Il est généralement utilisé en référence au parallélisme, à la concurrence et à la sécurité des threads.

La discussion de ce sujet est fascinante, mais peut généralement être trouvée ailleurs sur Stack Overflow . Je résiste à l'envie de plonger ici. Le concept clé n'est «pas possible de changer après la création».

Imaginez si, sur Amazon, vous déployez un service Web en le transformant en image machine (AMI - une instance préconstruite que vous pouvez réapprovisionner à plusieurs reprises). Il se connecte à une base de données principale via des informations d'identification qu'il extrait d'un registre au démarrage. Il vide les journaux dans un outil de journalisation comme Splunk. Pour un fonctionnement quotidien normal, vous n'avez aucune raison de rentrer dans cette case. Si vous avez besoin de faire évoluer ce service, il vous suffit de créer plus d'instances de cette AMI et d'ajuster un équilibreur de charge. La rotation est simplement la destruction des instances et des équilibreurs de charge.

Pour le fonctionnement quotidien, cette case n'a aucune raison de changer . Nous pouvons simplement tirer plus loin de l'AMI.

Que se passe-t-il lorsque vous devez fournir un correctif de sécurité au niveau du système d'exploitation? C'est à ce moment-là que vous avez une décision à prendre ... créez-vous une nouvelle AMI avec le correctif installé et redéployez-vous toutes les instances en cours d'exécution, ou utilisez-vous des images existantes pour mettre à jour le correctif? Il y a beaucoup de gens qui voudraient simplement entrer. Les adeptes de l '«architecture immuable» m'ont simplement crié dessus pour avoir même suggéré qu'une telle chose était possible.

Les Immutabilistes (s'il y a un tel mot) préconisent la cuisson du nouvel ami. Ils préconisent de supprimer toute raison de ssh dans une machine jamais. Ils préconisent que toute configuration de machine spécifique se produise au démarrage de cette machine en extrayant les détails de configuration d'un référentiel. C'est l'expression ultime du «bétail, pas des animaux de compagnie».

L'architecture immuable concerne spécifiquement les configurations de machine qui n'ont aucune raison de changer après la création de l'image de la machine . Si quelque chose doit changer, créez une nouvelle image d'instance, arrêtez l'ancienne, affichez la nouvelle.

Les technologies du cloud ont déplacé la frontière entre le matériel et les logiciels, de sorte que de nombreuses opérations techniques, auparavant exclusives citoyennes du monde du matériel, font également partie du domaine logiciel. Les environnements informatiques partagés peuvent être aussi anciens que les ordinateurs eux-mêmes ^1, mais les technologies cloud peuvent les populariser en offrant des métaphores pratiques et familières pour interagir avec eux: les utilisateurs du cloud réservent une instance, un ordinateur complet ou une imitation, tandis que les environnements informatiques partagés plus anciens ont tous les paramètres possibles de limitations lourdes et «votre programme doit être téléchargé sur ce serveur FTP, s'exécutera dans l'environnement X (généralement avec une ancienne version de 10 ans du logiciel que vous souhaitez utiliser), pendant au plus 60 minutes» pourrait sembler familier aux utilisateurs anciens ou réels des centres de calcul.

La conséquence pratique de ce changement est que les procédures de déploiement peuvent désormais être représentées par des artefacts logiciels. (Les procédures de déploiement sont les instructions indiquant comment configurer une infrastructure, avec des bases de données, des serveurs Web ou tout ce qui appartient à cette infrastructure, ainsi que le réseau sur lequel elles fonctionnent.) Adaptée à ces nouveaux objectifs, la maintenance manuelle des serveurs ressemble à peu près à correctif manuel du code de production - ce qui n'est que dans de très rares occasions une chose souhaitable. La maintenance manuelle est susceptible d'introduire des écarts entre les systèmes en cours d'exécution en production et le code décrivant ces systèmes, ce qui signifie à son tour un comportement irréproductible et une analyse de bogue impossible, une correction de bogue double et d'autres calamités.

Le modèle de serveur immuable n'est que la transposition pour les opérations cloud du mantra ci-dessus, selon laquelle nous devrions éviter la maintenance manuelle des programmes en cours d'exécution. Au lieu de configurer manuellement les serveurs, le modèle de serveur immuable recommande d'automatiser cette configuration.

Saveurs de mise en œuvre

Bien que l'idée générale du modèle de serveur immuable soit assez claire, il existe de nombreuses nuances d'implémentation. Par exemple, certaines approches suggèrent de ne pas mettre à jour les serveurs du tout mais de remplacer systématiquement les serveurs à la place. En effet, la mise à jour donne une situation où un déploiement se compose de serveurs ayant été démarrés à plusieurs moments distincts et ayant subi plusieurs processus de mise à jour distincts, ce qui implique un ensemble de serveurs non homogène et peut entraîner des différences subtiles dans la façon dont les serveurs gèrent leurs tâches. Un deuxième point de variation populaire est la discipline concernant l'accès à distance aux serveurs. Certains aiment désactiver l'accès administratif complètement distant aux serveurs, afin de garantir que la maintenance manuelle ne se produira jamais.

Note historique

À ma connaissance, le terme «serveur immuable» a été popularisé par Kief Morris, mais l'idée elle-même est beaucoup plus ancienne. En 1999, les prisons FreeBSD ont déjà popularisé l'idée d'automatiser entièrement la configuration des environnements informatiques jetables, c'est ainsi que j'ai commencé à implémenter le modèle de «serveur immuable» de nombreuses années avant d'entendre ce nom pour décrire cette technique.

L'immuabilité, sous forme d'immuabilité physique basée sur des CD-ROM, a également été une mesure populaire pour fabriquer des systèmes informatiques fiables. Cela ne doit pas être confondu avec le modèle de serveur immuable.

Les serveurs immuables sont des serveurs sur lesquels aucune modification ne peut être apportée (à part les mises à jour et les correctifs de sécurité idéalement). Au lieu de modifier le logiciel sur le serveur, vous mettez en file d'attente un nouveau serveur avec le logiciel souhaité, puis fermez l'ancien.

Ce concept permet de garantir que votre serveur de test, de développement et d'assurance qualité sont tous identiques, ce qui est important pour de multiples raisons hors de la portée de cette question. Un autre avantage des serveurs immuables est la possibilité de restaurer l'application sur un serveur plus ancien. Par exemple, je dois changer K sur le serveur de production 1, donc je spoule le serveur 2 et change K. Maintenant, après 10 minutes, je remarque que K a cassé quelque chose avec mon application, plutôt que d'avoir à le réparer immédiatement, ce qui pourrait prendre des heures et potentiellement provoquer des temps d'arrêt pour mes clients, je redirige le trafic vers le serveur 1, tandis que je trouve ce qui ne va pas avec 2.

La meilleure explication peut être trouvée (comme toujours) dans l'article bliki de Martin Fowler sur les serveurs immuables .

Un serveur, qu'il s'agisse de matériel ou d'un serveur virtuel dans le cloud, est généralement doté d'un système d'exploitation et d'une application.

Souvent, l'application et les composants du système d'exploitation nécessitent une configuration et des modifications doivent être appliquées. Par exemple, les correctifs de sécurité, le déploiement de nouvelles versions de l'application et les modifications de configuration.

Lorsque vous considérez que tout changement est une mutation de l'état du serveur, le terme immutablecommence à avoir plus de sens. Cela signifie qu'aucune mutation n'est autorisée sur un tel serveur.

C'est souvent le cas, lorsque des personnes sont impliquées dans le changement d'état du serveur - que ce soit le déploiement d'une version, un changement de configuration ou un chemin de sécurité. Le résultat est un serveur qui ne fonctionne plus comme prévu. Par exemple, l'application peut ne pas s'exécuter maintenant en raison d'une mauvaise configuration, etc.

C'est pourquoi une pratique de création de serveurs immuables est établie. Avec des serveurs immuables , une image d'un serveur est créée avec toute la configuration, les correctifs et les versions d'application regroupés. Ensuite, cette image de serveur peut être utilisée pour créer des serveurs dans divers environnements.

Le premier environnement où une telle image est utilisée, serait un environnement où l'image peut être testée pour fonctionner. Toutes les anomalies sont détectées et ce n'est qu'alors qu'une telle image peut être promue dans un environnement de production pour y remplacer les serveurs par la nouvelle version (qui est connue pour bien fonctionner).

Une fois que le processus de création des images et de promotion des images est automatisé, vous obtenez un processus très résistant aux pannes qui implique très peu d'efforts humains et très peu de chances d'introduire une défaillance dans votre service.

Souvent, les serveurs immuables n'incluent même aucun moyen de les "entrer", comme par exemple le serveur ssh est manquant. Dans ce cas, il arrive aussi souvent que toute la métrologie d'un serveur (métriques, journaux) soit expédiée à des systèmes externes tels qu'une base de données de métriques ou un service d'agrégation de journaux.

Avec les conteneurs (voir: Docker ), il existe également un processus pour créer des images, puis les générer dans des conteneurs en cours d'exécution. Ceux-ci sont assez souvent remplacés par de nouveaux conteneurs basés sur des images mises à jour, et ne sont jamais mutés. Cela signifie qu'aucun humain n'entre dans le conteneur pour "réparer quelque chose" en introduisant un changement.

Commençons par l'inverse, qu'est-ce qu'un serveur mutable?

Traditionnellement, une infrastructure de serveur modifiable est une infrastructure qui est continuellement modifiée et mise à jour sur place. Vous pouvez y sécuriser le shell, mettre à niveau les packages, le configurer, installer des services et y déployer du nouveau code. C'est ce qui le rend mutable, vous pouvez le muter ou le modifier.

Une infrastructure immuable 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, réparé ou modifié de quelque manière que ce soit, de nouveaux serveurs construits à partir d'une image commune avec les modifications appropriées sont provisionnés pour remplacer les anciens. Une fois validés, ils sont mis en service et les anciens sont mis hors service.

Pourquoi sont-ils utilisés? Les avantages d'une infrastructure immuable sont plus de cohérence et de fiabilité dans votre infrastructure et un processus de déploiement plus simple et plus prévisible et elle atténue les problèmes de serveur courants dans l'infrastructure mutable, tels que les temps d'arrêt à partir du crash du serveur ou autre.

Mais vous devez savoir comment l'approvisionner efficacement via des automatisations de déploiement complètes et un approvisionnement rapide du serveur.

Imaginez que vous extrayez du bitcoin, vous ne voudriez aucun temps d'arrêt si votre serveur tombait en panne, vous en auriez besoin de sauvegarder le plus rapidement possible, donc une infrastructure immuable est censée être la solution.