L'infrastructure comme code: première connaissance

Notre entreprise est en train d'intégrer l'équipe SRE. Je suis entré dans toute cette histoire du côté du développement. Au cours du processus, j'ai eu des réflexions et des idées que je souhaite partager avec d'autres développeurs. Dans cet article de méditation, je parle de ce qui se passe, comment cela se passe et comment tout le monde peut vivre avec.

Suite d'une série d'articles basés sur des discours lors de notre événement DevForum interne :

1. Chat Schrodinger sans boîte: le problème du consensus dans les systèmes distribués.
2. Infrastructure comme code. (Vous êtes ici)
3. Génération de contrats dactylographiés pour les modèles c #. (En cours ...)
4. Comment les serveurs s'accordent les uns avec les autres: algorithme de consensus distribué Raft.
5. L' infrastructure comme code: comment surmonter les problèmes avec XP.
...

Nous avons décidé de faire en sorte que l'équipe SRE implémente les idées google sre . Nous avons recruté des programmeurs de leurs propres développeurs et les avons envoyés étudier pendant plusieurs mois.

L'équipe a été confrontée aux tâches de formation suivantes:

• Décrivez notre infrastructure, qui est principalement dans Microsoft Azure sous forme de code (Terraform et tout ce qui l'entoure).
• Apprenez aux développeurs à travailler avec l'infrastructure.
• Préparez les développeurs au devoir.

Présentation du concept d'infrastructure en tant que code

Dans le modèle habituel du monde (administration classique), la connaissance des infrastructures se situe à deux endroits:

1. Ou sous forme de connaissances dans l'esprit des experts.
2. Ou cette information se trouve sur certaines machines à écrire, dont certains connaissent les experts. Mais pas le fait qu'une personne de l'extérieur (au cas où toute notre équipe décède soudainement) sera en mesure de comprendre quoi et comment cela fonctionne. Il peut y avoir beaucoup d'informations sur la machine: accessoires, bouchons couronne, un lecteur (voir montage de disque ) et juste une liste interminable de ce qui peut arriver. Il est difficile de comprendre ce qui se passe dans la réalité.

Dans les deux cas, nous sommes pris au piège, devenant dépendants:

• ou d'une personne mortelle, sensible à la maladie, tombant amoureux, aux sautes d'humeur et aux licenciements tout simplement banals;
• ou d'une machine qui fonctionne physiquement et qui tombe, vole, présente des imprévus et des inconvénients.

Il va sans dire qu'idéalement, tout devrait être traduit en code écrit lisible par l'homme, pris en charge et de haute qualité.

Ainsi, l'infrastructure en tant que code (Incffrastructure as Code - IaC) est une description de l'ensemble de l'infrastructure disponible sous forme de code, ainsi que des outils associés pour travailler avec elle et pour en réaliser l'infrastructure.

L'infrastructure comme problème de code

Voyons maintenant des exemples de la façon dont l'infrastructure peut être câblée en code. Le code est bien écrit, de haute qualité, avec des commentaires et des retraits.

Exemple de code de Terraforma.



Exemple de code d'Ansible.



Messieurs, mais si tout était si simple! Nous sommes avec vous dans le monde réel, et il est toujours prêt à vous surprendre, à présenter des surprises, des problèmes. Pas sans eux ici.

1. Le premier problème est que dans la plupart des cas, l'IaC est une sorte de DSL.

Et DSL, à son tour, est une description de la structure. Plus précisément, ce que vous devriez avoir: Json, Yaml, des modifications de certaines grandes entreprises qui ont créé leur propre dsl (HCL est utilisé dans la terraform).

Le problème est qu'il ne peut y avoir facilement aucune chose familière comme:

• Variables
• conditions;
• quelque part il n'y a pas de commentaires, par exemple dans Json, par défaut ils ne sont pas fournis;
• les fonctions
• et je ne parle pas de choses de haut niveau comme les classes, l'héritage et tout ça.

2. Le deuxième problème avec ce code est le plus souvent un environnement hétérogène . Habituellement, vous vous asseyez et travaillez avec C #, c'est-à-dire avec une langue, une pile, un écosystème. Et ici, vous avez une grande variété de technologies.

C'est une situation très réelle quand un bash avec python démarre un processus dans lequel Json glisse. Vous l'analysez, puis un autre générateur génère 30 autres fichiers. Pour tout cela, les variables d'entrée d'Azure Key Vault entrent, qui sont rassemblées par le plugin pour drone.io écrit en Go, et ces variables passent par yaml, qui a été obtenu à la suite de la génération à partir du moteur de modèle jsonnet. Il est assez difficile d'avoir un code strictement bien décrit lorsque vous avez un environnement aussi diversifié.

Le développement traditionnel dans le cadre d'une tâche est livré avec une seule langue. Ici, nous travaillons avec un grand nombre de langues.

3. Le troisième problème est la décision . Nous sommes habitués à refroidir les éditeurs (Ms Visual Studio, Jetbrains Rider) qui font tout pour nous. Et même si nous sommes ternes, ils diront que nous avons tort. Cela semble normal et naturel.

Mais quelque part à proximité, il y a un VSCode, dans lequel il y a des plugins qui sont installés, pris en charge ou non. De nouvelles versions ont été publiées et n'ont pas été prises en charge. Une transition banale vers l'implémentation d'une fonction (même si elle existe) devient un problème complexe et non trivial. Un simple renommage d'une variable est une relecture dans un projet d'une dizaine de fichiers. C'est une chance si c'est quelque chose qui doit être corrigé. Bien sûr, il y a du rétro-éclairage à certains endroits, il y a de la compilation automatique, quelque part il y a du formatage (même si je n'ai pas démarré les fenêtres dans la terraform).

Au moment de l'écriture, le plugin vscode-terraform n'était pas encore sorti pour supporter la version 0.12, bien qu'il soit déjà sorti depuis 3 mois.

Il est temps d'oublier ...

1. Débogage
2. Outil de refactoring.
3. Complétion automatique.
4. Détecte les erreurs de compilation.

C'est drôle, mais cela augmente également le temps de développement et augmente le nombre d'erreurs qui se produisent inévitablement.

Le pire est que nous sommes obligés de ne pas penser à la façon de concevoir, de décomposer des fichiers en dossiers, de décomposer, de rendre le code supportable, lisible, etc., mais de savoir comment j'écrirais correctement cette commande, parce que je l'ai en quelque sorte mal écrite .

En tant que débutant, vous essayez d'apprendre des terraformes, et l'IDE ne vous aide pas du tout. Quand il y a de la documentation - ils sont entrés, ont regardé. Mais si vous deviez entrer un nouveau langage de programmation, l'EDI suggérerait qu'il existe un tel type, mais il n'y en a pas. Au moins au niveau int ou chaîne. C'est souvent utile.

Mais qu'en est-il des tests?

Vous demandez: "Qu'en est-il des tests, messieurs les programmeurs?" Les gars sérieux testent tout sur la prod, et c'est difficile. Voici un exemple de test unitaire pour le module terraform du site Web de Microsoft .



Ils ont une bonne documentation. J'ai toujours aimé Microsoft pour son approche de la documentation et de la formation. Mais vous n'avez pas besoin d'être l'oncle Bob pour comprendre que ce n'est pas un code idéal. Notez la validation rendue à droite.

Le problème avec le test unitaire est que vous et moi pouvons vérifier l'exactitude de la sortie de Json. J'ai lancé 5 paramètres, on m'a donné un footcloth Json pour 2000 lignes. Je peux analyser ce qui se passe ici, valider le résultat du test ...

Il est difficile d'analyser Json dans Go. Et vous devez écrire en Go, car les terraforms on Go sont une bonne pratique de ce que vous testez dans la langue dans laquelle vous écrivez. L'organisation même du code est très faible. En même temps, c'est la meilleure bibliothèque pour les tests.

Microsoft écrit lui-même ses modules, les testant de cette manière. Bien sûr, c'est Open Source. Tout ce dont je parle, vous pouvez venir le réparer. Je peux m'asseoir et tout réparer en une semaine, ouvrir des plugins VS-code, des terraforms, faire un plugin rider. Peut-être écrire quelques analyseurs, visser les linters, copier la bibliothèque pour les tests. Je peux tout faire. Mais je n'ai pas à le faire.

Infrastructure des meilleures pratiques en tant que code

Nous allons plus loin. S'il n'y a pas de tests en IaC, mauvais avec l'IDE et le réglage, alors il devrait y avoir au moins les meilleures pratiques. Je suis juste allé sur Google Analytics et j'ai comparé deux requêtes de recherche: les meilleures pratiques Terraform et les meilleures pratiques C #.



Que voyons-nous? Des statistiques impitoyables ne sont pas en notre faveur. Par la quantité de matériel - la même chose. Dans le développement C #, nous nous baignons simplement dans les matériaux, nous avons des pratiques exemplaires, il y a des livres écrits par des experts, et aussi des livres écrits sur des livres par d'autres experts qui critiquent ces livres. La mer de la documentation officielle, des articles, des cours de formation, désormais aussi le développement open source.

En ce qui concerne la demande IaC: ici, vous essayez petit à petit de collecter les informations des rapports de la surcharge ou de HashiConf, de la documentation officielle et de nombreux problèmes sur le github. Comment diffusez-vous ces modules, que faire avec eux? Il semble que ce soit un vrai problème ... Il y a une communauté, messieurs, où vous recevrez 10 commentaires sur un github pour toute question. Mais ce n'est pas exact.

Malheureusement, à l'heure actuelle, des experts commencent tout juste à apparaître. Bien qu'il y en ait trop peu. Et la communauté elle-même se bloque au niveau des primordiums.

Où tout cela va-t-il et que faire

Vous pouvez tout laisser tomber et revenir en C #, dans le monde d'un cavalier. Mais non. Pourquoi feriez-vous cela même si vous ne trouviez pas de solution. Ensuite, je donne mes conclusions subjectives. Vous pouvez discuter avec moi dans les commentaires, ce sera intéressant.

Personnellement, j'ai mis quelques choses:

1. Le développement dans ce domaine est très rapide. Je donne le calendrier des demandes de DevOps.
   
   
   
   Peut-être que le sujet est hype, mais le fait que la sphère se développe nous donne de l'espoir.
   
   Si quelque chose se développe si vite, des personnes intelligentes apparaîtront sûrement qui diront comment le faire et comment ne pas le faire. L'augmentation de la popularité conduit au fait que peut-être quelqu'un aura enfin le temps d'ajouter le plugin jsonnet pour vscode, ce qui nous permettra de procéder à la mise en œuvre de la fonction, plutôt que de la rechercher via ctrl + shift + f. Lorsque tout se développe, plus de matériaux apparaissent. Le même livre Google sur SRE est un excellent exemple.
2. Il existe des techniques et des pratiques développées dans le développement conventionnel que nous pouvons appliquer avec succès ici. Oui, il y a des nuances avec les tests et un environnement hétérogène, un réglage insuffisant, mais un grand nombre de pratiques ont été accumulées qui peuvent être utiles et utiles.
   
   Un exemple trivial: la collaboration via la programmation par paires. Cela aide beaucoup à le comprendre. Lorsque vous avez un voisin à proximité qui essaie également de comprendre quelque chose, vous comprendrez mieux ensemble.
   
   Comprendre comment se fait le refactoring aide à le produire même dans une telle situation. Autrement dit, vous ne pouvez pas tout changer en même temps, mais changez le nom, puis changez l'emplacement, puis il peut mettre en évidence une partie, oh, mais il n'y a pas assez de commentaires.

Conclusion

Malgré le fait que mon raisonnement puisse sembler pessimiste, j'attends avec impatience l'avenir et j'espère sincèrement que nous (et vous) réussirons.

Vient ensuite la deuxième partie de l'article . J'y explique comment nous avons utilisé des pratiques de programmation extrêmes pour améliorer notre processus d'apprentissage et travailler avec l'infrastructure.