Il semblerait que les développeurs Terraform proposent de bonnes pratiques assez pratiques pour travailler avec l'infrastructure AWS. Il y a seulement une nuance. Au fil du temps, le nombre d'environnements augmente, des fonctionnalités apparaissent dans chacun. Apparaît presque une copie de la pile d'applications dans la région voisine. Et le code Terraform doit être soigneusement copié et modifié selon les nouvelles exigences ou pour créer un flocon de neige.
Mon rapport porte sur les modèles dans Terraform pour lutter contre le chaos et la routine manuelle sur des projets importants et longs.
Vidéo:
J'ai 40 ans, je suis dans l'informatique depuis 20 ans. Je travaille chez Ixtens depuis 12 ans. Nous sommes engagés dans un développement axé sur le commerce électronique. Et je pratique les pratiques DevOps depuis 5 ans.
Mon histoire portera sur l'expérience d'un projet dans une entreprise dont je ne dirai pas le nom, cachée derrière un accord de confidentialité.
Les chiffres sur la diapositive sont donnés afin de comprendre la portée du projet. Et tout ce que je vais dire ensuite est lié à Amazon.
J'ai rejoint ce projet il y a 4 ans. Et la refactorisation de l'infrastructure battait son plein, car le projet avait pris de l'ampleur. Et les modèles qui ont été utilisés ne conviennent plus. Et compte tenu de la croissance prévue du projet, il était nécessaire de proposer quelque chose de nouveau.
Merci à Matvey, qui nous a raconté hier ce qui s'est passé chez Dodo Pizza. C'est ce qui nous est arrivé il y a 4 ans.
Les développeurs sont venus et ont commencé à créer du code d’infrastructure.
La raison la plus évidente pour laquelle cela était nécessaire était le délai de mise sur le marché. Il fallait s’assurer que l’équipe DevOps ne soit pas un goulot d’étranglement lors du déploiement. Et entre autres, Terraform et Puppet ont été utilisés dès le tout premier niveau.
Terraform est un projet open source de HashiCorp. Et pour ceux qui ne savent pas du tout ce que c'est, les prochaines slides.
L'infrastructure en tant que code signifie que nous pouvons décrire notre infrastructure et demander à certains robots de s'assurer que nous obtenons les ressources que nous avons décrites.
Par exemple, nous avons besoin d'une machine virtuelle. Nous allons décrire, ajouter quelques paramètres requis.
Après cela, nous configurerons l'accès à Amazon dans la console. Et demandez le plan Terraform. Le plan Terraform dira : "Ok, pour votre ressource, nous pouvons faire ces choses." Et au moins une ressource sera ajoutée. Et aucun changement n’est attendu.
Une fois que tout vous convient, vous pouvez demander à Terraform de postuler et Terraform créera une instance pour vous et vous obtiendrez une machine virtuelle dans votre cloud.
De plus, notre projet se développe. Nous y ajoutons quelques modifications. Nous demandons plus d'instances, nous ajoutons 53 entrées.
Et nous répétons. S'il vous plaît planifier. Nous voyons quels changements sont prévus. Appliquer. Et ainsi notre infrastructure se développe.
Terraform utilise des éléments tels que des fichiers d'état. Autrement dit, il enregistre toutes les modifications apportées à Amazon dans un fichier, où pour chaque ressource que vous avez décrite, il existe des ressources correspondantes créées dans Amazon. Ainsi, lors de la modification de la description d'une ressource, Terraform sait exactement ce qui doit être modifié dans Amazon.
Ces fichiers d'état n'étaient à l'origine que des fichiers. Et nous les avons stockés dans Git, ce qui était extrêmement gênant. Quelqu'un oubliait constamment d'apporter des modifications et il y avait de nombreux conflits.
Il est désormais possible d'utiliser le backend, c'est-à-dire que Terraform indique dans quel compartiment et par quelle clé le fichier d'état doit être enregistré. Et Terraform lui-même se chargera d'obtenir ce fichier d'état, de faire toute la magie et de remettre le résultat final.
Notre infrastructure se développe. Voici notre code. Et maintenant, nous ne voulons pas simplement créer une machine virtuelle, nous voulons disposer d'un environnement de test.
Terraform vous permet de créer un module, c'est-à-dire de décrire la même chose dans un dossier.
Et, par exemple, lors des tests, appelez ce module et obtenez la même chose que si nous faisions Terraform apply dans le module lui-même. Voici le code pour tester.
Pour la production, nous pouvons y envoyer certaines modifications, car lors des tests, nous n'avons pas besoin de grandes instances, en production, de grandes instances seront utiles.
Et puis je reviendrai sur le projet. C'était une tâche difficile, l'infrastructure était prévue très vaste. Et il fallait en quelque sorte placer tout le code de manière à ce qu'il soit pratique pour tout le monde : pour ceux qui effectuent la maintenance sur ce code, et pour ceux qui apportent des modifications. Et il était prévu que n'importe quel développeur puisse aller réparer l'infrastructure selon les besoins pour sa partie de la plateforme.
Il s'agit d'une arborescence de répertoires recommandée par HashiCorp si vous avez un grand projet et qu'il est logique de diviser l'ensemble de l'infrastructure en quelques petits morceaux et de décrire chaque élément dans un dossier séparé.
Disposant d'une vaste bibliothèque de ressources, vous pouvez faire appel à peu près à la même chose en test et en production.
Dans notre cas, cela n'était pas tout à fait approprié, car la pile de tests pour les développeurs ou pour les tests devait être obtenue d'une manière ou d'une autre plus simple. Et je ne voulais pas parcourir les dossiers et postuler dans le bon ordre, et craindre que la base augmente, puis que l'instance qui utilise cette base augmente. Par conséquent, tous les tests ont été lancés à partir d’un seul dossier. Les mêmes modules y ont été appelés, mais tout s'est déroulé en une seule fois.
Terraform prend en charge toutes les dépendances. Et il crée toujours des ressources dans cet ordre afin que vous puissiez obtenir une adresse IP, par exemple, à partir d'une instance fraîchement créée, et obtenir cette adresse IP dans l'entrée route53.
De plus, la plateforme est très grande. Et exécuter une pile de tests, même pendant une heure, même pendant 8 heures, est une entreprise assez coûteuse.
Et nous avons automatisé cette activité. Et le travail Jenkins a permis à la pile de s'exécuter. Il était nécessaire d'y lancer une pull request avec les modifications que le développeur souhaite tester, de spécifier toutes les options, composants et tailles nécessaires. S'il souhaite tester les performances, il peut alors prendre plus d'instances. S'il lui suffit de vérifier qu'un formulaire s'ouvre, il pourrait commencer au salaire minimum. Et indiquez également si un cluster est nécessaire ou non, etc.
Et puis Jenkins a poussé un script shell qui a légèrement modifié le code dans le dossier Terraform. Suppression des fichiers inutiles, ajout des fichiers nécessaires. Et puis, avec une seule exécution de Terraform Apply, la pile a augmenté.
Et puis il y a eu d’autres étapes dans lesquelles je ne veux pas aborder.
Étant donné que pour les tests, nous avions besoin d'un peu plus d'options qu'en production, nous avons dû faire des copies des modules afin que dans ces copies nous puissions ajouter les fonctionnalités qui ne sont nécessaires que pour les tests.
Et il se trouve que lors des tests, il semble que vous souhaitiez tester les modifications qui finiront par être mises en production. Mais en fait, une chose a été testée et une autre a été utilisée en production. Et il y a eu une petite rupture dans le modèle selon lequel, en production, tous les changements étaient appliqués par l'équipe d'exploitation. Et parfois, il s'est avéré que ces modifications qui étaient censées passer des tests à la production sont restées dans une autre version.
De plus, il y avait un tel problème qu'un nouveau service a été ajouté, légèrement différent de celui existant. Et au lieu de modifier un module existant, il fallait en faire une copie et y ajouter les modifications nécessaires.
En fait, Terraform n'est pas un vrai langage. Ceci est une déclaration. Si nous devons déclarer quelque chose, nous le déclarons. Et tout fonctionne.
À un moment donné, en discutant d'une de mes pull request, un de mes collègues a dit qu'il n'était pas nécessaire de produire des flocons de neige. Je me demandais ce qu'il voulait dire. Il existe un tel fait scientifique que dans le monde, il n'y a pas deux flocons de neige identiques, ils sont tous légèrement, mais différents. Et dès que j’ai entendu cela, j’ai immédiatement ressenti tout le poids du code Terraform. Car lorsqu’il fallait passer de version en version, Terraform nécessitait un changement de chaîne de rupture, c’est-à-dire que le code n’était plus compatible avec la version suivante. Et j'ai dû faire une pull request, qui couvrait près de la moitié des fichiers de l'infrastructure, afin d'amener l'infrastructure à la prochaine version de Terraform.
Et après l'apparition d'un tel flocon de neige, tout le code Terraform que nous avions transformé en un gros, gros tas de neige.
Pour un développeur externe qui est hors service, cela n'a pas beaucoup d'importance, car il a fait une pull request, sa ressource a démarré. Et voilà, ce n'est pas son affaire. Et l’équipe DevOps qui s’assure que tout va bien doit apporter tous ces changements. Et le coût de ces changements augmentait considérablement à chaque flocon de neige supplémentaire.
Il y a une histoire sur la façon dont un étudiant lors d'un séminaire dessine deux cercles parfaits à la craie sur un tableau noir. Et le professeur est surpris de voir comment il a réussi à dessiner si facilement sans boussole. L’étudiant répond : « C’est très simple, j’ai fait un hachoir à viande pendant deux ans dans l’armée. »
Et sur les quatre années que j'ai passées sur ce projet, j'ai travaillé sur Terraform pendant environ deux ans. Et bien sûr, j'ai quelques astuces, quelques conseils pour simplifier le code Terraform, l'utiliser comme un langage de programmation et réduire la charge des développeurs qui doivent maintenir ce code à jour.
La première chose par laquelle je voudrais commencer, ce sont les liens symboliques. Terraform contient beaucoup de code répétitif. Par exemple, faire appel à un fournisseur à presque chaque moment où nous créons une infrastructure est la même chose. Et il est logique de le confier à un papa séparé. Et partout où le fournisseur est tenu de créer des liens symboliques vers ce fichier.
Par exemple, vous utilisez assumer un rôle en production, ce qui vous permet d'obtenir des droits d'accès à un compte Amazon externe. Et en modifiant un fichier, tous les fichiers restants qui se trouvent dans l'arborescence des ressources auront les droits requis pour que Terraform sache à quel segment Amazon accéder.
Où les liens symboliques ne fonctionnent pas ? Comme je l'ai dit, Terraform possède des fichiers d'état. Et ils sont vraiment très cool. Mais le fait est que Terraform initialise le backend dès le premier. Et il ne peut utiliser aucune variable dans ces paramètres, elles doivent toujours être écrites sous forme de texte.
Et par conséquent, lorsque quelqu'un crée une nouvelle ressource, il copie une partie du code d'autres dossiers. Et il peut se tromper avec la clé ou avec le seau. Par exemple, il fabrique un bac à sable à partir d'un bac à sable, puis le met en production. Il se peut donc que le seau en production soit utilisé à partir du bac à sable. Bien sûr, ils le trouveront rapidement. Il sera possible de résoudre ce problème d'une manière ou d'une autre, mais c'est néanmoins une perte de temps et, dans une certaine mesure, de ressources.
Que pouvons-nous faire ensuite ? Avant de travailler avec Terraform, vous devez l'initialiser. Au moment de l'initialisation, Terraform télécharge tous les plugins. À un moment donné, ils sont passés d’une architecture monolithique à une architecture davantage de microservices. Et vous devez toujours faire Terraform init pour qu'il récupère tous les modules, tous les plugins.
Et vous pouvez utiliser un script shell qui, dans un premier temps, peut récupérer toutes les variables. Le script Shell est illimité. Et deuxièmement, la manière. Si nous utilisons toujours le chemin qui se trouve dans le référentiel comme clé du fichier d'état, l'erreur sera donc exclue ici.
Où obtenir des données ? Fichier JSON. Terraform vous permet d'écrire une infrastructure non seulement en hcl (HashiCorp Configuration Language), mais également en JSON.
JSON est facile à lire à partir d'un script shell. Par conséquent, vous pouvez placer un fichier de configuration avec un compartiment à un endroit. Et utilisez ce bucket à la fois dans le code Terraform et dans le script shell pour l'initialisation.
Pourquoi est-il important d'avoir un bucket Terraform ? Parce qu'il existe des fichiers d'état distants. Autrement dit, lorsque je lève une ressource, afin de dire à Amazon : « Veuillez augmenter l'instance », je dois spécifier de nombreux paramètres requis.
Et ces identifiants sont stockés dans un autre dossier. Et je peux le prendre et dire : « Terraform, s'il vous plaît, accédez au fichier d'état de cette même ressource et procurez-moi ces identifiants. » Il y a donc une sorte d’unification entre différentes régions ou environnements.
Il n'est pas toujours possible d'utiliser un fichier d'état distant. Par exemple, vous avez créé manuellement un VPC. Et le code Terraform qui crée le VPC crée un VPC tellement différent que cela prend très longtemps et que vous devez vous ajuster l'un à l'autre, vous pouvez donc utiliser l'astuce suivante.
C'est-à-dire créer un module qui, pour ainsi dire, crée un VPC et vous donne des identifiants, mais en fait il n'y a qu'un fichier avec des valeurs codées en dur qui peut être utilisé pour créer la même instance.
Il n'est pas toujours nécessaire de sauvegarder le fichier d'état dans le cloud. Par exemple, lorsque les modules sont testés, vous pouvez utiliser l'initialisation backend, lorsque le fichier sera enregistré uniquement sur le disque au moment du test.
Parlons maintenant un peu des tests. Que peut-on tester dans Terraform ? Beaucoup de choses sont probablement possibles, mais je vais parler de ces 4 choses.
HashiCorp comprend comment formater le code Terraform. Et Terraform fmt vous permet de formater le code que vous modifiez selon cette conviction. En conséquence, les tests doivent nécessairement vérifier si le formatage correspond à ce que HashiCorp a légué, afin de ne pas avoir à modifier l'emplacement des parenthèses, etc.
Le suivant est Terraform validate. Il fait un peu plus qu'une vérification de syntaxe - hélas, toutes les parenthèses sont-elles appariées. Qu’est-ce qui est important ici ? Nous avons une infrastructure très mince. Il contient de nombreux dossiers différents. Et dans chacun, vous devez exécuter Terraform validate.
En conséquence, pour accélérer les tests, nous exécutons plusieurs processus en parallèle en utilisant le mode parallèle.
Le parallèle est une chose très cool, utilisez-le.
Mais chaque fois que Terraform est initialisé, il va à HashiCorp et demande : « Quels sont les derniers plugins ? Et le plugin que j'ai dans le cache, est-ce celui-là ou pas ? Et cela ralentissait à chaque pas.
Si Terraform vous indique où se trouvent les plugins, Terraform dira : « OK, c'est probablement la chose la plus récente qui soit. Je n'irai nulle part, je vais commencer à valider votre code Terraform tout de suite."
Afin de remplir le dossier avec les plugins nécessaires, nous disposons d'un code Terraform très simple qu'il suffit d'initialiser. Ici, bien sûr, vous devez spécifier tous les fournisseurs qui participent d'une manière ou d'une autre à votre code, sinon Terraform dira : "Je ne connais aucun fournisseur, car il n'est pas dans le cache."
Le prochain est le plan Terraform. Comme je l'ai dit, le développement est cyclique. Nous créons du code avec des modifications. Et puis il faut savoir quels changements sont prévus pour l'infrastructure.
Et lorsque l'infrastructure est très, très grande, vous pouvez modifier un module, réparer un environnement de test ou une région spécifique et casser un voisin. Par conséquent, un plan Terraform doit être élaboré pour l'ensemble de l'infrastructure et montrer les changements prévus.
Vous pouvez le faire de manière intelligente. Par exemple, nous avons écrit un script Python qui résout les dépendances. Et en fonction de ce qui a été modifié : un module Terraform ou simplement un composant spécifique, il fait des plans pour tous les dossiers dépendants.
Le plan Terraform doit être réalisé sur demande. C'est du moins ce que nous faisons.
Bien sûr, les tests sont bons à faire pour chaque changement, pour chaque commit, mais les plans coûtent assez cher. Et nous disons dans la pull request : "S'il vous plaît, donnez-moi les plans." Le robot démarre. Et envoie aux commentaires ou pour joindre tous les plans attendus de vos modifications.
Le plan est une chose plutôt coûteuse. Cela prend du temps car Terraform se rend sur Amazon et demande : « Cette instance existe-t-elle toujours ? Cette mise à l'échelle automatique a-t-elle exactement les mêmes paramètres ? Et pour l'accélérer, vous pouvez utiliser un paramètre tel que rafraîchir=false. Cela signifie que Terraform dégonflera l'état S3. Et je croirai que l’État correspondra exactement à ce qui existe en Amazonie.
Un tel plan Terraform est beaucoup plus rapide, mais l'état doit correspondre à votre infrastructure, c'est-à-dire qu'à un moment donné, l'actualisation de Terraform doit commencer. C'est exactement ce que fait l'actualisation Terraform, afin que l'état corresponde à ce qui se trouve dans l'infrastructure réelle.
Et je dois dire sur la sécurité. C'est par là que cela aurait dû commencer. Lorsque vous exécutez Terraform et que Terraform fonctionne avec votre infrastructure, il existe une vulnérabilité. Autrement dit, vous exécutez essentiellement du code. Et si la pull request contient une sorte de code malveillant, elle peut alors être exécutée sur une infrastructure qui a trop d'accès. Par conséquent, faites attention à l'endroit où vous lancez le plan Terraform.
La prochaine chose dont je voudrais parler est le test des données utilisateur.
Que sont les données utilisateur ? Sur Amazon, lorsque nous créons une instance, nous pouvons envoyer une sorte de lettre de l'instance - des métadonnées. Lorsqu'une instance est démarrée, cloud init est généralement toujours présent sur ces instances. Cloud init lit cette lettre et dit : "OK, aujourd'hui, je suis un équilibreur de charge." Et conformément à ces préceptes, il accomplit certaines actions.
Mais, malheureusement, lorsque nous planifions Terraform et que Terraform s'applique, les données utilisateur ressemblent à cette bouillie de chiffres. Autrement dit, il vous envoie simplement un hachage. Et tout ce que vous pouvez voir dans le plan, c'est s'il y aura des changements ou si le hachage restera le même.
Et si vous n'y prêtez pas attention, certains fichiers texte battus peuvent aller vers Amazon, vers la véritable infrastructure.
Alternativement, vous pouvez spécifier non pas l'intégralité de l'infrastructure lors de l'exécution, mais uniquement le modèle. Et dans le code, dites : "Veuillez afficher ce modèle pour moi." Et par conséquent, vous pouvez obtenir une impression de ce à quoi ressembleront vos données sur Amazon.
Une autre option consiste à utiliser un module pour générer des données utilisateur. Vous appliquerez ce module. Récupérez le fichier sur le disque. Comparez-le avec la référence. Et ainsi, si un juin décide de corriger un peu les données utilisateur, alors vos tests diront : "OK, il y a quelques changements ici et là - c'est normal."
La prochaine chose dont je voudrais parler est l'application Automate Terraform.
Bien sûr, c'est déjà assez effrayant d'appliquer Terraform en mode automatique, car qui sait quels changements y sont survenus et à quel point ils peuvent être préjudiciables à une infrastructure vivante.
Pour un environnement de test, tout va bien. Autrement dit, un travail qui crée un environnement de test est ce dont tous les développeurs ont besoin. Et une expression telle que « tout a fonctionné pour moi » n'est pas un mème amusant, mais la preuve qu'une personne s'est trompée, a levé une pile, a lancé quelques tests sur cette pile. Et il s'est assuré que tout allait bien là-bas et a dit : "OK, le code que je publie a été testé."
Dans les environnements de production, sandbox et autres environnements plus critiques pour l'entreprise, il est sûr d'utiliser partiellement certaines ressources, car cela ne provoque la mort de personne. Ce sont : les groupes de mise à l'échelle automatique, les groupes de sécurité, les rôles, route53 et là, la liste peut être assez longue. Mais gardez un œil sur ce qui se passe, lisez les rapports des applications automatisées.
Lorsqu'il est dangereux ou effrayant d'utiliser, par exemple, s'il s'agit de ressources persistantes, provenant d'une base de données, obtenez des rapports indiquant qu'il y a des modifications non appliquées dans un élément d'infrastructure. Et l'ingénieur est déjà supervisé en train d'exécuter les tâches à appliquer ou de les réaliser depuis sa console.
Amazon propose une protection contre la résiliation. Et cela peut vous protéger dans certains cas contre des modifications qui ne sont pas nécessaires pour vous. Terraform est donc allé sur Amazon et a dit "Je dois tuer cette instance pour en créer une autre". Et Amazon dit : « Désolé, pas aujourd'hui. Nous avons la protection Terminate.
Et la cerise sur le gâteau, c’est l’optimisation du code. Lorsque l'on travaille avec du code Terraform, nous devons transmettre un très grand nombre de paramètres au module. Ce sont les paramètres nécessaires pour créer une sorte de ressource. Et le code se transforme en de grandes listes de paramètres qui doivent être transmis de module en module, de module en module, surtout si les modules sont imbriqués.
Et c'est très difficile à lire. Il est très difficile de revoir cela. Et très souvent, il s’avère que certains paramètres sont en cours de révision et qu’ils ne sont pas tout à fait ceux qui sont nécessaires. Et cela coûte du temps et de l’argent pour le réparer plus tard.
Par conséquent, je vous suggère d'utiliser un paramètre complexe qui inclut un certain arbre de valeurs. Autrement dit, vous avez besoin d'une sorte de dossier contenant toutes les valeurs que vous aimeriez avoir sur un certain environnement.
Et en appelant ce module, vous pouvez obtenir une arborescence générée dans un module commun, c'est-à-dire dans un module commun qui fonctionne de la même manière pour toute l'infrastructure.
Dans ce module, vous pouvez effectuer des calculs en utilisant une fonctionnalité aussi nouvelle de Terraform que les locaux. Et puis, dans une sortie, émettez une sorte de paramètre complexe, qui peut inclure des hachages, des tableaux, etc.
C'est là que se terminent toutes les meilleures trouvailles que j'ai terminées. Et j'aimerais raconter une histoire sur Columbus. Lorsqu'il cherchait de l'argent pour son expédition de découverte de l'Inde (comme il le pensait alors), personne ne le croyait et croyait que c'était impossible. Puis il dit : « Assurez-vous que l'œuf ne tombe pas. Tous les banquiers, des gens très riches et probablement intelligents, ont essayé de mettre l’œuf d’une manière ou d’une autre, et il tombait tout le temps. Puis Colomb prit l'œuf et le pressa un peu. La coquille s'est froissée et l'œuf est resté immobile. Ils ont dit : « Oh, c'est trop facile ! » Et Colomb répondit : « Oui, c'est trop simple. Et lorsque j’ouvrirai l’Inde, tout le monde empruntera cette route commerciale.
Et ce que je viens de vous dire est probablement des choses assez simples et triviales. Et quand on les connaît et qu’on commence à les utiliser, c’est dans l’ordre des choses. Alors utilisez-le. Et si ce sont des choses tout à fait normales pour vous, alors au moins vous savez comment mettre un œuf pour qu'il ne tombe pas.
Pour résumer:
- Essayez d'éviter les flocons de neige. Et moins il y a de flocons de neige, moins vous aurez besoin de ressources pour apporter des modifications à l’ensemble de votre grande infrastructure.
- Changement constant. Autrement dit, lorsque des modifications ont eu lieu dans le code, vous devez adapter votre infrastructure à ces modifications dès que possible. Il ne devrait pas y avoir de situation où quelqu'un vient dans deux ou trois mois pour examiner Elasticsearch, élabore un plan Terraform, et il y a beaucoup de changements auxquels il ne s'attendait pas. Et il faut beaucoup de temps pour tout remettre en ordre.
- Tests et automatisation. Plus votre code est couvert de tests et de puces, plus vous avez confiance que vous faites tout correctement. Et la livraison automatique augmentera votre confiance plusieurs fois.
- Le code des environnements de test et de production doit être presque le même. En pratique, car après tout, la production est un peu différente et il y aura quand même quelques nuances qui dépasseront l'environnement de test. Mais néanmoins, cela peut être plus ou moins fourni.
- Et si vous avez beaucoup de code Terraform et qu'il faut beaucoup de temps pour maintenir ce code à jour, alors il n'est jamais trop tard pour le refactoriser et le remettre en forme.
- infrastructure immuable. Livraison AMI dans les délais.
- Structure pour route53 lorsque vous avez beaucoup d'entrées et que vous souhaitez qu'elles soient dans un ordre cohérent.
- Luttez contre les limites de débit des API. C'est à ce moment-là qu'Amazon dit : "Ça y est, je ne peux plus accepter de demandes, veuillez patienter." Et la moitié du bureau attend de pouvoir lancer son infrastructure.
- des instances ponctuelles. Amazon n'est pas un événement bon marché et les places vous permettent d'économiser pas mal. Et là, vous pouvez raconter tout un rapport à ce sujet.
- Rôles de sécurité et IAM.
- Recherchez des ressources perdues, lorsque vous avez des instances d'origine inconnue sur Amazone, elles mangent de l'argent. Même si les instances coûtent entre 100 et 150 $ par mois, cela représente plus de 1 000 $ par an. Trouver de telles ressources est une activité lucrative.
- Et des instances réservées.
C'est tout pour moi. Terraform est très cool, utilisez-le. Merci!
des questions
Merci pour le rapport! Vous avez un fichier d'état dans S3, mais comment résoudre le problème que plusieurs personnes peuvent prendre ce fichier d'état et essayer de le déployer ?
Premièrement, nous ne sommes pas pressés. Deuxièmement, il y a les drapeaux dans lesquels nous signalons que nous travaillons sur un morceau de code. Autrement dit, malgré le fait que l'infrastructure soit très vaste, cela ne signifie pas que quelqu'un utilise constamment quelque chose. Et quand il y avait une phase active, c'était un problème, nous gardions les fichiers d'état dans Git. C'était important, sinon quelqu'un créerait un fichier d'état, et nous devions les rassembler manuellement en tas pour que tout continue. Maintenant, ce problème n’existe plus. En général, Terraform a résolu ce problème. Et si quelque chose change constamment, vous pouvez utiliser des verrous qui empêchent ce que vous avez dit.
Utilisez-vous l'open source ou l'entreprise ?
Aucune entreprise, c’est-à-dire tout ce que vous pouvez télécharger gratuitement.
Je m'appelle Stanislav. Je voulais faire un petit ajout. Vous avez parlé de la fonctionnalité Amazon qui permet de rendre une instance impossible à tuer. C'est également dans Terraform lui-même, dans le bloc Life Second, que vous pouvez prescrire une interdiction de changement, ou une interdiction de destruction.
Était limité dans le temps. Bon point.
Je voulais également demander deux choses. Tout d’abord, vous avez parlé de tests. Avez-vous utilisé des outils de test ? J'ai entendu parler du plugin Test Kitchen. Il y a peut-être autre chose. Et j'aimerais poser des questions sur les valeurs locales. En quoi diffèrent-elles fondamentalement des variables d’entrée ? Et pourquoi ne puis-je pas paramétrer quelque chose uniquement via des valeurs locales ? J'ai essayé d'aborder ce sujet, mais je ne l'ai pas compris moi-même.
Nous pouvons parler plus en détail derrière cette salle. Les outils de test sont entièrement fabriqués par nos soins. Il n'y a rien à tester. En général, il existe des options lorsque des tests automatiques élèvent l'infrastructure quelque part, vérifient qu'elle fonctionne correctement, puis détruisent tout avec un rapport indiquant que votre infrastructure est toujours en bon état. Nous n’avons pas cela car les piles de tests s’exécutent tous les jours. Et ça suffit. Et si quelque chose commence à se briser, alors il commencera à se briser sans que nous le vérifiions ailleurs.
Concernant les valeurs locales, poursuivons la conversation en dehors du public.
Bonjour! Merci pour le rapport! Très informatif. Vous avez dit que vous disposiez d'une grande partie du même type de code pour décrire l'infrastructure. Avez-vous pensé à générer ce code ?
Excellente question, merci ! Le fait est que lorsque nous utilisons l’infrastructure en tant que code, nous supposons que nous examinons le code et comprenons quel type d’infrastructure se cache derrière ce code. Si le code est généré, nous devons alors imaginer quel code sera généré afin de comprendre quel type d'infrastructure sera présent. Ou bien nous générons le code, le validons et, en fait, nous obtenons la même chose. Par conséquent, nous avons suivi la voie que nous avions écrite et nous l’avons compris. De plus, les générateurs sont apparus un peu plus tard, lorsque nous avons commencé à fabriquer. Et il était trop tard pour changer.
Avez-vous entendu parler de jsonnet ?
Non.
Écoute, c'est vraiment un truc cool. Je vois un cas spécifique où vous pouvez l'appliquer et générer une structure de données.
Les générateurs sont bons quand on en a, comme dans la blague sur la machine à raser. Autrement dit, la première fois, le visage est différent, mais ensuite tout le monde a le même visage. Les générateurs sont très cool. Mais malheureusement, nos visages sont un peu différents. C'est un problème.
Il suffit de regarder. Merci!
Je m'appelle Maxim, je viens de la Sberbank. Vous avez dit un peu que vous aviez essayé d'amener Terraform à un analogue d'un langage de programmation. N'est-il pas plus facile d'utiliser Ansible ?
Ce sont des choses très différentes. Ansible peut créer des ressources et Puppet peut créer des ressources sur Amazon. Mais Terraform est carrément affiné.
Vous n'avez qu'Amazon ?
Ce n'est pas que nous n'avons qu'Amazon. Nous n'avons presque qu'Amazon. Mais la caractéristique clé est que Terraform se souvient. Dans Ansible, si vous dites : « Récupérez-moi 5 instances », alors il augmentera, puis vous dites : « Et maintenant j'en ai besoin de 3 ». Et Terraform dira : « Ok, je vais en tuer 2 », et Ansible dira : « Ok, en voici 3 pour vous. » Total 8.
Bonjour! Merci pour votre rapport! C'était très intéressant d'entendre parler de Terraform. Je veux juste faire un petit commentaire sur le fait que Terraform n'a toujours pas de version stable, alors soyez très prudent avec Terraform.
Belle cuillère pour le dîner. Autrement dit, si vous avez besoin d'une solution, vous reportez parfois ce qui est instable, etc., mais cela fonctionne et nous a aidé.
La question est. Vous utilisez le backend Remote, vous utilisez S 3. Pourquoi n'utilisez-vous pas le backend officiel ?
Officiel?
Nuage Terraform.
Quand est-il apparu?
Il y a environ 4 mois.
S'il était apparu il y a 4 ans, j'aurais probablement répondu à votre question.
Il existe déjà une fonction et des verrous intégrés, et vous pouvez stocker un fichier d'état. Essayez-le. Mais je n'ai pas testé non plus.
Nous sommes dans un gros train qui roule à grande vitesse. Et vous ne pouvez pas simplement prendre et jeter quelques voitures.
Vous parliez de flocons de neige, pourquoi n'avez-vous pas utilisé de branche ? Pourquoi cela n’a-t-il pas fonctionné ainsi ?
Notre approche est telle que toute l'infrastructure se trouve dans un seul référentiel. Terraform, Puppet, tous les scripts qui s'y rapportent d'une manière ou d'une autre, ils sont tous dans un seul référentiel. De cette façon, nous pouvons garantir que les changements incrémentiels sont testés un par un. S’il s’agissait d’un ensemble de succursales, un tel projet serait alors presque impossible à maintenir. Six mois s'écoulent et ils divergent tellement que ce n'est qu'une sorte de punition. C'est ce que je voulais fuir avant de refactoriser.
c'est-à-dire que ça ne marche pas ?
Cela ne fonctionne pas du tout.
En branche, j'ai découpé le dossier slide. Autrement dit, si vous faites pour chaque pile de tests, par exemple, l'équipe A a son propre papa, l'équipe B a son propre papa, alors cela ne fonctionne pas non plus. Nous avons créé un code d’environnement de test unifié suffisamment flexible pour convenir à tout le monde. Autrement dit, nous avons servi un seul code.
Bonjour! Je m'appelle Yura ! Merci pour le rapport! Question sur les modules. Vous dites que vous utilisez des modules. Comment résoudre le problème si des modifications ont été apportées à un module qui ne sont pas compatibles avec les modifications d'une autre personne ? En quelque sorte versionner des modules ou essayer d'amener un prodige à répondre à deux exigences ?
C’est le gros problème des tas de neige. C’est ce dont nous souffrons lorsqu’un changement inoffensif peut détruire une partie de l’infrastructure. Et cela ne sera perceptible qu’après un certain temps.
Autrement dit, cela n'a pas encore été décidé ?
Vous réalisez des modules universels. Évitez les flocons de neige. Et tout s'arrangera. La seconde moitié du rapport explique comment l’éviter.
Bonjour! Merci pour le rapport! Je voudrais clarifier. Dans les coulisses, il y avait un gros tas pour lequel je suis venu. Comment les marionnettes et la distribution des rôles sont-elles intégrées ?
données d'utilisateur.
Autrement dit, est-ce que vous venez de cracher le fichier et de l'exécuter d'une manière ou d'une autre ?
Les données utilisateur sont une note, c'est-à-dire que lorsque nous réalisons un clonage d'image, alors Daemon s'y lève et essaie de comprendre qui il est, lit une note indiquant qu'il est un équilibreur de charge.
Autrement dit, s’agit-il d’une sorte de processus distinct qui est dévoilé ?
Nous ne l'avons pas inventé. Nous l'utilisons.
Bonjour! J'ai juste une question sur les données utilisateur. Vous avez dit qu'il y avait des problèmes là-bas, que quelqu'un pourrait envoyer quelque chose au mauvais endroit. Existe-t-il un moyen de stocker les données utilisateur dans le même Git, afin qu'il soit toujours clair à quoi font référence les données utilisateur ?
Nous générons des données utilisateur à partir d'un modèle. C'est-à-dire qu'un certain nombre de variables y ont recours. Et Terraform génère le résultat final. Par conséquent, vous ne pouvez pas simplement regarder le modèle et dire ce qui se passe, car tous les problèmes sont liés au fait que le développeur pense qu'il passe une chaîne dans cette variable, puis qu'un tableau est utilisé. Et lui - bang et moi - untel, untel, la ligne suivante, et tout s'est cassé. S'il s'agit d'une nouvelle ressource et qu'une personne l'utilise et constate que quelque chose ne fonctionne pas, le problème est rapidement résolu. Et si ce groupe de mise à l'échelle automatique a été mis à jour, les instances du groupe de mise à l'échelle automatique commencent à un moment donné à être remplacées. Et applaudissez, quelque chose ne fonctionne pas. Ça fait mal.
Il s’avère que la seule solution est de tester ?
Oui, vous voyez le problème, vous y ajoutez des étapes de test. Autrement dit, la sortie peut également être testée. Ce n'est peut-être pas si pratique, mais vous pouvez également mettre quelques marques - vérifiez que les données utilisateur sont clouées ici.
Je m'appelle Timur. C'est très cool qu'il existe des rapports sur la façon d'organiser correctement Terraform .
Je n'ai même pas commencé.
Je pense que lors de la prochaine conférence, il y en aura peut-être. J'ai une question simple. Pourquoi codez-vous en dur la valeur dans un module séparé plutôt que d'utiliser tfvars, c'est-à-dire qu'un module avec des valeurs est meilleur que tfvars ?
Autrement dit, je devrais écrire ici (diapositive : Production/environment/settings.tf) : domaine = variable, domaine vpcnetwork, variable vpcnetwork et stvars - obtenez la même chose ?
C’est exactement ce que nous faisons. Nous nous référons par exemple au module source de paramétrage.
En fait, c'est un tel tfvars. Tfvars est très pratique dans un environnement de test. J'ai des tfvars pour les grandes instances, pour les petites. Et j'ai jeté un fichier dans le dossier. Et j’ai obtenu ce que je voulais. Lorsque nous voyons des infrastructures, nous voulons pouvoir tout voir et tout comprendre immédiatement. Et il s'avère que vous devez regarder ici, puis regarder dans les tfvars.
Il s'avère que tout était au même endroit ?
Oui, tfvars, c'est quand vous avez un seul code. Et il est utilisé à plusieurs endroits différents avec des nuances différentes. Ensuite, vous lancez des tfvars et obtenez vos nuances. Et nous sommes une infrastructure en tant que code dans sa forme la plus pure. Regardé et compris.
Bonjour! Avez-vous rencontré des situations où le fournisseur de cloud interfère avec ce que vous avez fait avec Terraform ? Disons que nous modifions les métadonnées. Il y a des clés ssh. Et Google y glisse sans cesse ses méta-données, ses clés. Et Terraform écrit toujours qu'il y a des changements. Après chaque exécution, même si rien ne change, il dit toujours qu'il mettra à jour ce champ maintenant.
Avec des clés, mais - oui, une partie de l'infrastructure est affectée par une telle chose, c'est-à-dire que Terraform ne peut rien changer. Nous ne pouvons rien changer non plus de nos mains. Tant qu'on vit avec.
Autrement dit, vous êtes tombé sur cela, mais vous n'avez rien trouvé, comment fait-il et le fait-il lui-même ?
Malheureusement oui.
Bonjour! Je m'appelle Stanislav Starkov. Mail. fr Groupe. Comment résolvez-vous le problème de génération d'une balise sur..., comment la transmettez-vous à l'intérieur ? Si je comprends bien, via les données utilisateur, pour spécifier le nom d'hôte, inciter Puppet ? Et la deuxième partie de la question. Comment résoudre ce problème dans SG, c'est à dire lorsque vous générez SG, une centaine d'instances du même type, comment les nommer correctement ?
Ces cas qui sont très importants pour nous, nous les nommerons magnifiquement. Pour ceux qui ne sont pas nécessaires, il y a un post-scriptum indiquant qu'il s'agit d'un groupe de mise à l'échelle automatique. Et en théorie, vous pouvez le clouer et en obtenir un nouveau.
Quant au problème avec la balise, un tel problème n’existe pas, mais une telle tâche existe. Et nous utilisons très, très massivement les tags, car l’infrastructure est vaste et coûteuse. Et nous devons examiner à quoi l’argent est dépensé, afin que les étiquettes nous permettent de déterminer quoi et où il est allé. Et, par conséquent, chercher quelque chose ici coûte beaucoup d’argent.
Sur quoi d'autre portait la question ?
Lorsque SG crée une centaine d’instances, faut-il les distinguer d’une manière ou d’une autre ?
Non, non. Chaque instance a un agent qui me dit que j'ai un problème. Si l'agent signale, alors il le connaît et, au moins, son adresse IP existe. Vous pouvez déjà courir. Deuxièmement, nous utilisons Consul pour Discovery, où il n'y a pas de Kubernetes. Et Consul affiche également l'adresse IP de l'instance.
Autrement dit, vous ciblez exactement l'adresse IP, et non le nom d'hôte ?
Il est impossible de naviguer par nom d'hôte, c'est à dire qu'ils sont nombreux. Il existe des identifiants d'instance - AE, etc. Vous pouvez le trouver quelque part, vous pouvez le lancer dans la recherche.
Bonjour! J'ai réalisé que Terraform était une bonne chose, adaptée aux nuages.
Pas seulement.
C'est la question qui m'intéresse. Si vous décidez de migrer, disons, vers le Bare Metal en masse avec toutes vos instances ? Y aura-t-il des problèmes ? Ou devez-vous toujours utiliser d'autres produits, par exemple le même Ansible mentionné ici ?
Ansible, c'est un peu autre chose. Autrement dit, Ansible est déjà en cours d'exécution lorsque l'instance a démarré. Et Terraform fonctionne avant le démarrage de l'instance. Passer au Bare Metal ne l’est pas.
Pas maintenant, mais les entreprises viendront et diront : « Allez ».
Passer à un autre cloud - oui, mais il y a ici une fonctionnalité légèrement différente. Vous devez écrire le code Terraform de manière à pouvoir passer à un autre cloud avec moins d'effusion de sang.
Initialement, la tâche était que toute notre infrastructure soit agnostique, c'est-à-dire que n'importe quel cloud devrait convenir, mais à un moment donné, l'entreprise a abandonné et a déclaré : « OK, dans les N prochaines années, nous n'irons nulle part, vous pouvez utiliser les services de Amazone".
Terraform vous permet de créer des tâches Front-End, de configurer PagerDuty, des documents de données, etc. Il a beaucoup de queues. Il peut pratiquement contrôler le monde entier.
Merci pour le rapport! Je fais également tourner Terraform depuis 4 ans maintenant. Au stade d'une transition en douceur vers Terraform, vers l'infrastructure, vers une description déclarative, nous avons été confrontés à une situation où quelqu'un faisait quelque chose à la main et vous essayiez d'élaborer un plan. Et j'ai eu une erreur là-bas. Comment gérez-vous de tels problèmes ? Comment retrouver les ressources perdues qui ont été indiquées ?
Surtout avec nos mains et nos yeux, si nous voyons quelque chose d'étrange dans le rapport, alors nous analysons ce qui s'y passe, ou nous le tuons simplement. En général, les pull request sont monnaie courante.
S'il y a une erreur, effectuez-vous une restauration ? Avez-vous essayé de faire cela ?
Non, c'est une décision d'une personne au moment où elle voit le problème.
Source: habr.com