Représenter l'infrastructure sous forme de code dans un format texte reproductible est une bonne pratique simple pour les systèmes qui ne nécessitent pas de manipuler des souris. Cette pratique a un nom - , et jusqu'à présent, il existe deux outils populaires pour l'implémenter, notamment dans AWS : и .
Comparaison de l'expérience avec Terraform et CloudFormation
Avant de venir à (Aka ) J'ai travaillé et a utilisé Terraform pendant trois ans. Dans mon nouvel endroit, j'ai également utilisé Terraform de toutes mes forces, puis l'entreprise a poussé la transition vers tout ce qui est à la Amazon, y compris CloudFormation. J'ai développé avec diligence les meilleures pratiques pour les deux et j'ai utilisé les deux outils dans des flux de travail très complexes à l'échelle de l'organisation. Plus tard, après avoir soigneusement pesé les implications de la migration de Terraform vers CloudFormation, je suis devenu convaincu que Terraform était probablement le meilleur choix pour l'organisation.
Terraforme Horrible
Logiciel bêta
Terraform n'a même pas encore publié la version 1.0, ce qui est une bonne raison pour ne pas l'utiliser. Cela a beaucoup changé depuis que je l'ai essayé moi-même, mais à l'époque terraform apply souvent en panne après plusieurs mises à jour ou simplement après quelques années d'utilisation. Je dirais que « tout est différent maintenant », mais... c'est ce que tout le monde semble dire, non ? Certains changements sont incompatibles avec les versions précédentes, bien qu'ils soient appropriés, et il semble même que la syntaxe et les abstractions des magasins de ressources soient désormais ce dont nous avons besoin. L'instrument semble s'être vraiment amélioré, mais... :-0
D'un autre côté, AWS a fait du bon travail en maintenant la rétrocompatibilité. Cela est probablement dû au fait que leurs services sont souvent testés de manière approfondie au sein de l'organisation et ensuite seulement, renommés, sont publiés. Donc « ils ont fait de gros efforts » est un euphémisme. Maintenir la compatibilité ascendante avec les API pour un système aussi varié et complexe qu'AWS est incroyablement difficile. Quiconque a dû gérer des API publiques aussi largement utilisées doit comprendre à quel point il est difficile de le faire pendant tant d'années. Mais le comportement de CloudFormation, dans ma mémoire, n'a jamais changé au fil des années.
Rencontrez la jambe... c'est une balle
Pour autant que je sache, supprimez la ressource outsider La pile CloudFormation à partir de votre pile CF n'est pas possible. La même chose est vraie avec Terraform. Il vous permet d'importer des ressources existantes dans votre pile. La fonction peut être considérée comme étonnante, mais une grande puissance implique de grandes responsabilités. Il vous suffit d'ajouter une ressource à la pile, et pendant que vous travaillez avec votre pile, vous ne pouvez pas supprimer ou modifier cette ressource. Un jour, ça s’est retourné contre moi. Un jour sur Twitch, quelqu'un a accidentellement importé le groupe de sécurité AWS de quelqu'un d'autre dans sa propre pile Terraform sans faire de mal. J'ai entré plusieurs commandes et... le groupe de sécurité (ainsi que le trafic entrant) a disparu.
Terraforme génial
Récupération à partir d'états incomplets
Parfois, CloudFormation ne parvient pas à passer complètement d'un état à un autre. En même temps, il tentera de revenir au précédent. C'est dommage que cela ne soit pas toujours réalisable. Il peut être assez effrayant de déboguer ce qui s'est passé plus tard - on ne sait jamais si CloudFormation sera content qu'il soit piraté - même juste pour le réparer. Qu'il soit ou non possible de revenir à l'état antérieur, il ne sait vraiment pas comment le déterminer et, par défaut, reste suspendu pendant des heures en attendant un miracle.
Terraform, en revanche, a tendance à récupérer beaucoup plus facilement des transitions échouées et propose des outils de débogage avancés.
Des changements plus clairs dans l’état du document
« D'accord, équilibreur de charge, vous changez. Mais comment?"
—ingénieur anxieux, prêt à appuyer sur le bouton « accepter ».
Parfois, je dois effectuer quelques manipulations avec l'équilibreur de charge dans la pile CloudFormation, comme ajouter un numéro de port ou modifier un groupe de sécurité. ClouFormation affiche mal les changements. Moi, sur des épingles et des aiguilles, je revérifie le fichier yaml dix fois pour m'assurer que je n'ai rien effacé de nécessaire et que je n'ai rien ajouté d'inutile.
Terraform est beaucoup plus transparent à cet égard. Parfois, il est même trop transparent (lire : ennuyeux). Heureusement, la dernière version inclut un affichage amélioré des modifications afin que vous puissiez désormais voir exactement ce qui change.
Flexibilité
Écrivez le logiciel à l’envers.
Pour parler franchement, la caractéristique la plus importante d’un logiciel à long terme est la capacité de s’adapter au changement. Écrivez n’importe quel logiciel à l’envers. Le plus souvent, j'ai commis des erreurs en prenant un service « simple », puis en commençant à tout regrouper dans une seule pile CloudFormation ou Terraform. Et bien sûr, des mois plus tard, il s’est révélé que j’avais tout mal compris, et que le service n’était en fait pas simple ! Et maintenant, je dois d'une manière ou d'une autre diviser une grande pile en petits composants. Lorsque vous travaillez avec CloudFormation, cela ne peut être fait qu'en recréant d'abord la pile existante, et je ne le fais pas avec mes bases de données. Terraform, en revanche, a permis de disséquer la pile et de la diviser en parties plus petites plus compréhensibles.
Modules dans Git
Le partage de code Terraform sur plusieurs piles est beaucoup plus simple que le partage de code CloudFormation. Avec Terraform, vous pouvez placer votre code dans un référentiel git et y accéder à l'aide du contrôle de version sémantique. Toute personne ayant accès à ce référentiel peut réutiliser le code partagé. L'équivalent de CloudFormation est S3, mais il n'a pas les mêmes avantages, et il n'y a aucune raison pour que nous abandonnions git au profit de S3.
L'organisation s'est développée et la capacité à partager des piles communes a atteint un niveau critique. Terraform rend tout cela simple et naturel, tandis que CloudFormation vous fera franchir des obstacles avant de pouvoir faire fonctionner quelque chose comme ça.
Opérations en tant que code
"Écrivons-le et d'accord."
—ingénieur 3 ans avant d'inventer le vélo Terraform.
Lorsqu'il s'agit de développement de logiciels, Go ou un programme Java n'est pas seulement du code.
Coder en tant que code
Il y a aussi l'infrastructure sur laquelle cela fonctionne.
L'infrastructure comme code
Mais d'où vient-elle ? Comment le surveiller ? Où réside votre code ? Les développeurs ont-ils besoin d’une autorisation d’accès ?
Opérations en tant que code
Être développeur de logiciels ne signifie pas seulement écrire du code.
AWS n'est pas le seul : vous faites probablement appel à d'autres fournisseurs. SignalFx, PagerDuty ou Github. Peut-être disposez-vous d'un serveur Jenkins interne pour CI/CD ou d'un tableau de bord Grafana interne pour la surveillance. Infra as Code est choisi pour différentes raisons, et chacune est tout aussi importante pour tout ce qui concerne les logiciels.
Lorsque je travaillais chez Twitch, nous avons accéléré les services au sein des systèmes mixtes intégrés et AWS d'Amazon. Nous avons produit et pris en charge de nombreux microservices, augmentant ainsi les coûts opérationnels. Les discussions se sont déroulées à peu près comme ceci :
- Я: Bon sang, ça fait beaucoup de gestes pour overclocker un microservice. Je vais devoir utiliser ces déchets pour créer un compte AWS (nous sommes allés sur 2 comptes sur microservice), puis celui-ci pour configurer des alertes, celui-ci pour un référentiel de code, et celui-ci pour une liste de diffusion, et puis celui-ci...
- Conduire: Écrivons-le et d'accord.
- Я: D'accord, mais le script lui-même va changer. Nous aurons besoin d'un moyen de vérifier que tous ces gadgets Amazon intégrés sont à jour.
- Conduire: Ça a l'air bien. Et nous écrirons un script pour cela.
- Я: Super! Et le script devra probablement encore définir des paramètres. Les acceptera-t-il ?
- Conduire: Laissez-le l'emmener partout où il va !
- Я: Le processus peut changer et la compatibilité ascendante sera perdue. Une sorte de contrôle de version sémantique sera nécessaire.
- Conduire: Bonne idée!
- Я: Les outils peuvent être modifiés manuellement, dans l'interface utilisateur. Nous aurons besoin d'un moyen de vérifier et de résoudre ce problème.
…3 années plus tard:
- Conduire: Et nous avons eu Terraform.
La morale de l'histoire est la suivante : même si vous éperdument dans tout ce qui concerne Amazon, vous utilisez toujours quelque chose qui ne vient pas d'AWS, et ces services ont un état qui utilise un langage de configuration pour maintenir cet état synchronisé.
CloudFormation lambda vs modules git terraform
lambda est la solution de CloudFormation au problème de logique personnalisée. Avec Lambda, vous pouvez ou . Cette approche introduit des complexités supplémentaires qui ne sont pas présentes dans la gestion des versions sémantiques des modules git de Terraform. Pour moi, le problème le plus urgent était de gérer les autorisations pour tous ces utilisateurs lambdas (et ce sont des dizaines de comptes AWS). Un autre problème important était celui de « qu’est-ce qui est arrivé en premier, la poule ou l’œuf ? » : il était lié au code lambda. Cette fonction elle-même est une infrastructure et du code, et elle nécessite elle-même une surveillance et des mises à jour. Le dernier clou du cercueil était la difficulté de mettre à jour sémantiquement les modifications du code lambda ; nous devions également nous assurer que les actions de pile sans commande directe ne changeaient pas entre les exécutions.
Je me souviens d'une fois, j'ai voulu créer un déploiement Canary pour l'environnement Elastic Beanstalk avec un équilibreur de charge classique. La chose la plus simple à faire serait d'effectuer un deuxième déploiement pour l'EB à côté de l'environnement de production, en allant encore plus loin : en combinant le groupe de déploiement Canary à mise à l'échelle automatique avec le LB de déploiement dans l'environnement de production. Et puisque Terraform utilise , cela nécessitera 4 lignes de code supplémentaires dans Terraform. Quand j'ai demandé s'il existait une solution comparable dans CloudFormation, ils m'ont indiqué un référentiel git complet avec un pipeline de déploiement et tout, le tout dans le but de quelque chose que de pauvres 4 lignes de code Terraform pourraient faire.
Il détecte mieux la dérive
Assurez-vous que la réalité correspond aux attentes.
est une fonctionnalité d'opérations en tant que code très puissante car elle permet de garantir que la réalité correspond aux attentes. Il est disponible avec CloudFormation et Terraform. Mais à mesure que la pile de production grandissait, la recherche de dérives dans CloudFormation produisait de plus en plus de fausses détections.
Avec Terraform, vous disposez de crochets de cycle de vie beaucoup plus avancés pour la détection des dérives. Par exemple, vous entrez la commande directement dans la définition de tâche ECS si vous souhaitez ignorer les modifications apportées à une définition de tâche spécifique sans ignorer les modifications apportées à l'ensemble de votre déploiement ECS.
CDK et l'avenir de CloudFormation
CloudFormation est difficile à gérer à grande échelle et entre infrastructures. Beaucoup de ces difficultés sont reconnues et l'outil a besoin de choses comme , un cadre permettant de définir l'infrastructure cloud dans le code et de l'exécuter via AWS CloudFormation. Il sera intéressant de voir ce que l'avenir réserve à aws-cdk, mais il aura du mal à rivaliser avec les autres atouts de Terraform ; pour mettre CloudFormation à jour, des changements globaux seront nécessaires.
Pour que Terraform ne déçoive pas
Il s’agit d’une « infrastructure en tant que code » et non « en tant que texte ».
Ma première impression de Terraform était plutôt mauvaise. Je pense que je n'ai tout simplement pas compris l'approche. Presque tous les ingénieurs le perçoivent involontairement comme un format de texte qui doit être converti en l'infrastructure souhaitée. NE LE FAITES PAS DE CETTE FAÇON.
Les truismes d'un bon développement logiciel s'appliquent également à Terraform.
J'ai vu de nombreuses pratiques adoptées pour créer un bon code ignorées dans Terraform. Vous avez étudié pendant des années pour devenir un bon programmeur. N'abandonnez pas cette expérience simplement parce que vous travaillez avec Terraform. Les truismes d'un bon développement logiciel s'appliquent à Terraform.
Comment le code peut-il ne pas être documenté ?
J'ai vu d'énormes piles Terraform sans aucune documentation. Comment pouvez-vous écrire du code dans des pages - sans aucune documentation ? Ajoutez une documentation qui explique votre code Terraform (accent mis sur le mot « code »), pourquoi cette section est si importante et ce que vous faites.
Comment pouvons-nous déployer des services qui étaient autrefois une grande fonction main() ?
J'ai vu des piles Terraform très complexes présentées comme un seul module. Pourquoi ne déployons-nous pas les logiciels de cette façon ? Pourquoi divisons-nous les grandes fonctions en fonctions plus petites ? Les mêmes réponses s'appliquent à Terraform. Si votre module est trop volumineux, vous devez le diviser en modules plus petits.
Votre entreprise n'utilise-t-elle pas de bibliothèques ?
J'ai vu comment des ingénieurs, lançant un nouveau projet à l'aide de Terraform, copiaient bêtement d'énormes morceaux d'autres projets dans le leur, puis les bricolaient jusqu'à ce qu'ils commencent à fonctionner. Travailleriez-vous ainsi avec le code « combat » dans votre entreprise ? Nous n'utilisons pas seulement les bibliothèques. Oui, mais où en sommes-nous sans bibliothèques partagées en principe ?!
N'utilisez-vous pas PEP8 ou gofmt ?
La plupart des langues ont un schéma de formatage standard accepté. En Python, c'est PEP8. Dans Go - gofmt. Terraform a les siens : terraform fmt. Profitez-en pour votre santé !
Utiliserez-vous React sans connaître JavaScript ?
Les modules Terraform peuvent simplifier certaines parties de l'infrastructure complexe que vous créez, mais cela ne signifie pas que vous ne pouvez pas du tout la bricoler. Vous souhaitez utiliser Terraform correctement sans comprendre les ressources ? Vous êtes condamné : le temps passera et vous ne maîtriserez jamais Terraform.
Codez-vous avec des singletons ou une injection de dépendances ?
L'injection de dépendances est une bonne pratique reconnue pour le développement de logiciels et est préférée aux singletons. En quoi est-ce utile dans Terraform ? J'ai vu des modules Terraform qui dépendent de l'état distant. Au lieu d'écrire des modules qui récupèrent l'état distant, écrivez un module qui prend des paramètres. Et puis transmettez ces paramètres au module.
Vos bibliothèques font-elles dix choses bien ou une chose géniale ?
Les bibliothèques qui fonctionnent le mieux sont celles qui se concentrent sur une tâche qu’elles accomplissent très bien. Au lieu d'écrire de gros modules Terraform qui essaient de tout faire en même temps, créez-en des parties qui font bien une chose. Et puis combinez-les selon vos besoins.
Comment apporter des modifications aux bibliothèques sans rétrocompatibilité ?
Un module Terraform commun, comme une bibliothèque classique, doit d'une manière ou d'une autre communiquer les modifications aux utilisateurs sans être rétrocompatible. C'est ennuyeux lorsque ces changements se produisent dans les bibliothèques, et c'est tout aussi ennuyeux lorsque des modifications non rétrocompatibles sont apportées aux modules Terraform. Il est recommandé d'utiliser les balises git et semver lors de l'utilisation des modules Terraform.
Votre service de production fonctionne-t-il sur votre ordinateur portable ou dans un centre de données ?
Hashicorp dispose d'outils comme pour exécuter votre terraform. Ces services centralisés facilitent la gestion, l'audit et l'approbation des modifications Terraform.
Vous n'écrivez pas de tests ?
Les ingénieurs reconnaissent que le code doit être testé, mais eux-mêmes oublient souvent les tests lorsqu'ils travaillent avec Terraform. Pour les infrastructures, c'est semé d'embûches. Mon conseil est de « tester » ou de « créer des exemples » de piles en utilisant des modules qui peuvent être déployés correctement pour les tests pendant CI/CD.
Terraform et microservices
La vie et la mort des entreprises de microservices dépendent de la rapidité, de l’innovation et de la perturbation des nouvelles piles de travail de microservices.
L’aspect négatif le plus courant associé aux architectures de microservices, et qui ne peut être éliminé, est lié au travail et non au code. Si vous considérez Terraform comme un simple moyen d'automatiser uniquement le côté infrastructure d'une architecture de microservices, vous passez à côté des véritables avantages du système. Maintenant c'est déjà .
Source: habr.com