Représenter l'infrastructure sous forme de code dans un format texte répétable est une bonne pratique simple pour les systèmes, avec laquelle on n'a pas besoin d'embrouiller. Cette pratique est désignée par le terme — , et jusqu'à présent, pour sa mise en œuvre, surtout sur AWS, il existe deux outils populaires : et .
Je compare l'expérience avec Terraform et CloudFormation
Avant d'arriver chez (aussi connu sous le nom de ) j'ai travaillé et j'ai utilisé Terraform pendant environ trois ans. À mon nouveau poste, j'ai également largement utilisé Terraform, puis l'entreprise a poussé pour la transition vers tout ce qui est Amazon, y compris CloudFormation. J'ai travaillé dur pour développer les meilleures pratiques pour les deux, et j'ai utilisé les deux outils dans des processus de travail très complexes à l'échelle de l'organisation. Plus tard, après avoir réfléchi aux implications du passage de Terraform à CloudFormation, j'ai réalisé que Terraform est probablement le meilleur choix pour une organisation.
Terraform Horrible
Version bêta du logiciel
Terraform n'a même pas encore atteint la version 1.0, et c'est une raison valable de ne pas l'utiliser. Depuis que je l'ai essayé pour la première fois, il a beaucoup changé, mais à l'époque, terraform apply il échouait souvent après quelques mises à jour ou simplement après quelques années d'utilisation. Je dirais que 'maintenant, tout est différent', mais... tout le monde dit ça, n'est-ce pas ? Il y a des changements incompatibles avec les versions précédentes, bien qu'ils soient justifiés, et même le sentiment que la syntaxe et les abstractions des ressources sont maintenant adéquates. L'outil semble vraiment s'être amélioré, mais… :-0
D'un autre côté, AWS a bien travaillé pour maintenir la compatibilité avec les versions précédentes. Probablement parce que leurs services sont souvent bien testés en interne avant d'être publiés sous un nouveau nom. Donc, 'bien travaillé' est un euphémisme. Maintenir la compatibilité avec les versions antérieures de l'API pour un système aussi varié et complexe qu'AWS est incroyablement difficile. Quiconque a dû prendre soin d'API publiques largement utilisées doit comprendre à quel point c'est difficile de le faire pendant tant d'années. Quant au comportement de CloudFormation, je n'ai jamais vu de changements au fil des ans.
Salut, pied... c'est une balle
À ma connaissance, supprimer une ressource externe Il est impossible d'importer une stack CloudFormation dans sa propre stack CF. C'est à peu près la même chose avec Terraform. Il permet d'importer des ressources existantes dans sa propre stack. C'est une fonctionnalité, on peut dire, impressionnante, mais avec un grand pouvoir vient une grande responsabilité. Il suffit d'ajouter une ressource à la stack et, tant que vous travaillez avec votre stack, cette ressource ne peut pas être supprimée ou modifiée. Une fois, cela a eu des conséquences. Un jour, sur le site de Twitch, quelqu'un, sans mauvaise intention, a accidentellement importé le groupe de sécurité AWS de quelqu'un d'autre dans sa propre stack Terraform. Il a entré quelques commandes et... le groupe de sécurité (avec le trafic entrant) a disparu.
Terraform le Grand
Récupération à partir d'états incomplets
Parfois, CloudFormation ne peut pas passer complètement d'un état à un autre. Dans ce cas, il essaiera de revenir à l'état précédent. Malheureusement, ce n'est pas toujours possible. Déboguer ce qui en résulte peut s'avérer assez angoissant - on ne sait jamais si CloudFormation va apprécier qu'on le modifie, même pour le réparer. Et il ne sait pas vraiment comment revenir à l'état précédent et attend par défaut pendant des heures un miracle.
Terraform, en revanche, a tendance à se rétablir après des transitions ratées de manière beaucoup plus élégante et propose des outils de débogage avancés.
Des changements plus clairs dans l'état du document
"D'accord, équilibreur de charge, tu changes. Mais comment ?"
- un ingénieur inquiet, prêt à appuyer sur le bouton "accepter".
Parfois, j'ai besoin d'effectuer certaines manipulations avec l'équilibreur de charge dans la stack CloudFormation - par exemple, ajouter un numéro de port ou modifier le groupe de sécurité. Les modifications de CloudFormation sont faiblement affichées. À chaque fois, je vérifie le fichier yaml à plusieurs reprises, pour m'assurer que je n'ai rien supprimé d'important et que je n'ai rien ajouté de superflu.
Terraform est, à cet égard, beaucoup plus transparent. Parfois, il est même trop transparent (lire : agaçant). Heureusement, la dernière version a inclus une meilleure visualisation des modifications - on peut désormais voir exactement ce qui change.
Flexibilité
Écrivez le logiciel à l'envers.
Pour être direct, la caractéristique la plus importante d'un logiciel durable est sa capacité à s'adapter aux changements. Écrivez toujours votre logiciel à l'envers. J'ai souvent fait l'erreur de choisir un service « simple », puis de m'efforcer de tout intégrer dans un seul stack CloudFormation ou Terraform. Et bien sûr, après des mois, il s'est révélé que j'avais mal compris, et que le service n'était en réalité pas si simple ! J'avais donc besoin de décomposer ce grand stack en petites composantes. Lorsque vous travaillez avec CloudFormation, c'est seulement possible si vous recréez d'abord le stack existant, ce que je ne fais pas avec mes bases de données. En revanche, Terraform me permettait de disséquer le stack et de le décomposer en parties plus compréhensibles.
Modules dans git
Partager du code Terraform entre de nombreux stacks est beaucoup plus simple que de le faire avec CloudFormation. Avec Terraform, vous pouvez mettre le code dans un dépôt git et y accéder en utilisant un contrôle de version sémantique. Quiconque a accès à ce dépôt peut réutiliser le code commun. L'équivalent pour CloudFormation est S3, mais il n'a pas les mêmes avantages, et il n'y a aucune raison de renoncer à git au profit de S3.
L'organisation a grandi et la capacité de partager des stacks communs a atteint un niveau critique. Avec Terraform, tout cela se fait facilement et naturellement, tandis que CloudFormation vous obligera à sauter à travers des cerceaux avant que quelque chose de similaire ne fonctionne.
Operations as code
« Script et c'est bon ».
— un ingénieur trois ans avant d'inventer le vélo Terraform.
Quand il s'agit de développement logiciel, Go ou un programme en Java n'est pas juste du code.
Code as Code
Il y a aussi l'infrastructure sur laquelle il fonctionne.
Infrastructure as Code
Mais d'où vient-elle ? Comment la surveiller ? Où réside votre code ? Les développeurs doivent-ils obtenir l'autorisation d'accès ?
Operations as Code
Être développeur software, ce n'est pas juste écrire du code.
Pas que AWS : vous utilisez sûrement les services d'autres fournisseurs. SignalFx, PagerDuty ou Github. Peut-être avez-vous un serveur Jenkins interne pour CI/CD ou un tableau de bord Grafana interne pour la surveillance. L'Infra as Code est choisi pour diverses raisons, et toutes sont également importantes pour tout ce qui concerne le logiciel.
Lorsque je travaillais chez Twitch, nous optimisions les services au sein de systèmes embarqués mixtes et des systèmes AWS d'Amazon. Nous développions et maintenions de nombreux microservices, ce qui augmentait les coûts d'exploitation. Les discussions se déroulaient à peu près comme ceci :
- Je: Mince, ça fait pas mal de mouvements pour faire démarrer un seul microservice. Je vais devoir utiliser cette chose pour créer un compte AWS (nous avions deux comptes pour microservice), puis celui-ci pour configurer les alertes, encore celui-ci pour le dépôt de code, et celui-là pour la liste des adresses e-mail, et puis celui-ci…
- Lead: On va le mettre sous script, c'est parti.
- Je: D'accord, mais le script va changer. Il faudra un moyen de vérifier que tous ces petits trucs d'Amazon sont à jour.
- Lead: Ça sonne bien. Et pour cela, on va écrire un script.
- Je: Super ! Et le script va probablement avoir besoin de paramètres. Est-ce qu'il peut les prendre ?
- Lead: Oui, il peut les prendre, il n'y a pas de souci !
- Je: Le processus peut changer, ce qui risque de faire perdre la rétrocompatibilité. Il va falloir un contrôle de version sémantique.
- Lead: Excellente idée !
- Je: Les outils peuvent être modifiés manuellement, dans l'interface utilisateur. Nous aurons besoin d'un moyen de vérifier et de corriger cela.
…3 ans plus tard :
- Lead: Et nous avons réussi à obtenir Terraform.
La morale de cette fable est la suivante : même si vous êtes immergés dans tout ce qui vient d'Amazon, vous utilisez quand même quelque chose qui ne vient pas d'AWS, et ces services ont un état qui utilise un langage pour la configuration pour synchroniser cet état.
CloudFormation lambda contre les modules git de Terraform
lambda est la solution de CloudFormation pour la logique utilisateur. Avec lambda, vous pouvez ou . Cette approche présente des complexités supplémentaires qui n'existent pas dans le contrôle de version sémantique des modules git de Terraform. Pour moi, le problème le plus pressant est devenu la gestion des autorisations pour toutes ces lambdas personnalisées (et cela représente des dizaines de comptes AWS). Un autre problème tout aussi important est le dilemme du « qu'est-ce qui est venu en premier — l'œuf ou la poule ? » : il était lié au code lambda. Cette fonction elle-même — à la fois infrastructure et code — nécessite également un suivi et des mises à jour. Le dernier clou dans le cercueil a été la difficulté d'une mise à jour sémantique des modifications du code lambda ; il fallait en plus s'assurer que les actions de la pile ne changent pas entre les exécutions sans commande explicite.
Je me souviens qu'un jour j'ai eu envie de créer un déploiement canari pour un environnement Elastic Beanstalk avec un équilibreur de charge classique. Le plus simple aurait été de faire un second déploiement pour EB à côté de l'environnement de production, en ajoutant une étape supplémentaire : en liant le groupe de déploiement canari évolutif automatiquement avec l'équilibreur de charge de l'environnement de production. Et puisque Terraform utilise , cela nécessitera 4 lignes de code supplémentaires dans Terraform. Lorsque j'ai demandé s'il n'y avait pas de solution comparable dans CloudFormation, on m'a indiqué tout un répertoire sur git avec un pipeline de déploiement et autres : tout ça juste pour ce que l'on pourrait faire avec 4 malheureuses lignes de code Terraform.
Il détecte mieux le drift
Assurez-vous que la réalité correspond aux attentes.
— c'est une fonction très puissante des opérations en tant que code, car elle permet de s'assurer que la réalité correspond aux attentes. Elle est disponible à la fois avec CloudFormation et avec Terraform. Mais au fur et à mesure que la pile de travail grandit, la recherche du drift dans CloudFormation produit de plus en plus de faux positifs.
Avec Terraform, vous disposez de hooks de cycle de vie beaucoup plus avancés pour la détection du drift. Par exemple, vous entrez la commande directement dans la définition de la tâche ECS, si vous souhaitez ignorer les modifications sur la définition d'une tâche particulière, sans ignorer pour autant les modifications de l'ensemble du déploiement ECS.
CDK et l'avenir de CloudFormation
CloudFormation est difficile à gérer à grande échelle, inter-infrastructure. Beaucoup de ces difficultés ont été reconnues, et l'outil a besoin de choses comme , une structure pour définir l'infrastructure cloud en code et la faire passer par AWS CloudFormation. Il sera intéressant de voir ce qui attend aws-cdk à l'avenir, mais il sera difficile pour lui de rivaliser avec les autres avantages de Terraform ; pour rattraper CloudFormation, des changements globaux seront nécessaires.
Pour que Terraform ne déçoive pas
C'est de l'« infrastructure en tant que CODE », et non « en tant que texte ».
Ma première impression de Terraform a été plutôt mauvaise. Je pense que je n'ai simplement pas compris l'approche. Presque tous les ingénieurs le perçoivent involontairement au départ comme un format texte à transformer en infrastructure souhaitée. NE FAITES PAS ÇA.
Les vérités évidentes d'un bon développement logiciel s'appliquent également à Terraform.
J'ai constaté que de nombreuses pratiques recommandées pour écrire un bon code sont ignorées dans Terraform. Vous avez passé des années à devenir un bon programmeur. Ne renoncez pas à cette expérience simplement parce que vous travaillez avec Terraform. Les vérités fondamentales du bon développement logiciel s'appliquent également à Terraform.
Comment pourrait-on coder sans documenter ?
J'ai rencontré d'énormes stacks Terraform complètement dépourvus de documentation. Comment peut-on écrire du code sur des pages entières — sans aucune documentation ? Ajoutez de la documentation expliquant votre code Terraform (l'accent ici est mis sur le mot « code »), pourquoi cette section est si importante, et ce que vous faites.
Comment peut-on déployer des services qui étaient autrefois une grande fonction main() ?
J'ai vu des stacks Terraform très complexes présentés sous la forme d'un seul module. Pourquoi ne déployons-nous pas les logiciels de cette façon ? Pourquoi décomposons-nous des grandes fonctions en plus petites ? Les mêmes réponses s'appliquent à Terraform. Si votre module est trop vaste, il faut le diviser en modules plus petits.
Votre entreprise n'utilise-t-elle pas de bibliothèques ?
J'ai observé des ingénieurs qui, en lançant un nouveau projet avec Terraform, copiaient et collait des morceaux énormes d'autres projets dans le leur, puis les retouchaient jusqu'à ce que cela fonctionne. Feriez-vous cela dans votre entreprise avec du code « en production » ? Nous n'utilisons pas des bibliothèques sans raison. Oui, mais que ferions-nous sans bibliothèques communes en général ?!
N'utilisez-vous pas PEP8 ou gofmt ?
Dans la plupart des langages, il existe un schéma de formatage standard accepté. En Python, c'est PEP8. En Go — gofmt. Terraform a le sien : terraform fmt. Utilisez-le à votre guise !
Utiliserez-vous React sans connaître JavaScript ?
Les modules Terraform peuvent simplifier une certaine partie de l'infrastructure complexe que vous créez, mais cela ne signifie pas que vous pouvez l'utiliser sans comprendre les ressources. Voulez-vous utiliser correctement Terraform sans comprendre ? Vous êtes condamné : le temps va passer et vous n'apprendrez jamais Terraform.
Codez-vous des singletons, ou injectez-vous des dépendances ?
L'injection de dépendances est une pratique reconnue comme la meilleure pour le développement logiciel, souvent privilégiée par les singletons. Comment cela peut-il être utile dans Terraform ? J'ai rencontré des modules Terraform qui dépendent d'un état distant. Au lieu d'écrire des modules qui extraient de cet état, écrivez un module qui prend des paramètres. Ensuite, transmettez ces paramètres au module.
Vos bibliothèques réalisent-elles dix choses bien ou une seule - mais parfaitement ?
Les bibliothèques qui se concentrent sur une seule tâche, qu'elles accomplissent à la perfection, fonctionnent le mieux. Au lieu d'écrire de grands modules Terraform qui tentent de tout faire à la fois, décomposez-les en parties qui effectuent chacune une tâche spécifique avec excellence. Ensuite, combinez-les comme il faut.
Comment apportez-vous des modifications aux bibliothèques sans rétrocompatibilité ?
Un module Terraform commun, tout comme une bibliothèque traditionnelle, doit informer ses utilisateurs des changements sans rétrocompatibilité. Lorsque des modifications surviennent dans les bibliothèques, c'est frustrant, et il en va de même lorsque des changements sans rétrocompatibilité sont effectués dans les modules Terraform. Il est recommandé d'appliquer des tags git et de la semver lors de l'utilisation des modules Terraform.
Votre service de production tourne sur votre ordinateur portable ou dans un centre de données ?
Hashicorp propose des outils comme pour exécuter votre terraform. Ces services centralisés facilitent la gestion, l'audit et l'approbation des modifications terraform.
N'écrivez-vous pas de tests ?
Les ingénieurs reconnaissent qu'il est nécessaire de tester le code, mais souvent, ils négligent les vérifications en travaillant avec Terraform. Pour l'infrastructure, cela peut entraîner des problèmes sournois. Je recommande de « tester » ou de « créer des exemples » de stacks avec des modules qui peuvent être déployés correctement pour vérification lors de CI/CD.
Terraform et microservices
La vie et la mort des entreprises de microservices dépendent de la rapidité, de la mise à jour et de la destruction de nouveaux stacks de microservices.
Le principal inconvénient commun associé aux architectures de microservices, dont on ne peut pas se débarrasser, concerne le travail, et non le code. Si vous percevez Terraform uniquement comme un moyen d'automatiser le côté infrastructure des architectures de microservices, vous vous privez des véritables avantages de ce système. Maintenant déjà, .
Source : habr.com
