Dans notre entreprise, nous sommes en train d'intégrer l'équipe SRE. J'ai abordé toute cette histoire du point de vue 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 réflexion, je parle de ce qui se passe, comment cela se passe et comment tout le monde peut vivre avec cela par la suite.
Suite de la série d'articles inspirés des présentations lors de notre événement interne. :
2. Infrastructure as code. (Vous êtes ici)
3. Génération de contrats Typescript à partir de modèles C#. (En cours…)
4. Introduction à l'algorithme de consensus Raft. (En cours…)
…
Nous avons décidé de créer une équipe SRE, en mettant en œuvre des idées de . Nous avons recruté des programmeurs parmi nos propres développeurs et les avons envoyés se former pendant plusieurs mois.
L'équipe avait les objectifs d'apprentissage suivants :
- Décrire notre infrastructure, qui se trouve principalement dans Microsoft Azure, sous forme de code (Terraform et tout ce qui s'y rapporte).
- Former les développeurs à travailler avec l'infrastructure.
- Préparer les développeurs aux astreintes.
Nous introduisons le concept d'Infrastructure as code.
Dans un modèle traditionnel (administration classique), les connaissances sur l'infrastructure se trouvent à deux endroits :
- Soit sous forme de connaissances dans l'esprit des experts.
- Soit ces informations se trouvent sur certaines machines, dont une partie est connue des experts. Mais il n'est pas sûr qu'une personne extérieure (si toute notre équipe venait à disparaître subitement) puisse comprendre comment cela fonctionne. Sur la machine, il peut y avoir beaucoup d'informations : accès, cron jobs, montage de disque (voir ) et simplement une liste infinie de ce qui peut se passer. Il est difficile de comprendre ce qui se passe réellement.
Dans les deux cas, nous nous retrouvons piégés, devenant dépendants :
- soit d'une personne, qui est mortelle, sujette à des maladies, des amours, des variations d'humeur et simplement à des licenciements banals ;
- soit d'une machine fonctionnelle, qui peut aussi tomber en panne, être volée, renvoyer des surprises et des désagréments.
Il s'impose donc de trouver une solution, à savoir qu'idéalement, tout doit être traduit en code lisible par l'homme, maintenable et de qualité.
Ainsi, l'infrastructure en tant que code (Infrastructure as Code – IaC) est la description de toute l'infrastructure existante sous forme de code, ainsi que les outils associés pour travailler avec elle et en déployer la véritable infrastructure.
Pourquoi tout traduire en codeLes humains ne sont pas des machines. Ils ne peuvent pas tout mémoriser. La réaction d'un humain et celle d'une machine sont différentes. Tout ce qui est automatisé fonctionne potentiellement plus rapidement que tout ce que fait un humain. La chose la plus importante est une source unique de vérité (single source of truth).
D'où viennent les nouveaux ingénieurs SREDonc, nous avons décidé d'intégrer de nouveaux ingénieurs SRE, mais d'où les obtenir ? Le livre avec les bonnes réponses () nous dit : des développeurs. Après tout, ils travaillent avec du code, et vous atteignez l'état idéal.
Nous avons beaucoup et longtemps cherché sur le marché du travail en dehors de notre entreprise. Mais nous devons admettre que nous n'avons trouvé personne qui corresponde à nos demandes. Nous avons dû fouiller parmi nos propres employés.
Problèmes de l'infrastructure en tant que code
Regardons maintenant des exemples de la façon dont l'infrastructure peut être intégrée dans le code. Le code est bien écrit, de qualité, avec des commentaires et une bonne indentation.
Exemple de code à partir de Terraform.
Exemple de code à partir d'Ansible.
Messieurs, mais si tout était si simple ! Nous sommes dans le monde réel, et il est toujours prêt à vous surprendre, à vous présenter des défis et des problèmes. Il y en a aussi ici.
1. Le premier problème est que, dans la plupart des cas, IaC est un certain dsl.
Un DSL, à son tour, est une description de la structure. Plus précisément, ce que vous devez avoir : Json, Yaml, des modifications provenant de certaines grandes entreprises qui ont créé leur propre dsl (Terraform utilise HCL).
Le problème est qu'il peut facilement ne pas contenir des choses qui nous semblent familières telles que :
- variables ;
- conditions ;
- quelque part, il n'y a pas de commentaires, par exemple, en Json, ils ne sont pas prévus par défaut ;
- fonctions ;
- et je ne parle même pas de choses de haut niveau comme les classes, l'héritage et tout ça.
2. Le deuxième problème de ce code – la plupart du temps, c'est un environnement hétérogène. En général, vous êtes assis et travaillez avec C#, c'est-à-dire avec un seul langage, une seule pile, un seul écosystème. Et là, vous avez une énorme diversité de technologies.
Une situation tout à fait réelle est qu'un bash avec Python lance un processus dans lequel on insère du JSON. Vous l'analysez, puis un autre générateur produit encore 30 fichiers. Pour tout cela, il y a des variables d'entrée provenant d'Azure Key Vault, qui sont extraites par un plugin pour drone.io, écrit en Go, et ces variables passent par un YAML, généré à partir du moteur de templating jsonnet. Il est assez complexe d'avoir un code strictement bien décrit lorsque vous avez un environnement aussi varié.
Le développement traditionnel dans le cadre d'une seule tâche se fait dans un seul langage. Ici, nous travaillons avec de nombreux langages.
3. Le troisième problème est l'outillage. Nous sommes habitués à des éditeurs puissants (Ms Visual Studio, Jetbrains Rider), qui font tout pour nous. Et même si nous faisons une erreur, ils nous disent que nous avons tort. On a l'impression que c'est normal et naturel.
Mais il y a à côté VSCode, qui a certains plugins, qui sont installés, soutenus ou non. De nouvelles versions sortent et ne sont pas prises en charge. Un simple passage à l'implémentation d'une fonction (même si elle existe) devient un problème complexe et non trivial. Un simple renommage de variable se transforme en un remplacement dans un projet de plusieurs fichiers. On a de la chance si cela remplace ce qui doit l'être. Bien sûr, il y a un certain éclairage, une autocomplétion, où il y a du formatage (mais chez moi, ça n'a pas fonctionné dans Terraform sous Windows).
Au moment de la rédaction de cet article n'a pas encore été publié pour prendre en charge la version 0.12, bien qu'elle soit sortie depuis 3 mois.
Il est temps d'oublier…
- le débogage.
- l'outil de refactorisation.
- l'autocomplétion.
- la détection des erreurs lors de la compilation.
C'est drôle, mais cela augmente le temps de développement et le nombre d'erreurs qui se produisent inévitablement.
Le plus terrifiant, c'est que nous sommes forcés de ne pas penser à comment concevoir, organiser les fichiers dans les dossiers, décomposer, rendre le code maintenable, lisible, etc., mais à comment écrire correctement cette commande, parce que je l'ai écrite d'une manière incorrecte.
En tant que débutant, vous essayez de comprendre Terraform, mais l'IDE ne vous aide pas du tout. Quand il y a de la documentation – vous y accédez, vous regardez. Mais si vous découvriez un nouveau langage de programmation, l'IDE vous dirait qu'il y a ce type et qu'il n'y en a pas d'autre. Au moins, au niveau d'int ou string. Cela peut souvent être utile.
Et qu'en est-il des tests ?
Vous allez demander : « Qu'en est-il des tests, mesdames et messieurs les programmeurs ? » Les développeurs sérieux testent tout en production, et c'est rigoureux. Voici un exemple de test unitaire pour un module Terraform provenant du site. .
Ils ont une bonne documentation. J'ai toujours aimé l'approche de Microsoft en matière de documentation et d'apprentissage. Mais il n'est pas nécessaire d'être Uncle Bob pour comprendre qu'il n'y a pas de code parfait ici. Faites attention à la validation déportée à droite.
Le problème du test unitaire, c'est que nous pouvons vérifier la pertinence du JSON en sortie. J'ai envoyé 5 paramètres, j'ai reçu une longue chaîne de JSON de 2000 lignes. Je peux analyser ce qui se passe ici, valider le résultat du test…
Il est difficile d'analyser JSON en Go. Pourtant, il faut écrire en Go, car Terraform en Go est une bonne pratique : tester dans le même langage que celui que vous utilisez. L'organisation du code est très faible. Néanmoins, c'est la meilleure bibliothèque pour les tests.
Microsoft lui-même écrit ses modules en les testant de cette manière. Bien sûr, c'est open source. Tout ce dont je parle, vous pouvez venir et le réparer. Je peux m'asseoir et tout corriger en une semaine, rendre open source les plugins de VS Code, Terraform, créer un plugin pour Rider. Peut-être écrire quelques analyseurs, ajouter des linters, contribuer à une bibliothèque de tests. Je peux faire tout cela. Mais ce n'est pas mon travail.
Meilleures pratiques de l'Infrastructure as Code.
Continuons. S'il n'y a pas de tests dans l'IaC, si l'IDE et les outils sont insuffisants, alors il doit y avoir au moins de bonnes pratiques. Je suis simplement allé sur Google Analytics et j'ai comparé deux requêtes de recherche : Terraform best practices et c# best practices.
Que voyons-nous ? Des statistiques implacables qui ne jouent pas en notre faveur. En termes de quantité de matériel, c'est la même chose. Dans le développement C#, nous sommes submergés de matériaux, nous avons des pratiques suprêmes, des livres écrits par des experts, et aussi des livres critiques d'autres experts sur ces livres. Une mer de documentation officielle, d'articles, de cours d'apprentissage, et maintenant même le développement open source.
Concernant la requête sur l'IaC : ici, vous essayez de rassembler des informations à partir de morceaux de présentations de Highload ou de HashiConf, de la documentation officielle, et de nombreux issues sur GitHub. Comment déployer ces modules, que faire avec ? Cela semble être un véritable problème… Il y a une communauté, mesdames et messieurs, où pour chaque question, vous recevrez dix commentaires sur GitHub. Mais ce n'est pas sûr.
Malheureusement, les experts ne commencent à apparaître que maintenant. Ils sont encore trop peu nombreux. Et la communauté en est encore à ses débuts.
Où tout cela nous mène-t-il et que faire ?
On peut tout laisser tomber et revenir à C#, dans le monde de Rider. Mais non. Pourquoi se lancer dans cette aventure si ce n'est pas pour trouver une solution ? Voici mes conclusions subjectives. Vous pouvez débattre avec moi dans les commentaires, ça sera intéressant.
Personnellement, je parie sur plusieurs éléments :
- Le développement dans ce domaine avance très rapidement. Voici un graphique des requêtes liées à DevOps.
Cela peut sembler être un sujet à la mode, mais le simple fait que le domaine croisse apporte un certain espoir.Si quelque chose croît aussi rapidement, des personnes intelligentes finiront par dire comment faire, et comment ne pas faire. L'augmentation de la popularité signifie que certains auront peut-être enfin le temps d'écrire un plugin pour jsonnet pour vscode, permettant d'accéder à l'implémentation d'une fonction sans avoir à la chercher avec ctrl+shift+f. Lorsque tout évolue, plus de ressources apparaissent. La sortie du livre de Google sur SRE en est un excellent exemple.
- Il existe des méthodes et des pratiques en développement traditionnel que nous pouvons appliquer avec succès ici. Oui, il y a des nuances avec les tests et un environnement hétérogène, des outils insuffisants, mais un grand nombre de pratiques a été accumulé qui peuvent être utiles.
Un exemple banal : le travail collaboratif par pair programming. Cela aide énormément à comprendre. Lorsque vous avez un voisin qui essaie également de comprendre, ensemble vous saisissez mieux.
Comprendre comment s'effectue le refactoring aide même dans cette situation. Cela signifie que vous pouvez changer des éléments progressivement, d'abord le nom, puis la mise en page, et peut-être isoler une partie, ah, et ici il manque des commentaires.
Conclusion
Bien que mes réflexions puissent sembler pessimistes, j'ai un regard optimiste vers l'avenir et j'espère sincèrement que nous réussirons (vous et nous).
La seconde partie de l'article est en préparation. Je parlerai de la manière dont nous avons essayé d'appliquer des pratiques de développement agile pour améliorer notre processus d'apprentissage et notre travail avec l'infrastructure.
Source : habr.com
