Que sont les serveurs immuables?


23

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

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?

4
pas possible de muter
Evgeny

3
@Evgeny: ggggggggggggrrrrrrrrrrrrrrrr, j'étais proche, mais complètement faux avec ma supposition muette (veuillez ne pas rire de moi ...).
Pierre.Vriens


Je suis désolé d'être si franc, mais une simple recherche sur Internet pour définir "immuable" était-elle si coûteuse? Je comprends que la question est plus large que cela, mais rechercher le sens du mot plutôt que de deviner aurait pu vous donner une bonne longueur d'avance.
Adrian

@Adrian aucun problème à être émoussé (parce que je souffre d'ESL, je devrais google que pour vraiment obtenir le meening exact de émoussé). Cependant, je me demande si vous connaissez cette question meta.SA ? En dehors de cela, je préfère apprendre des experts DevOps, plutôt que des alternatives de type Wikipédia.
Pierre.Vriens

Réponses:


19

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.


"fermez l'ancien, évoquez le nouveau". Ou si votre architecture le permet, faites apparaître le nouveau, ajustez l'équilibreur de charge, arrêtez l'ancien. De cette façon, vous pouvez le faire à tout moment, même en pleine période de pointe. :)
Tim Malone

L'immuabilité, si elle provient de la programmation fonctionnelle (années 1960), on se rend compte maintenant que non seulement elle réduit les bugs (quelque chose qui est souvent négligé), mais aide également à la concurrence.
ctrl-alt-delor

Je serais vraiment intéressé par tout ajout à cette réponse fantastique sur la façon dont les agents de surveillance ou les logiciels supplémentaires qui pourraient être difficiles à intégrer dans l'original pourraient entrer en jeu ici. Par exemple, le logiciel de surveillance APM qui doit détecter son nouvel environnement de machine après la création et modifier les paramètres. J'explore SSM et l'automatisation pour déployer cela dans AWS, mais nous avons trouvé très peu de choses sur l'immuable avec les AMI / images lors du traitement d'agents supplémentaires qui pourraient être installés ultérieurement.
SheldonH

10

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.


1 Si nous ne comptons pas les tables à tisser automatiques ou les orgues à rouleaux comme des ordinateurs.


1
Wow, encore une autre explication intéressante, merci! Maintenant, j'ai vraiment du mal à décider quelle réponse marquer comme acceptée (patience à ce sujet s'il vous plaît, et sachez que je ne peux marquer que 1 au maximum, bien que pour le moment je ne sois pas du tout décidé sur laquelle.) .).
Pierre.Vriens

1
Avec plaisir! - Je pense que c'est une bonne idée d'attendre plusieurs jours pour accepter une réponse, cela augmente les chances des utilisateurs d'écrire plus de réponses.
Michael Le Barbier Grünewald

9

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.


Hm, intéressant ... J'ai besoin d'un peu de temps pour digérer davantage ... Connaître le dicton comme "1 réponse à une question déclenche 10 nouvelles questions?" ...
Pierre.Vriens

1
Cette pratique de «restauration» rapide est souvent appelée «déploiement bleu / vert» (également rouge / noir, selon qui fait l'appel).
Evgeny

@Evgeny et pire encore, pourraient également être appelés déploiements A / B, flou avec les expériences A / B. (et pire encore, lorsque ce type de déploiement, plusieurs versions de la même application, sont en direct pour faire des expériences A / B au lieu des indicateurs de fonctionnalité)
Tensibai

On m'a toujours dit que les déploiements bleus / verts étaient destinés au déploiement d'une mise à jour vers une application existante, PAS le serveur lui-même. @Evgeny
Turtle

Oui. Vous pouvez échanger des serveurs, des conteneurs, des applications et ainsi de suite et toujours l'appeler Bleu / Vert . Je pense que cela mérite son propre Q&A ici. Je voulais juste souligner que la façon dont vous avez expliqué le retour en arrière dans votre réponse est assez souvent appelée B / G.
Evgeny

6

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.


Explication intéressante, vous voudrez peut-être la muter un petit peu, si vous le pouvez, et si cela a du sens, pour élaborer sur quelque chose qui, je crois, est en quelque sorte lié, c'est-à-dire "rincer" un système. Ce que je pense, c'est que vous laissez (plus ou moins) quelqu'un "jouer" avec quelque chose et que vous le prévenez dès le départ (par exemple) chaque nuit, il y a une sorte de réinitialisation à un état initial. Il semble que l'entrée pour une telle réinitialisation soit ... euh ... qu'allais-je dire ... à droite: un truc immuable qui peut être utilisé pour cela.
Pierre.Vriens

2
L'exécution d'un service qui ramène le serveur à un état connu (tel qu'un Chef / Puppet / Ansible / etc ...) signifie simplement que vous n'utilisez pas de serveur immuable. en.wikipedia.org/wiki/Promise_theory est génial, mais martinfowler.com/bliki/ImmutableServer.html est encore mieux.
Evgeny

Tu me taquines je crois, ou est-ce plutôt "me défie" (pour essayer de découvrir la limite de questions quotidiennes). N'y a-t-il pas quelque part une règle SE qui dit "vous ne pouvez poser que 50 questions en 30 jours"?
Pierre.Vriens

0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.