{"id":52367,"date":"2019-11-07T00:00:00","date_gmt":"2019-11-06T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/pereshel-s-terraform-na-cloudformation-i-pozhalel"},"modified":"2020-02-18T14:00:04","modified_gmt":"2020-02-18T11:00:04","slug":"pereshel-s-terraform-na-cloudformation-i-pozhalel","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/pereshel-s-terraform-na-cloudformation-i-pozhalel","title":{"rendered":"Je suis pass\u00e9 de Terraform \u00e0 CloudFormation - et j'ai regrett\u00e9","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Repr\u00e9senter l'infrastructure sous forme de code dans un format texte r\u00e9p\u00e9table est une bonne pratique simple pour les syst\u00e8mes, avec laquelle on n'a pas besoin d'embrouiller. Cette pratique est d\u00e9sign\u00e9e par le terme \u2014 Infrastructure as Code<\/a><\/noindex>, et jusqu'\u00e0 pr\u00e9sent, pour sa mise en \u0153uvre, surtout sur AWS, il existe deux outils populaires : Terraform<\/a><\/noindex> et CloudFormation<\/a><\/noindex>.<\/p>\n

<\/p>\n

\"Je
\nJe compare l'exp\u00e9rience avec Terraform et CloudFormation<\/em><\/p>\n

<\/p>\n

Avant d'arriver chez Twitch<\/a><\/noindex> (aussi connu sous le nom de Amazon Jr.<\/a><\/noindex>) j'ai travaill\u00e9 dans une startup<\/a><\/noindex> et j'ai utilis\u00e9 Terraform pendant environ trois ans. \u00c0 mon nouveau poste, j'ai \u00e9galement largement utilis\u00e9 Terraform, puis l'entreprise a pouss\u00e9 pour la transition vers tout ce qui est Amazon, y compris CloudFormation. J'ai travaill\u00e9 dur pour d\u00e9velopper les meilleures pratiques pour les deux, et j'ai utilis\u00e9 les deux outils dans des processus de travail tr\u00e8s complexes \u00e0 l'\u00e9chelle de l'organisation. Plus tard, apr\u00e8s avoir r\u00e9fl\u00e9chi aux implications du passage de Terraform \u00e0 CloudFormation, j'ai r\u00e9alis\u00e9 que Terraform est probablement le meilleur choix pour une organisation.<\/p>\n

<\/a><\/noindex><\/p>\n

Terraform Horrible<\/h2>\n

<\/p>\n

Version b\u00eata du logiciel<\/h3>\n

<\/p>\n

Terraform n'a m\u00eame pas encore atteint la version 1.0, et c'est une raison valable de ne pas l'utiliser. Depuis que je l'ai essay\u00e9 pour la premi\u00e8re fois, il a beaucoup chang\u00e9, mais \u00e0 l'\u00e9poque, terraform apply<\/code> Il tombait souvent en panne apr\u00e8s quelques mises \u00e0 jour ou simplement apr\u00e8s quelques ann\u00e9es d'utilisation. Je dirais que \u00ab maintenant c'est diff\u00e9rent \u00bb, mais\u2026 tout le monde dit \u00e7a, non ? Il y a des changements incompatibles avec les versions pr\u00e9c\u00e9dentes, m\u00eame s'ils sont justifi\u00e9s, et j'ai m\u00eame l'impression que la syntaxe et les abstractions de stockage de ressources sont maintenant \u00e0 la hauteur. L'outil semble vraiment s'\u00eatre am\u00e9lior\u00e9, mais\u2026 :-0<\/p>\n

<\/p>\n

D'un autre c\u00f4t\u00e9, AWS a bien fait, en maintenant la compatibilit\u00e9 avec les versions pr\u00e9c\u00e9dentes. C'est probablement parce que leurs services sont souvent soigneusement test\u00e9s en interne avant d'\u00eatre publi\u00e9s sous un nouveau nom. Donc, dire qu'\u00ab ils ont bien travaill\u00e9 \u00bb est encore une faible expression. Maintenir la compatibilit\u00e9 avec les versions pr\u00e9c\u00e9dentes de l'API pour un syst\u00e8me aussi variable et complexe qu'AWS est incroyablement difficile. Quiconque a d\u00fb g\u00e9rer des API publiques utilis\u00e9es aussi largement sait \u00e0 quel point cela peut \u00eatre compliqu\u00e9 au fil des ans. Quant au comportement de CloudFormation, il n'a jamais chang\u00e9 au fil des ans, autant que je me souvienne.<\/p>\n

<\/p>\n

Salut, pied... c'est une balle<\/h3>\n

<\/p>\n

\u00c0 ma connaissance, supprimer une ressource externe<\/strong> Il est impossible d'importer une stack CloudFormation dans sa propre stack CF. C'est \u00e0 peu pr\u00e8s la m\u00eame chose avec Terraform. Il permet d'importer des ressources existantes dans sa propre stack. C'est une fonctionnalit\u00e9, on peut dire, impressionnante, mais avec un grand pouvoir vient une grande responsabilit\u00e9. Il suffit d'ajouter une ressource \u00e0 la stack et, tant que vous travaillez avec votre stack, cette ressource ne peut pas \u00eatre supprim\u00e9e ou modifi\u00e9e. Une fois, cela a eu des cons\u00e9quences. Un jour, sur le site de Twitch, quelqu'un, sans mauvaise intention, a accidentellement import\u00e9 le groupe de s\u00e9curit\u00e9 AWS de quelqu'un d'autre dans sa propre stack Terraform. Il a entr\u00e9 quelques commandes et... le groupe de s\u00e9curit\u00e9 (avec le trafic entrant) a disparu.<\/p>\n

<\/p>\n

Terraform le Grand<\/h2>\n

<\/p>\n

R\u00e9cup\u00e9ration \u00e0 partir d'\u00e9tats incomplets<\/h3>\n

<\/p>\n

Parfois, CloudFormation ne peut pas passer compl\u00e8tement d'un \u00e9tat \u00e0 un autre. Dans ce cas, il essaiera de revenir \u00e0 l'\u00e9tat pr\u00e9c\u00e9dent. Malheureusement, ce n'est pas toujours possible. D\u00e9boguer ce qui en r\u00e9sulte peut s'av\u00e9rer assez angoissant - on ne sait jamais si CloudFormation va appr\u00e9cier qu'on le modifie, m\u00eame pour le r\u00e9parer. Et il ne sait pas vraiment comment revenir \u00e0 l'\u00e9tat pr\u00e9c\u00e9dent et attend par d\u00e9faut pendant des heures un miracle.<\/p>\n

<\/p>\n

Terraform, en revanche, a tendance \u00e0 se r\u00e9tablir apr\u00e8s des transitions rat\u00e9es de mani\u00e8re beaucoup plus \u00e9l\u00e9gante et propose des outils de d\u00e9bogage avanc\u00e9s.<\/p>\n

<\/p>\n

Des changements plus clairs dans l'\u00e9tat du document<\/h3>\n

<\/p>\n

\u00ab Alors, l'\u00e9quilibreur de charge, tu \u00e9volues. Mais comment ? \u00bb<\/p>\n

\u2014 un ing\u00e9nieur inquiet, pr\u00eat \u00e0 appuyer sur le bouton \u00ab accepter \u00bb.<\/p><\/blockquote>\n

Parfois, j'ai besoin d'effectuer certaines manipulations avec l'\u00e9quilibreur de charge dans la stack CloudFormation - par exemple, ajouter un num\u00e9ro de port ou modifier le groupe de s\u00e9curit\u00e9. Les modifications de CloudFormation sont faiblement affich\u00e9es. \u00c0 chaque fois, je v\u00e9rifie le fichier yaml \u00e0 plusieurs reprises, pour m'assurer que je n'ai rien supprim\u00e9 d'important et que je n'ai rien ajout\u00e9 de superflu.<\/p>\n

<\/p>\n

Terraform est, \u00e0 cet \u00e9gard, beaucoup plus transparent. Parfois, il est m\u00eame trop transparent (lire : aga\u00e7ant). Heureusement, la derni\u00e8re version a inclus une meilleure visualisation des modifications - on peut d\u00e9sormais voir exactement ce qui change.<\/p>\n

<\/p>\n

Flexibilit\u00e9<\/h3>\n

<\/p>\n

\u00c9crivez le logiciel \u00e0 l'envers.<\/p><\/blockquote>\n

Pour \u00eatre franc, la caract\u00e9ristique la plus importante d'un logiciel durable est sa capacit\u00e9 \u00e0 s'adapter aux changements. \u00c9crivez toujours un logiciel \u00e0 l'envers. C'est souvent l\u00e0 que je me suis plant\u00e9, en prenant un service \u00ab simple \u00bb, puis en essayant de tout int\u00e9grer dans un unique stack CloudFormation ou Terraform. Et bien s\u00fbr, des mois plus tard, je d\u00e9couvrais que je m'\u00e9tais compl\u00e8tement tromp\u00e9 et que le service n'\u00e9tait en r\u00e9alit\u00e9 pas si simple ! Et l\u00e0, je dois trouver un moyen de d\u00e9composer le grand stack en petites parties. Lorsque vous travaillez avec CloudFormation, cela n'est possible que si vous recr\u00e9ez d'abord le stack existant, ce que je ne fais pas avec mes bases de donn\u00e9es. Terraform, en revanche, permettait de d\u00e9cortiquer le stack et de le diviser en parties plus compr\u00e9hensibles.<\/p>\n

<\/p>\n

Modules dans git<\/h3>\n

<\/p>\n

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\u00e9p\u00f4t git et y acc\u00e9der en utilisant un contr\u00f4le de version s\u00e9mantique. Quiconque a acc\u00e8s \u00e0 ce d\u00e9p\u00f4t peut r\u00e9utiliser le code commun. L'\u00e9quivalent pour CloudFormation est S3, mais il n'a pas les m\u00eames avantages, et il n'y a aucune raison de renoncer \u00e0 git au profit de S3.<\/p>\n

<\/p>\n

L'organisation a grandi et la capacit\u00e9 de partager des stacks communs a atteint un niveau critique. Avec Terraform, tout cela se fait facilement et naturellement, tandis que CloudFormation vous obligera \u00e0 sauter \u00e0 travers des cerceaux avant que quelque chose de similaire ne fonctionne.<\/p>\n

<\/p>\n

Operations as code<\/h3>\n

<\/p>\n

\u00ab Scriptage et c'est tout. \u00bb<\/p>\n

\u2014 un ing\u00e9nieur trois ans avant d'inventer le v\u00e9lo Terraform.<\/p><\/blockquote>\n

Quand il s'agit de d\u00e9veloppement logiciel, Go ou un programme en Java n'est pas juste du code.<\/p>\n

<\/p>\n

\"Je
\nCode as Code<\/em><\/p>\n

<\/p>\n

Il y a aussi l'infrastructure sur laquelle il fonctionne.<\/p>\n

<\/p>\n

\"Je
\nInfrastructure as Code<\/em><\/p>\n

<\/p>\n

Mais d'o\u00f9 vient-elle ? Comment la surveiller ? O\u00f9 r\u00e9side votre code ? Les d\u00e9veloppeurs doivent-ils obtenir l'autorisation d'acc\u00e8s ?<\/p>\n

<\/p>\n

\"Je
\nOperations as Code<\/em><\/p>\n

<\/p>\n

\u00catre d\u00e9veloppeur software, ce n'est pas juste \u00e9crire du code.<\/p><\/blockquote>\n

Pas que AWS : vous utilisez s\u00fbrement les services d'autres fournisseurs. SignalFx, PagerDuty ou Github. Peut-\u00eatre 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 \u00e9galement importantes pour tout ce qui concerne le logiciel.<\/p>\n

<\/p>\n

Lorsque je travaillais chez Twitch, nous acc\u00e9l\u00e9rions les services au sein de syst\u00e8mes int\u00e9gr\u00e9s mixtes et des syst\u00e8mes AWS d'Amazon. Nous produisions et maintenions de nombreux microservices, augmentant ainsi les co\u00fbts d'exploitation. Les discussions se d\u00e9roulaient g\u00e9n\u00e9ralement comme suit :<\/p>\n

<\/p>\n