De nombreuses personnes connaissent et utilisent Terraform dans leur travail quotidien, mais les meilleures pratiques n'ont pas encore été élaborées. Chaque équipe doit inventer ses propres approches et méthodes.
Votre infrastructure commence presque certainement simplement : quelques ressources + quelques développeurs. Au fil du temps, il se développe dans toutes sortes de directions. Trouvez-vous des moyens de regrouper les ressources dans des modules Terraform, d'organiser le code dans des dossiers et qu'est-ce qui pourrait éventuellement mal se passer ? (derniers mots célèbres)
Le temps passe et vous avez l’impression que votre infrastructure est votre nouvel animal de compagnie, mais pourquoi ? Vous vous inquiétez des changements inexplicables dans l'infrastructure, vous avez peur de toucher à l'infrastructure et au code - en conséquence, vous retardez les nouvelles fonctionnalités ou réduisez la qualité...
Après trois ans de gestion d'une collection de modules communautaires Terraform pour AWS sur Github et de maintenance à long terme de Terraform en production, Anton Babenko est prêt à partager son expérience : comment écrire des modules TF pour que cela ne fasse pas de mal à l'avenir.
À la fin de la conférence, les participants seront plus familiers avec les principes de gestion des ressources dans Terraform, les meilleures pratiques associées aux modules dans Terraform et certains principes d'intégration continue associés à la gestion de l'infrastructure.
Avertissement: Je constate que ce rapport est daté de novembre 2018 – 2 ans se sont déjà écoulés. La version de Terraform 0.11 évoquée dans le rapport n'est plus prise en charge. Au cours des 2 dernières années, 2 nouvelles versions ont été publiées, qui contiennent de nombreuses innovations, améliorations et changements. Veuillez y prêter attention et vérifier la documentation.
Liens:
- +
- — code de formatage automatique et documentation
- — générateur de modules Terraform (WIP)
- — Générateur de code Terraform à partir de diagrammes visuels (WIP)
- www.terraform-best-practices.com
- (Les nouveaux articles sont sur mon site personnel www.antonbabenko.com/)
- @antonbabenko - Twitter et un tas de Slacks différents
Je m'appelle Anton Babenko. Certains d'entre vous ont probablement utilisé le code que j'ai écrit. J'en parlerai désormais avec plus d'assurance que jamais, car j'ai accès aux statistiques.
Je travaille sur Terraform et j'ai participé et contribué activement à un grand nombre de projets open source liés à Terraform et Amazon depuis 2015.
Depuis, j'ai écrit suffisamment de code pour le présenter de manière intéressante. Et je vais essayer de vous en parler maintenant.
Je parlerai des subtilités et des spécificités du travail avec Terraform. Mais ce n'est pas vraiment le sujet de HighLoad. Et maintenant vous comprendrez pourquoi.
Au fil du temps, j'ai commencé à écrire des modules Terraform. Les utilisateurs ont écrit des questions, je les ai réécrites. Ensuite, j'ai écrit divers utilitaires pour formater le code à l'aide d'un hook de pré-commit, etc.
Il y avait beaucoup de projets intéressants. J'aime la génération de code parce que j'aime que l'ordinateur fasse de plus en plus de travail pour moi et le programmeur, je travaille donc actuellement sur un générateur de code Terraform à partir de diagrammes visuels. Peut-être que certains d'entre vous les ont vus. Ce sont de belles boites avec des flèches. Et je pense que c'est génial si vous pouvez cliquer sur le bouton « Exporter » et obtenir le tout sous forme de code.
Je suis d'Ukraine. Je vis en Norvège depuis de nombreuses années.
De plus, les informations pour ce rapport ont été collectées auprès de personnes qui connaissent mon nom et me trouvent sur les réseaux sociaux. J'ai presque toujours le même surnom.
Comme je l'ai mentionné, je suis le principal responsable des modules Terraform AWS, qui est l'un des plus grands référentiels sur GitHub où nous hébergeons des modules pour les tâches les plus courantes : VPC, Autoscaling, RDS.
Et ce que vous avez entendu maintenant est le plus élémentaire. Si vous doutez de comprendre ce qu'est Terraform, il est préférable de passer votre temps ailleurs. Il y aura beaucoup de termes techniques ici. Et je n'ai pas hésité à déclarer que le niveau du rapport était le plus élevé. Cela signifie que je peux parler en utilisant tous les termes possibles sans trop d’explications.
Terraform est apparu en 2014 comme un utilitaire permettant d'écrire, de planifier et de gérer une infrastructure sous forme de code. Le concept clé ici est « l’infrastructure en tant que code ».
Toute la documentation, comme je l'ai dit, est écrite en . J'espère que la plupart des gens connaissent ce site et ont lu la documentation. Si oui, alors vous êtes dans la bonne zone.
Voici à quoi ressemble un fichier de configuration Terraform standard, dans lequel nous définissons d'abord certaines variables.
Dans ce cas, nous définissons « aws_region ».
Ensuite, nous décrivons les ressources que nous souhaitons créer.
Nous exécutons quelques commandes, notamment « terraform init » afin de charger les dépendances et les fournisseurs.
Et nous exécutons la commande « terraform apply » afin de vérifier si la configuration spécifiée correspond aux ressources que nous avons créées. Comme nous n'avons rien créé auparavant, Terraform nous propose de créer ces ressources.
Nous le confirmons. Nous créons ainsi un seau appelé escargot de mer.
Il existe également plusieurs utilitaires similaires. Beaucoup d'entre vous qui utilisent Amazon connaissent AWS CloudFormation, Google Cloud Deployment Manager ou Azure Resource Manager. Chacun d’eux a sa propre implémentation pour gérer les ressources au sein de chacun de ces fournisseurs de cloud public. Terraform est particulièrement utile car il vous permet de gérer plus de 100 fournisseurs. (Plus de détails )
Les objectifs poursuivis par Terraform depuis le début :
- Terraform fournit une vue unique des ressources.
- Vous permet de prendre en charge toutes les plates-formes modernes.
- Et Terraform a été conçu dès le début comme un utilitaire qui vous permet de modifier l'infrastructure de manière sûre et prévisible.
En 2014, le mot « prévisible » semblait très inhabituel dans ce contexte.
Terraform est un utilitaire universel. Si vous disposez d’une API, vous pouvez absolument tout contrôler :
- Vous pouvez faire appel à plus de 120 fournisseurs pour gérer tout ce que vous voulez.
- Par exemple, vous pouvez utiliser Terraform pour décrire l'accès aux référentiels GitHub.
- Vous pouvez même créer et fermer des bugs dans Jira.
- Vous pouvez gérer les métriques New Relic.
- Vous pouvez même créer des fichiers dans Dropbox si vous le souhaitez vraiment.
Tout cela est réalisé à l'aide des fournisseurs Terraform, qui disposent d'une API ouverte qui peut être décrite dans Go.
Disons que nous avons commencé à utiliser Terraform, lu de la documentation sur le site, regardé des vidéos et commencé à écrire main.tf, comme je l'ai montré sur les diapositives précédentes.
Et tout va bien, vous avez un fichier qui crée un VPC.
Si vous souhaitez créer un VPC, vous spécifiez environ ces 12 lignes. Décrivez dans quelle région vous souhaitez créer, quel cidr_block d'adresses IP utiliser. C'est tout.
Naturellement, le projet grandira progressivement.
Et vous y ajouterez une tonne de nouveautés : des ressources, des sources de données, vous intégrerez de nouveaux fournisseurs, du coup vous souhaiterez utiliser Terraform pour gérer les utilisateurs de votre compte GitHub, etc. Vous souhaiterez peut-être utiliser différents fournisseurs DNS, traversez tout. Terraform rend cela facile.
Regardons l'exemple suivant.
Vous ajoutez progressivement internet_gateway car vous souhaitez que les ressources de votre VPC aient accès à Internet. C'est une bonne idée.
Le résultat est ce main.tf :
C'est la partie supérieure de main.tf.
C'est la partie inférieure de main.tf.
Ensuite, vous ajoutez un sous-réseau. Au moment où vous souhaiterez ajouter des passerelles NAT, des routes, des tables de routage et de nombreux autres sous-réseaux, vous n'aurez pas 38 lignes, mais environ 200 à 300 lignes.
Autrement dit, votre fichier main.tf se développe progressivement. Et bien souvent, les gens mettent tout dans un seul fichier. 10-20 Ko apparaissent dans main.tf. Imaginez que 10 à 20 Ko correspondent à du contenu textuel. Et tout est lié à tout. Cela devient progressivement difficile à gérer. 10-20 Ko est un bon cas d'utilisation, parfois plus. Et les gens ne pensent pas toujours que c’est mauvais.
Comme dans la programmation classique, c'est-à-dire pas dans l'infrastructure en tant que code, nous sommes habitués à utiliser un tas de classes, packages, modules, regroupements différents. Terraform vous permet de faire à peu près la même chose.
- Le code s'agrandit.
- Les dépendances entre les ressources augmentent également.
Et nous avons un très grand besoin. Nous comprenons que nous ne pouvons plus vivre ainsi. Notre code devient immense. 10-20 Ko, ce n'est bien sûr pas très vaste, mais nous parlons uniquement de la pile réseau, c'est-à-dire que vous n'avez fait qu'ajouter des ressources réseau. Nous ne parlons pas d'Application Load Balancer, de déploiement de cluster ES, de Kubernetes, etc., où 100 Ko peuvent facilement être intégrés. Si vous notez tout cela, vous apprendrez très vite que Terraform propose des modules Terraform.
Les modules Terraform sont une configuration Terraform autonome gérée en groupe. C'est tout ce que vous devez savoir sur les modules Terraform. Ils ne sont pas intelligents du tout, ils ne permettent pas d'établir des connexions complexes en fonction de quelque chose. Tout cela repose sur les épaules des développeurs. Autrement dit, il s'agit simplement d'une sorte de configuration Terraform que vous avez déjà écrite. Et vous pouvez simplement l'appeler en groupe.
Nous essayons donc de comprendre comment nous allons optimiser nos 10-20-30 Ko de code. Nous réalisons petit à petit que nous devons utiliser certains modules.
Le premier type de modules que vous rencontrez sont les modules de ressources. Ils ne comprennent pas en quoi consiste votre infrastructure, en quoi consiste votre entreprise, où et quelles sont les conditions. Ce sont exactement les modules que j'administre, en collaboration avec la communauté open source, et que nous proposons comme les tout premiers éléments de base de votre infrastructure.
Un exemple de module de ressources.
Lorsque nous appelons un module de ressources, nous spécifions à partir de quel chemin nous devons charger son contenu.
Nous indiquons quelle version nous souhaitons télécharger.
Nous y passons un tas d'arguments. C'est tout. C'est tout ce que nous devons savoir lorsque nous utilisons ce module.
Beaucoup de gens pensent que s’ils utilisent la dernière version, tout sera stable. Mais non. L'infrastructure doit être versionnée, il faut clairement répondre sur quelle version tel ou tel composant a été déployé.
Voici le code qui se trouve à l'intérieur de ce module. Module de groupe de sécurité. Ici, le parchemin va à la 640ème ligne. Créer une ressource de groupe de sécurité dans Amazon dans toutes les configurations possibles est une tâche très non triviale. Il ne suffit pas de simplement créer un groupe de sécurité et de lui indiquer les règles à lui transmettre. Ce serait très simple. Il existe un million de restrictions différentes sur Amazon. Par exemple, si vous utilisez Point de terminaison d'un VPC, liste de préfixes, diverses API et essaie de combiner tout cela avec tout le reste, alors Terraform ne vous permet pas de le faire. Et l'API Amazon ne le permet pas non plus. Par conséquent, nous devons cacher toute cette terrible logique dans un module et donner à l’utilisateur un code qui ressemble à ceci.
L'utilisateur n'a pas besoin de savoir comment il est fabriqué à l'intérieur.
Le deuxième type de modules, constitué de modules de ressources, résout déjà des problèmes plus applicables à votre entreprise. Il s'agit souvent d'un endroit qui constitue une extension pour Terraform et définit des valeurs rigides pour les balises, conformément aux normes de l'entreprise. Vous pouvez également y ajouter des fonctionnalités que Terraform ne vous permet pas actuellement d'utiliser. C'est maintenant. Désormais la version 0.11, qui est sur le point de devenir une chose du passé. Mais néanmoins, les préprocesseurs, jsonnet, cookiecutter et bien d'autres choses sont le mécanisme auxiliaire qui doit être utilisé pour un travail à part entière.
Ensuite, je vais en montrer quelques exemples.
Le module infrastructure est appelé exactement de la même manière.
La source à partir de laquelle télécharger le contenu est indiquée.
Un tas de valeurs sont transmises et transmises à ce module.
Ensuite, à l'intérieur de ce module, un ensemble de modules de ressources sont appelés pour créer un VPC ou un Application Load Balancer, ou pour créer un groupe de sécurité ou pour un cluster Elastic Container Service.
Il existe deux types de modules. Ceci est important à comprendre car la plupart des informations que j'ai regroupées dans ce rapport ne sont pas écrites dans la documentation.
Et la documentation de Terraform à l'heure actuelle est assez problématique car elle dit simplement qu'il existe ces fonctionnalités, vous pouvez les utiliser. Mais elle ne dit pas comment utiliser ces fonctionnalités, ni pourquoi il est préférable de les utiliser. Par conséquent, un très grand nombre de personnes écrivent quelque chose avec lequel ils ne peuvent pas vivre.
Voyons ensuite comment écrire ces modules. Nous verrons ensuite comment les appeler et comment travailler avec le code.
Registre Terraform -
Le conseil n°0 est de ne pas écrire de modules de ressources. La plupart de ces modules sont déjà écrits pour vous. Comme je l'ai dit, ils sont open source, ils ne contiennent aucune de votre logique métier, ils n'ont pas de valeurs codées en dur pour les adresses IP, les mots de passe, etc. Le module est très flexible. Et cela a probablement déjà été écrit. Il existe de nombreux modules pour les ressources d'Amazon. Environ 650. Et la plupart sont de bonne qualité.
Dans cet exemple, quelqu'un est venu vers vous et vous a dit : « Je veux pouvoir gérer une base de données. Créez un module pour que je puisse créer une base de données." La personne ne connaît pas les détails de mise en œuvre d'Amazon ou de Terraform. Il dit simplement : « Je veux gérer MSSQL ». Autrement dit, nous voulons dire qu'il appellera notre module, y transmettra le type de moteur et indiquera le fuseau horaire.
Et personne ne doit savoir que nous allons créer deux ressources différentes à l'intérieur de ce module : une pour MSSQL, la seconde pour tout le reste, uniquement parce que dans Terraform 0.11, vous ne pouvez pas spécifier les valeurs de fuseau horaire comme facultatives.
Et à la sortie de ce module, une personne pourra simplement recevoir une adresse. Il ne saura pas à partir de quelle base de données, à partir de quelle ressource nous créons tout cela en interne. C’est un élément de dissimulation très important. Et cela s'applique non seulement aux modules qui sont publics en open source, mais également aux modules que vous écrirez au sein de vos projets et de vos équipes.
C'est le deuxième argument, assez important si vous utilisez Terraform depuis un moment. Vous disposez d'un référentiel dans lequel vous mettez tous vos modules Terraform pour votre entreprise. Et il est tout à fait normal qu'avec le temps, ce projet atteigne une taille d'un ou deux mégaoctets. C'est bon.
Mais le problème est de savoir comment Terraform appelle ces modules. Par exemple, si vous appelez un module pour créer chaque utilisateur individuel, Terraform chargera d'abord l'intégralité du référentiel, puis naviguera vers le dossier où se trouve ce module spécifique. De cette façon, vous téléchargerez un mégaoctet à chaque fois. Si vous gérez 100 ou 200 utilisateurs, vous téléchargerez 100 ou 200 mégaoctets, puis accéderez à ce dossier. Donc, naturellement, vous ne voulez pas télécharger un tas de choses à chaque fois que vous cliquez sur "Terraform init".
Il y a deux solutions pour ce problème. La première consiste à utiliser des chemins relatifs. De cette façon, vous indiquez dans le code que le dossier est local (./). Et avant de lancer quoi que ce soit, vous faites un clone Git de ce dépôt localement. De cette façon, vous le faites une fois.
Il y a bien sûr de nombreux inconvénients. Par exemple, vous ne pouvez pas utiliser le contrôle de version. Et c’est parfois difficile à vivre.
Deuxième solution. Si vous avez beaucoup de sous-modules et que vous disposez déjà d'une sorte de pipeline établi, il existe alors le projet MBT, qui vous permet de collecter de nombreux packages différents à partir d'un mono-dépôt et de les télécharger sur S3. C'est un très bon moyen. Ainsi, le fichier iam-user-1.0.0.zip ne pèsera que 1 Ko, car le code pour créer cette ressource est très petit. Et cela fonctionnera beaucoup plus rapidement.
Parlons de ce qui ne peut pas être utilisé dans les modules.
Pourquoi ce mal est-il dans les modules ? Le pire, c'est d'assumer l'utilisateur. Supposons que l'utilisateur soit une option d'authentification du fournisseur qui peut être utilisée par différentes personnes. Par exemple, nous allons tous assimiler le rôle. Cela signifie que Terraform assumera ce rôle. Et puis, avec ce rôle, il effectuera d’autres actions.
Et le mal est que si Vasya aime se connecter à Amazon d'une manière, par exemple en utilisant la variable d'environnement par défaut, et que Petya aime utiliser sa clé partagée, qu'il a dans un endroit secret, alors vous ne pouvez pas spécifier les deux dans Terraforme. Et pour qu’ils ne subissent pas de souffrance, il n’est pas nécessaire d’indiquer ce blocage dans le module. Cela doit être indiqué à un niveau supérieur. Autrement dit, nous avons un module de ressources, un module d'infrastructure et une composition en haut. Et cela devrait être indiqué quelque part plus haut.
Le deuxième mal est celui qui pourvoit. Ici, le mal n'est pas si anodin, car si vous écrivez du code et qu'il fonctionne pour vous, alors vous pouvez penser que si cela fonctionne, alors pourquoi le changer.
Le problème, c’est que vous ne contrôlez pas toujours quand ce fournisseur sera lancé. Et deuxièmement, vous ne contrôlez pas ce que signifie aws ec2, c'est-à-dire parlons-nous de Linux ou de Windows maintenant. Vous ne pouvez donc pas écrire quelque chose qui fonctionnera de la même manière sur différents systèmes d'exploitation ou pour différents cas d'utilisation.
L'exemple le plus courant, qui est également indiqué dans la documentation officielle, est que si vous écrivez aws_instance et spécifiez un tas d'arguments, alors il n'y a rien de mal à cela si vous y spécifiez le provisionneur « local-exec » et exécutez votre ansible- livre de jeu.
En fait, oui, il n’y a rien de mal à cela. Mais vous vous rendrez bientôt compte que cette chose d'exécution locale n'existe pas, par exemple, dans launch_configuration.
Et lorsque vous utilisez launch_configuration et que vous souhaitez créer un groupe de mise à l'échelle automatique à partir d'une instance, alors dans launch_configuration, il n'y a pas de concept de « provisionneur ». Il y a la notion de « données utilisateur ».
Par conséquent, une solution plus universelle consiste à utiliser les données des utilisateurs. Et il sera lancé soit sur l'instance elle-même, lorsque l'instance est activée, soit dans les mêmes données utilisateur, lorsque le groupe d'autoscaling utilise cette launch_configuration.
Si vous souhaitez toujours exécuter le provisionneur, car il s'agit d'un composant de collage, lorsqu'une ressource est créée, vous devez à ce moment-là exécuter votre provisionneur, votre commande. Il existe de nombreuses situations de ce type.
Et la ressource la plus correcte pour cela s'appelle null_resource. Null_resource est une ressource factice qui n'est jamais réellement créée. Cela ne touche à rien, pas d'API, pas d'autoscaling. Mais cela vous permet de contrôler quand exécuter la commande. Dans ce cas, la commande est exécutée lors de la création.
Lien
Il y a plusieurs signes. Je n’entrerai pas dans les détails de tous les signes. Il y a un article à ce sujet. Mais si vous avez travaillé avec Terraform ou utilisé les modules d'autres personnes, vous avez souvent remarqué que de nombreux modules, comme la plupart du code open source, sont écrits par des personnes pour leurs propres besoins. Un homme l'a écrit et a résolu son problème. Je l'ai collé dans GitHub, laissez-le vivre. Il vivra, mais s'il n'y a pas de documentation ni d'exemples, personne ne l'utilisera. Et s'il n'existe aucune fonctionnalité qui vous permette de résoudre un peu plus que sa tâche spécifique, alors personne ne l'utilisera non plus. Il existe de nombreuses façons de perdre des utilisateurs.
Si vous souhaitez écrire quelque chose pour que les gens l'utilisent, je vous recommande de suivre ces panneaux.
Ce sont:
- Documentation et exemples.
- Fonctionnalité complète.
- Des défauts raisonnables.
- Code propre.
- Tests
Les tests sont une situation différente car ils sont assez difficiles à rédiger. Je crois davantage à la documentation et aux exemples.
Nous avons donc examiné comment écrire des modules. Il y a deux arguments. La première, qui est la plus importante, est de ne pas écrire si vous le pouvez, car un tas de personnes ont déjà réalisé ces tâches avant vous. Et deuxièmement, si vous décidez néanmoins, essayez de ne pas utiliser de fournisseurs dans les modules et les provisionneurs.
C'est la partie grise de la documentation. Vous pensez peut-être maintenant : « Quelque chose n’est pas clair. Pas convaincu." Mais nous verrons dans six mois.
Parlons maintenant de la façon d'appeler ces modules.
Nous comprenons que notre code évolue avec le temps. Nous n’avons plus un seul dossier, nous en avons déjà 20. Ils sont tous dans un seul dossier. Ou peut-être dans cinq dossiers. Peut-être commençons-nous d’une manière ou d’une autre à les ventiler par région, selon certaines composantes. On comprend alors que maintenant on a quelques rudiments de synchronisation et d’orchestration. Autrement dit, nous devons comprendre ce que nous devons faire si nous modifions les ressources du réseau, ce que nous devons faire avec le reste de nos ressources, comment provoquer ces dépendances, etc.
Il y a deux extrêmes. Le premier extrême est tout en un. Nous avons un fichier maître. Pour le moment, il s'agissait de la meilleure pratique officielle sur le site Terraform.
Mais maintenant, il est écrit comme obsolète et supprimé. Au fil du temps, la communauté Terraform s'est rendu compte que c'était loin d'être la meilleure pratique, car les gens ont commencé à utiliser le projet de différentes manières. Et il y a des problèmes. Par exemple, lorsque nous répertorions toutes les dépendances au même endroit. Il y a des situations où nous cliquons sur « Plan Terraform » et jusqu'à ce que Terraform mette à jour les états de toutes les ressources, beaucoup de temps peut s'écouler.
Beaucoup de temps équivaut, par exemple, à 5 minutes. Pour certains, cela prend beaucoup de temps. J'ai vu des cas où cela prenait 15 minutes. L'API AWS a passé 15 minutes à essayer de comprendre ce qui se passait avec l'état de chaque ressource. Il s'agit d'une très vaste zone.
Et, naturellement, un problème connexe apparaîtra lorsque vous souhaitez modifier quelque chose à un endroit, puis vous attendez 15 minutes, et cela vous donne un aperçu de certains changements. Vous avez craché, écrit « Oui » et quelque chose s’est mal passé. Ceci est un exemple très réel. Terraform n'essaie pas de vous protéger des problèmes. Autrement dit, écrivez ce que vous voulez. Il y aura des problèmes – vos problèmes. Bien que Terraform 0.11 n'essaye en aucun cas de vous aider. Il y a certains endroits intéressants dans 0.12 qui permettent de dire : « Vasya, tu veux vraiment ça, peux-tu reprendre tes esprits ?
La deuxième façon consiste à réduire cette zone, c'est-à-dire que les appels provenant d'un endroit peuvent être moins connectés depuis un autre endroit.
Le seul problème est que vous devez écrire plus de code, c'est-à-dire que vous devez décrire les variables dans un grand nombre de fichiers et les mettre à jour. Certaines personnes n'aiment pas ça. C'est normal pour moi. Et certains pensent : « Pourquoi écrire ça à différents endroits, je vais tout mettre au même endroit. » C'est possible, mais c'est le deuxième extrême.
Qui a tout cela vivant au même endroit ? Une, deux, trois personnes, c'est-à-dire que quelqu'un l'utilise.
Et qui appelle un composant particulier, un bloc ou un module d’infrastructure ? Cinq à sept personnes. C'est cool.
La réponse la plus courante se situe quelque part entre les deux. Si le projet est de grande envergure, vous vous retrouverez souvent dans une situation où aucune solution ne convient et où tout ne fonctionne pas, vous vous retrouverez donc avec un mélange. Il n’y a rien de mal à cela, tant que vous comprenez que les deux ont des avantages.
Si quelque chose a changé dans le VPC de la pile et que vous souhaitez appliquer ces modifications à EC2, c'est-à-dire que vous souhaitez mettre à jour le groupe de mise à l'échelle automatique parce que vous aviez un nouveau sous-réseau, alors j'appelle ce type d'orchestration des dépendances. Il existe des solutions : qui utilise quoi ?
Je peux suggérer quelles solutions existent. Vous pouvez utiliser Terraform pour faire la magie, ou vous pouvez utiliser des makefiles pour utiliser Terraform. Et voyez si quelque chose a changé là-bas, vous pouvez le lancer ici.
Comment aimez-vous cette décision ? Quelqu'un pense-t-il que c'est une solution intéressante ? Je vois un sourire, apparemment des doutes se sont glissés.
Bien sûr, n’essayez pas cela à la maison. Terraform n'a jamais été conçu pour être exécuté à partir de Terraform.
Lors d’un rapport, ils m’ont dit : « Non, ça ne marchera pas. » Le fait est que cela ne devrait pas fonctionner. Même si cela semble si impressionnant lorsque vous pouvez lancer Terraform à partir de Terraform, puis Terraform, vous ne devriez pas le faire. Terraform devrait toujours démarrer très facilement.
Si vous avez besoin d'une orchestration d'appels lorsque quelque chose a changé à un endroit, alors il y a Terragrunt.
Terragrunt est un utilitaire, un module complémentaire à Terraform, qui vous permet de coordonner et d'orchestrer les appels aux modules d'infrastructure.
Un fichier de configuration Terraform typique ressemble à ceci.
Vous spécifiez le module spécifique que vous souhaitez appeler.
Quelles dépendances le module a-t-il ?
Et quels arguments ce module accepte-t-il. C'est tout ce qu'il y a à savoir sur Terragrunt.
La documentation est là et il y a 1 700 étoiles sur GitHub. Mais dans la plupart des cas, c’est ce que vous devez savoir. Et cela est très simple à mettre en œuvre dans les entreprises qui commencent tout juste à travailler avec Terraform.
L'orchestration est donc Terragrunt. Il existe d'autres options.
Parlons maintenant de la façon de travailler avec le code.
Si vous devez ajouter de nouvelles fonctionnalités à votre code, dans la plupart des cas, cela est simple. Vous écrivez une nouvelle ressource, tout est simple.
Si vous disposez d'une ressource que vous avez créée à l'avance, par exemple, si vous avez découvert Terraform après avoir ouvert un compte AWS et souhaitez utiliser les ressources dont vous disposez déjà, il serait alors approprié d'étendre votre module de cette manière, afin que il soutient l’utilisation des ressources existantes.
Et pris en charge la création de nouvelles ressources en utilisant la ressource de bloc.
En sortie, nous renvoyons toujours l'identifiant de sortie en fonction de ce qui a été utilisé.
Le deuxième problème très important de Terraform 0.11 est le travail avec les listes.
La difficulté est que si nous avons une telle liste d'utilisateurs.
Et lorsque nous créons ces utilisateurs en utilisant une ressource de bloc, tout se passe bien. Nous parcourons toute la liste en créant un fichier pour chacun. Tout va bien. Et puis, par exemple, l'utilisateur 3, qui est au milieu, devrait être supprimé d'ici, puis toutes les ressources créées après lui seront recréées car l'index changera.
Travailler avec des listes dans un environnement avec état. Qu'est-ce qu'un environnement avec état ? C'est la situation où une nouvelle valeur est créée lors de la création de cette ressource. Par exemple, AWS Access Key ou AWS Secret Key, c'est-à-dire que lorsque nous créons un utilisateur, nous recevons une nouvelle clé d'accès ou secrète. Et chaque fois que nous supprimons un utilisateur, cet utilisateur aura une nouvelle clé. Mais ce n'est pas du feng shui, car l'utilisateur ne voudra pas être ami avec nous si nous créons un nouvel utilisateur pour lui à chaque fois que quelqu'un quitte l'équipe.
C'est la solution. Il s'agit d'un code écrit en Jsonnet. Jsonnet est un langage de création de modèles de Google.
Cette commande vous permet d'accepter ce modèle et en sortie, elle renvoie un fichier json créé selon votre modèle.
Le modèle ressemble à ceci.
Terraform vous permet de travailler avec HCL et Json de la même manière, donc si vous avez la possibilité de générer du Json, vous pouvez le glisser dans Terraform. Le fichier avec l'extension .tf.json sera téléchargé avec succès.
Et puis nous travaillons avec comme d'habitude : terraform init, terramorm apply. Et nous créons deux utilisateurs.
Désormais, nous n'avons plus peur si quelqu'un quitte l'équipe. Nous allons simplement éditer le fichier json. Vasya Pupkin est parti, Petya Pyatochkin est resté. Petya Pyatchkin ne recevra pas de nouvelle clé.
Intégrer Terraform à d'autres outils n'est pas vraiment le travail de Terraform. Terraform a été créé comme une plateforme de création de ressources et c'est tout. Et tout ce qui surviendra plus tard ne concerne pas Terraform. Et il n’est pas nécessaire de l’intégrer ici. Il existe Ansible, qui fait tout ce dont vous avez besoin.
Mais des situations surviennent lorsque nous souhaitons étendre Terraform et appeler une commande une fois que quelque chose est terminé.
Première façon. Nous créons une sortie où nous écrivons cette commande.
Et puis nous appelons cette commande à partir de la sortie du shell terraform et spécifions la valeur que nous voulons. Ainsi, la commande est exécutée avec toutes les valeurs substituées. C'est très confortable.
Deuxième façon. Il s'agit de l'utilisation de null_resource en fonction des évolutions de notre infrastructure. Nous pouvons appeler le même local-exe dès que l'ID de certaines ressources change.
Naturellement, tout cela est simple sur le papier, car Amazon, comme tous les autres fournisseurs publics, a ses propres cas extrêmes.
Le cas extrême le plus courant est que lorsque vous ouvrez un compte AWS, les régions que vous utilisez sont importantes ; cette fonctionnalité est-elle activée là-bas ? peut-être que vous l'avez ouvert après décembre 2013 ; peut-être utilisez-vous la valeur par défaut dans VPC, etc. Il existe de nombreuses restrictions. Et Amazon les a dispersés dans toute la documentation.
Il y a quelques choses que je recommande d’éviter.
Pour commencer, évitez tous les arguments non secrets dans le plan Terraform ou Terraform CLI. Tout cela peut être mis soit dans un fichier tfvars, soit dans une variable d'environnement.
Mais vous n’avez pas besoin de mémoriser toute cette commande magique. Plan Terraform – var et c'est parti. La première variable est var, la deuxième variable est var, la troisième, la quatrième. Le principe le plus important de l'infrastructure en tant que code que j'utilise le plus souvent est qu'en regardant simplement le code, je dois avoir une compréhension claire de ce qui y est déployé, dans quel état et avec quelles valeurs. Et donc je n'ai pas besoin de lire la documentation ou de demander à Vasya quels paramètres il a utilisés pour créer notre cluster. J'ai juste besoin d'ouvrir un fichier avec l'extension tfvars, qui correspond souvent à l'environnement, et de tout regarder là-bas.
N’utilisez pas non plus d’arguments cibles pour réduire la portée. Pour cela, il est beaucoup plus simple d'utiliser de petits modules d'infrastructure.
De plus, il n’est pas nécessaire de limiter ou d’augmenter le parallélisme. Si j'ai 150 ressources et que je souhaite augmenter le parallélisme Amazon de 10 à 100 par défaut, il est fort probable que quelque chose se passe mal. Ou bien, tout se passera peut-être bien maintenant, mais quand Amazon vous dira que vous passez trop d'appels, vous aurez des ennuis.
Terraform tentera de redémarrer la plupart de ces problèmes, mais vous n'obtiendrez presque rien. Le parallélisme = 1 est une chose importante à utiliser si vous tombez sur un bug dans l'API AWS ou dans le fournisseur Terraform. Et puis vous devez spécifier : parallélisme=1 et attendre que Terraform termine un appel, puis le deuxième, puis le troisième. Il les lancera un à un.
Les gens me demandent souvent : « Pourquoi est-ce que je pense que les espaces de travail Terraform sont mauvais ? » Je crois que le principe de l'infrastructure en tant que code est de voir quelle infrastructure a été créée et avec quelles valeurs.
Les espaces de travail n'ont pas été créés par les utilisateurs. Cela ne signifie pas que les utilisateurs ont écrit dans GitHub que nous ne pouvons pas vivre sans les espaces de travail Terraform. Non, pas comme ça. Terraform Enterprise est une solution commerciale. Terraform de HashiCorp a décidé que nous avions besoin d'espaces de travail, nous l'avons donc classé. Je trouve beaucoup plus facile de le mettre dans un dossier séparé. Ensuite, il y aura un peu plus de fichiers, mais ce sera plus clair.
Comment travailler avec le code ? En fait, travailler avec des listes est la seule difficulté. Et prenez Terraform plus facilement. Ce n’est pas quelque chose qui fera tout pour vous. Il n'est pas nécessaire d'y glisser tout ce qui est écrit dans la documentation.
Le sujet du rapport a été rédigé « pour l’avenir ». Je vais en parler très brièvement. Pour l’avenir, cela signifie que la version 0.12 sera bientôt disponible.
La 0.12 est une tonne de nouveautés. Si vous venez d'une programmation régulière, vous manquez toutes sortes de blocs dynamiques, de boucles, d'opérations de comparaison correctes et conditionnelles, où les côtés gauche et droit ne sont pas calculés simultanément, mais en fonction de la situation. Cela vous manque beaucoup, donc 0.12 le résoudra pour vous.
Mais! Si vous écrivez de moins en plus simplement, en utilisant des modules prêts à l'emploi et des solutions tierces, vous n'aurez pas à attendre et à espérer que la 0.12 viendra tout régler pour vous.
Merci pour le rapport! Vous avez parlé de l'infrastructure en tant que code et avez littéralement dit un mot sur les tests. Des tests sont-ils nécessaires dans les modules ? À qui revient cette responsabilité ? Dois-je l’écrire moi-même ou est-ce la responsabilité des modules ?
L'année prochaine sera remplie de rapports selon lesquels nous avons décidé de tout tester. Que tester est la plus grande question. Il existe de nombreuses dépendances, de nombreuses restrictions de la part des différents fournisseurs. Lorsque vous et moi parlons et que vous dites : « J'ai besoin de tests », alors je demande : « Que allez-vous tester ? Vous dites que vous ferez des tests dans votre région. Ensuite, je dis que cela ne fonctionne pas dans ma région. Autrement dit, nous ne pourrons même pas nous mettre d’accord sur ce point. Sans compter qu'il y a beaucoup de problèmes techniques. Autrement dit, comment rédiger ces tests pour qu'ils soient adéquats.
Je recherche activement ce sujet, c'est-à-dire comment générer automatiquement des tests basés sur l'infrastructure que vous avez écrite. Autrement dit, si vous avez écrit ce code, je dois l'exécuter, sur cette base, je peux créer des tests.
est l'une des bibliothèques les plus fréquemment mentionnées qui vous permet d'écrire des tests d'intégration pour Terraform. C'est l'un des utilitaires. Je préfère le type DSL, par exemple rspec.
Anton, merci pour le rapport ! Je m'appelle Valéry. Permettez-moi de poser une petite question philosophique. Il y a, sous condition, approvisionnement, il y a déploiement. Le provisionnement crée mon infrastructure, lors du déploiement, nous la remplissons avec quelque chose d'utile, par exemple des serveurs, des applications, etc. Et c'est dans ma tête que Terraform est davantage destiné au provisionnement, et Ansible est davantage destiné au déploiement, car Ansible est également destiné à l'infrastructure physique. vous permet d'installer nginx, Postgres. Mais en même temps, Ansible semble permettre le provisionnement, par exemple, de ressources Amazon ou Google. Mais Terraform permet également de déployer certains logiciels grâce à ses modules. De votre point de vue, existe-t-il une sorte de frontière entre Terraform et Ansible, où et quoi est-il préférable d'utiliser ? Ou, par exemple, pensez-vous qu'Ansible est déjà une poubelle, vous devriez essayer d'utiliser Terraform pour tout ?
Bonne question, Valéry. Je pense que Terraform n'a pas changé en termes de finalité depuis 2014. Il a été créé pour les infrastructures et est mort pour les infrastructures. Nous avions et aurons encore besoin de gestion de configuration Ansible. Le défi est qu’il existe des données utilisateur dans launch_configuration. Et là, vous tirez Ansible, etc. C'est la distinction standard que j'aime le plus.
Si nous parlons d'une belle infrastructure, alors il existe des utilitaires comme Packer qui collectent cette image. Ensuite, Terraform utilise la source de données pour trouver cette image et mettre à jour sa launch_configuration. Autrement dit, de cette manière, le pipeline consiste à extraire d'abord Tracker, puis à extraire Terraform. Et si la construction se produit, alors un nouveau changement se produit.
Bonjour! Merci pour le rapport! Je m'appelle Misha, société RBS. Vous pouvez appeler Ansible via le fournisseur lors de la création d'une ressource. Ansible propose également un sujet appelé inventaire dynamique. Et vous pouvez d'abord appeler Terraform, puis appeler Ansible, qui prendra les ressources de l'état et l'exécutera. Ce qui est mieux?
Les gens utilisent les deux avec le même succès. Il me semble que l'inventaire dynamique dans Ansible est une chose pratique, si nous ne parlons pas de groupe de mise à l'échelle automatique. Parce que dans le groupe de mise à l'échelle automatique, nous disposons déjà de notre propre boîte à outils, appelée launch_configuration. Dans launch_configuration, nous enregistrons tout ce qui doit être lancé lorsque nous créons une nouvelle ressource. Par conséquent, avec Amazon, utiliser l'inventaire dynamique et lire le fichier Terraform ts, à mon avis, est excessif. Et si vous utilisez d'autres outils où il n'y a pas de concept de « groupe d'autoscaling », par exemple, vous utilisez DigitalOcean ou un autre fournisseur où il n'y a pas de groupe d'autoscaling, alors vous devrez extraire manuellement l'API, rechercher des adresses IP, créer un fichier d'inventaire dynamique, et Ansible le parcourra déjà. Autrement dit, pour Amazon, il existe launch_configuration et pour tout le reste, il existe un inventaire dynamique.
Source: habr.com