Notre entreprise est en train d'intégrer une équipe SRE. Je suis entré dans toute cette histoire du côté du développement. Au cours du processus, j'ai trouvé 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, de la manière dont cela se produit et de la manière dont chacun peut continuer à vivre avec.
Suite d'une série d'articles rédigés à partir de discours prononcés lors de notre événement interne :
2. Infrastructure en tant que code. (Tu es là)
3. Génération de contrats Typescript à l'aide 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, mettant en œuvre les idées . Ils ont recruté des programmeurs parmi leurs propres développeurs et les ont envoyés se former pendant plusieurs mois.
L'équipe avait les tâches de formation suivantes :
- Décrivez notre infrastructure, qui est majoritairement dans Microsoft Azure sous forme de code (Terraform et tout autour).
- Apprenez aux développeurs à travailler avec l'infrastructure.
- Préparez les développeurs au devoir.
Nous introduisons le concept d'Infrastructure as code
Dans le modèle habituel du monde (administration classique), les connaissances sur les infrastructures se situent à deux endroits :
- Ou sous forme de connaissances chez les chefs d’experts.
- Ou bien ces informations se trouvent sur certaines machines à écrire, dont certaines sont connues des experts. Mais ce n’est pas un fait qu’un étranger (au cas où toute notre équipe décède subitement) sera capable de comprendre ce qui fonctionne et comment cela fonctionne. Il peut y avoir beaucoup d'informations sur une machine : accessoires, cronjobs, intimidés (voir. ) disque et juste une liste interminable de ce qui peut arriver. Il est difficile de comprendre ce qui se passe réellement.
Dans les deux cas, nous nous retrouvons pris au piège de la dépendance :
- ou d'une personne mortelle, sujette à la maladie, aux chutes amoureuses, aux sautes d'humeur et aux licenciements tout simplement banals ;
- ou d'une machine physiquement fonctionnelle, qui tombe également, est volée et présente des surprises et des inconvénients.
Il va sans dire qu’idéalement, tout devrait être traduit en code lisible, maintenable et bien écrit.
Ainsi, l'infrastructure en tant que code (Incfastructure as Code - IaC) est une description de l'ensemble de l'infrastructure existante sous forme de code, ainsi que des outils associés pour travailler avec elle et mettre en œuvre une infrastructure réelle à partir de celle-ci.
Pourquoi tout traduire en code ?Les gens ne sont pas des machines. Ils ne se souviennent pas de tout. La réaction d’une personne et d’une machine est différente. Tout ce qui est automatisé est potentiellement plus rapide que tout ce qui est fait par un humain. Le plus important est d’avoir une source unique de vérité.
D’où viennent les nouveaux ingénieurs SRE ?Nous avons donc décidé d'embaucher de nouveaux ingénieurs SRE, mais où les trouver ? Réservez avec les bonnes réponses () nous dit : de la part des développeurs. Après tout, ils fonctionnent avec le code et vous atteignez l'état idéal.
Nous les avons longtemps recherchés sur le marché du personnel en dehors de notre entreprise. Mais force est de constater que nous n’avons trouvé personne qui corresponde à nos demandes. J'ai dû chercher parmi les miens.
Problèmes Infrastructure en tant que code
Examinons maintenant des exemples de la manière dont l'infrastructure peut être codée en dur dans le code. Le code est bien écrit, de haute qualité, avec des commentaires et des indentations.
Exemple de code de Terraforma.
Exemple de code d'Ansible.
Messieurs, si c'était si simple ! Nous sommes dans le monde réel et il est toujours prêt à vous surprendre, à vous présenter des surprises et des problèmes. Ici non plus, je ne peux pas m'en passer.
1. Le premier problème est que dans la plupart des cas, IaC est une sorte de DSL.
Et le 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 proposé leur propre DSL (HCL est utilisé dans terraform).
Le problème est qu’il peut facilement ne pas contenir des éléments aussi familiers que :
- variables ;
- conditions;
- quelque part il n'y a pas de commentaires, par exemple, en Json, par défaut ils ne sont pas fournis ;
- les fonctions;
- et je ne parle même pas de choses aussi importantes que les classes, l’héritage et tout ça.
2. Le deuxième problème d'un tel code est qu'il s'agit le plus souvent d'un environnement hétérogène. Habituellement, vous vous asseyez et travaillez avec C#, c'est-à-dire avec un langage, une pile, un écosystème. Et vous disposez ici d’une grande variété de technologies.
C'est une situation très réelle lorsque bash avec python lance un processus dans lequel Json est inséré. Vous l'analysez, puis un autre générateur produit 30 autres fichiers. Pour tout cela, les variables d'entrée sont reçues d'Azure Key Vault, qui sont rassemblées par un plugin pour drone.io écrit en Go, et ces variables passent par yaml, qui a été généré à la suite de la génération à partir du moteur de modèle jsonnet. Il est assez difficile d'avoir du code strictement bien décrit dans un environnement aussi diversifié.
Le développement traditionnel dans le cadre d'une tâche s'accompagne d'un langage. Ici, nous travaillons avec un grand nombre de langues.
3. Le troisième problème est le réglage. Nous sommes habitués à des éditeurs sympas (Ms Visual Studio, Jetbrains Rider) qui font tout pour nous. Et même si nous sommes stupides, ils diront que nous avons tort. Cela semble normal et naturel.
Mais quelque part à proximité se trouve VSCode, dans lequel se trouvent des plugins qui sont installés, pris en charge ou non. De nouvelles versions sont sorties et n'étaient pas 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 changement de nom d'une variable est une relecture dans un projet d'une douzaine de fichiers. Vous aurez de la chance s'il place ce dont vous avez besoin. Bien sûr, il y a du rétroéclairage ici et là, il y a l'auto-complétion, quelque part il y a le formatage (même si cela n'a pas fonctionné pour moi en terraform sous Windows).
Au moment de la rédaction ne sont pas encore sortis pour prendre en charge la version 0.12, bien qu'elle soit publiée depuis 3 mois.
Il est temps d'oublier...
- Débogage.
- Outil de refactorisation.
- Achèvement automatique.
- Détection des erreurs lors de la compilation.
C'est drôle, mais cela augmente aussi le temps de développement et augmente le nombre d'erreurs qui surviennent inévitablement.
Le pire, c'est que nous sommes obligés de réfléchir non pas à la façon de concevoir, d'organiser les fichiers dans des dossiers, de les décomposer, de rendre le code maintenable, lisible, etc., mais à la façon dont je peux écrire cette commande correctement, car je l'ai écrite de manière incorrecte. .
En tant que débutant, vous essayez d'apprendre les terraforms, et l'EDI ne vous aide pas du tout. Lorsqu'il y a de la documentation, entrez et regardez. Mais si vous entriez dans un nouveau langage de programmation, l’EDI vous dirait qu’il existe un tel type, mais cela n’existe pas. Au moins au niveau int ou chaîne. C'est souvent utile.
Et les tests ?
Vous demandez : « Et les tests, messieurs les programmeurs ? Les gars sérieux testent tout en production, et c'est dur. Voici un exemple de test unitaire pour un module Terraform du site Web .
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 oncle Bob pour comprendre qu'il ne s'agit pas d'un code parfait. Notez la validation à droite.
Le problème avec un test unitaire est que vous et moi pouvons vérifier l'exactitude de la sortie Json. J'ai ajouté 5 paramètres et j'ai reçu un chausson Json avec 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 terraform en Go est une bonne pratique pour tester dans la langue dans laquelle vous écrivez. L’organisation du code lui-même est très faible. En même temps, c'est la meilleure bibliothèque pour les tests.
Microsoft écrit lui-même ses modules et les teste ainsi. 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, des plugins de code VS open source, des terraforms, créer un plugin pour le pilote. Peut-être écrire quelques analyseurs, ajouter des linters, contribuer à une bibliothèque pour les tests. Je peux tout faire. Mais ce n'est pas ce que je devrais faire.
Meilleures pratiques Infrastructure as code
Allons-nous en. S'il n'y a pas de tests dans IaC, si l'IDE et les réglages sont mauvais, alors il devrait au moins y avoir les meilleures pratiques. Je viens d'aller sur Google Analytics et j'ai comparé deux requêtes de recherche : les meilleures pratiques Terraform et les meilleures pratiques C#.
Que voit-on ? Les statistiques impitoyables ne sont pas en notre faveur. La quantité de matière est la même. Dans le développement C#, nous sommes tout simplement inondés de matériaux, nous avons les meilleures pratiques, il existe des livres écrits par des experts, ainsi que des livres écrits sur des livres par d'autres experts qui critiquent ces livres. Une mer de documentation officielle, d'articles, de formations et désormais aussi de développement open source.
Quant à la requête IaC : ici, vous essayez de collecter des informations petit à petit à partir de rapports highload ou HashiConf, de la documentation officielle et de nombreux problèmes sur Github. Comment diffuser ces modules en général, qu'en faire ? Il semble que ce soit un vrai problème... Il existe une communauté, messieurs, où pour toute question vous recevrez 10 commentaires sur Github. Mais ce n’est pas exactement le cas.
Malheureusement, à l’heure actuelle, les experts commencent tout juste à émerger. Il y en a trop peu pour l’instant. Et la communauté elle-même traîne à un niveau rudimentaire.
Où va tout cela et que faire
Vous pouvez tout laisser tomber et revenir en C#, dans le monde du rider. Mais non. Pourquoi voudriez-vous faire cela si vous ne trouvez pas de solution. Ci-dessous, je présente mes conclusions subjectives. Vous pouvez discuter avec moi dans les commentaires, ce sera intéressant.
Personnellement, je parie sur plusieurs choses :
- Le développement dans ce domaine se produit très rapidement. Voici un planning des demandes pour DevOps.
Le sujet est peut-être à la mode, mais le fait même que la sphère se développe donne un peu d’espoir.Si quelque chose se développe si rapidement, des personnes intelligentes apparaîtront certainement et vous diront quoi faire et quoi ne pas faire. L'augmentation de la popularité conduit au fait que peut-être que quelqu'un aura le temps d'ajouter enfin un plugin à jsonnet pour vscode, ce qui vous permettra de passer à l'implémentation de la fonction, plutôt que de la rechercher via ctrl+shift+f. Au fur et à mesure que les choses évoluent, de plus en plus de matériaux apparaissent. La sortie d'un livre de Google sur le SRE en est un excellent exemple.
- 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, des outils insuffisants, mais un grand nombre de pratiques ont été accumulées qui peuvent être utiles et utiles.
Un exemple trivial : la collaboration via la programmation en binôme. Cela aide beaucoup à comprendre. Lorsque vous avez un voisin à proximité qui essaie également de comprendre quelque chose, ensemble vous comprendrez mieux.
Comprendre comment le refactoring est effectué aide à le réaliser même dans une telle situation. Autrement dit, vous ne pouvez pas tout changer en même temps, mais changer le nom, puis changer l'emplacement, puis vous pouvez mettre en évidence une partie, oh, mais il n'y a pas assez de commentaires ici.
Conclusion
Même si mon raisonnement peut paraître pessimiste, je regarde l'avenir avec espoir et j'espère sincèrement que tout s'arrangera pour nous (et pour vous).
La deuxième partie de l'article est ensuite en préparation. Dans ce document, j'expliquerai comment nous avons essayé d'utiliser des pratiques de développement agiles pour améliorer notre processus d'apprentissage et travailler avec l'infrastructure.
Source: habr.com