{"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\/it\/blog\/administrirovanie\/pereshel-s-terraform-na-cloudformation-i-pozhalel","title":{"rendered":"Sono passato da Terraform a CloudFormation \u2014 e me ne sono pentito","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Rappresentare l'infrastruttura in codice in un formato testuale ripetibile \u00e8 una pratica migliore semplice che non richiede un mouse. Questa pratica \u00e8 stata battezzata come \u2014 Infrastructure as Code<\/a><\/noindex>, e al momento, per realizzarla, soprattutto in AWS, ci sono due strumenti popolari: Terraform<\/a><\/noindex> e CloudFormation<\/a><\/noindex>.<\/p>\n

<\/p>\n

\"Sono
\nConfronto l'esperienza di lavoro con Terraform e CloudFormation<\/em><\/p>\n

<\/p>\n

Prima di arrivare a Twitch<\/a><\/noindex> (ovvero Amazon Jr.<\/a><\/noindex>) ho lavorato in una startup<\/a><\/noindex> e per circa tre anni ho usato Terraform. Nel mio nuovo lavoro ho continuato a usare Terraform, ma poi l'azienda ha spinto per passare a tutto quanto a-lla Amazon, incluso CloudFormation. Ho lavorato duramente per sviluppare buone pratiche sia per l'uno che per l'altro, e ho utilizzato entrambi gli strumenti in processi lavorativi molto complessi su scala aziendale. In seguito, riflettendo sulle conseguenze del passaggio da Terraform a CloudFormation, mi sono reso conto che Terraform \u00e8 probabilmente la scelta migliore per un'organizzazione.<\/p>\n

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

Terraform Terribile<\/h2>\n

<\/p>\n

Versione Beta del software<\/h3>\n

<\/p>\n

Terraform non ha nemmeno ancora raggiunto la versione 1.0, e questo \u00e8 un motivo valido per non utilizzarlo. Da quando l'ho provato per la prima volta, \u00e8 cambiato molto, ma all'epoca terraform apply<\/code> spesso si rompono dopo alcuni aggiornamenti o semplicemente dopo un paio di anni di utilizzo. Direi che 'ora tutto \u00e8 cambiato', ma\u2026 cos\u00ec dicono tutti, vero? Ci sono modifiche non compatibili con le versioni precedenti, anche se sono appropriate, e ho addirittura la sensazione che la sintassi e le astrazioni degli archivi siano ora adeguate. Lo strumento sembra effettivamente essere migliorato, ma\u2026 :-0<\/p>\n

<\/p>\n

D'altra parte, AWS ha fatto un buon lavoro nel mantenere la compatibilit\u00e0 con le versioni precedenti. Probabilmente perch\u00e9 i loro servizi vengono spesso testati a fondo all'interno dell'organizzazione e solo successivamente, rinominati, pubblicati. Quindi, 'hanno fatto un buon lavoro' \u00e8 ancora un eufemismo. Mantenere la compatibilit\u00e0 con le versioni precedenti delle API per un sistema complesso e multi-variabile come AWS \u00e8 incredibilmente difficile. Chiunque abbia dovuto mantenere API pubbliche cos\u00ec diffuse dovrebbe capire quanto sia difficile farlo per tanti anni. E di CloudFormation, a memoria, non ho mai visto cambiamenti nel corso degli anni.<\/p>\n

<\/p>\n

Fai conoscenza, gamba\u2026 \u00e8 un proiettile<\/h3>\n

<\/p>\n

Per quanto ne so, eliminare una risorsa esterna<\/strong> Non \u00e8 possibile importare uno stack CloudFormation in un altro stack CF. La situazione \u00e8 simile con Terraform. Esso consente di importare risorse esistenti nel proprio stack. Una funzione, si pu\u00f2 dire, straordinaria, ma con grande potere arriva anche una grande responsabilit\u00e0. Non si pu\u00f2 semplicemente aggiungere una risorsa allo stack, e mentre si lavora con il proprio stack, non \u00e8 possibile eliminare o modificare quella risorsa. Una volta ci\u00f2 ha avuto delle conseguenze. Qualcuno su Twitch, senza intenzioni maligne, ha accidentalmente importato un gruppo di sicurezza AWS di qualcun altro nel proprio stack Terraform. Ha eseguito un paio di comandi e\u2026 il gruppo di sicurezza (insieme al traffico in ingresso) \u00e8 scomparso.<\/p>\n

<\/p>\n

Terraform Il Grande<\/h2>\n

<\/p>\n

Ripristino da stati incompleti<\/h3>\n

<\/p>\n

A volte CloudFormation non riesce a passare completamente da uno stato all'altro. In questo caso tenta di tornare indietro. Peccato che a volte non sia realizzabile. Debuggare ci\u00f2 che ne risulta pu\u00f2 essere un po' spaventoso: non si sa mai se CloudFormation sar\u00e0 contento di essere manomesso, anche se per ripararlo. E se riuscir\u00e0 a tornare allo stato precedente, non lo sa bene e di default rimane ore in attesa di un miracolo.<\/p>\n

<\/p>\n

Terraform, al contrario, tende a recuperare in modo pi\u00f9 elegante dopo passaggi non riusciti e offre strumenti di debug avanzati.<\/p>\n

<\/p>\n

Modifiche pi\u00f9 chiare negli stati del documento<\/h3>\n

<\/p>\n

'Va bene, bilanciatore di carico, ti stai evolvendo. Ma come?'<\/p>\n

\u2014 ingegnere preoccupato, pronto a premere il pulsante 'accetta'.<\/p><\/blockquote>\n

A volte devo fare alcune manovre con il bilanciatore di carico nello stack CloudFormation, come aggiungere un numero di porta o modificare il gruppo di sicurezza. CloudFormation visualizza le modifiche in modo poco chiaro. Io, sull'orlo di un attacco di nervi, controllo il file yaml almeno dieci volte per assicurarmi di non aver cancellato nulla di necessario e di non aver aggiunto nulla di superfluo.<\/p>\n

<\/p>\n

Terraform \u00e8 molto pi\u00f9 trasparente in questo senso. A volte \u00e8 addirittura troppo trasparente (leggi: irritante). Fortunatamente, nell'ultima versione \u00e8 stata inclusa una visualizzazione migliorata delle modifiche \u2014 ora \u00e8 chiaro cosa sta cambiando.<\/p>\n

<\/p>\n

Flessibilit\u00e0<\/h3>\n

<\/p>\n

Scrivi software al contrario.<\/p><\/blockquote>\n

Detto chiaramente, la caratteristica distintiva pi\u00f9 importante di un software a lungo termine \u00e8 la capacit\u00e0 di adattarsi ai cambiamenti. Qualsiasi software deve essere scritto al contrario. Mi sono spesso sbagliato prendendo un servizio 'semplice', per poi cercare di adattarlo all'interno di un unico stack CloudFormation o Terraform. E ovviamente, dopo mesi, emergeva che avevo frainteso tutto, e il servizio non era affatto semplice! E ora ho bisogno di suddividere in qualche modo un grande stack in parti pi\u00f9 piccole. Quando si lavora con CloudFormation, questo \u00e8 possibile solo ricreando preliminarmente lo stack esistente, e questo io, con i miei DB, non lo faccio. Terraform invece permetteva di sezionare lo stack e di scomporlo in parti pi\u00f9 comprensibili.<\/p>\n

<\/p>\n

Moduli in git<\/h3>\n

<\/p>\n

Condividere codice Terraform tra numerosi stack \u00e8 molto pi\u00f9 facile che con codice CloudFormation. Con Terraform puoi mettere il codice in un repository git e accedervi utilizzando il controllo versione semantico. Chiunque abbia accesso a questo repository pu\u00f2 riutilizzare il codice condiviso. L'equivalente in CloudFormation \u00e8 S3, ma non ha gli stessi vantaggi e non c'\u00e8 alcuna ragione per cui dovremmo rinunciare a git a favore di S3.<\/p>\n

<\/p>\n

L'organizzazione cresce e la capacit\u00e0 di condividere stack comuni ha raggiunto un livello critico. Con Terraform tutto ci\u00f2 avviene in modo facile e naturale, mentre CloudFormation ti costringer\u00e0 a saltare attraverso anelli prima che tu possa ottenere qualcosa di simile.<\/p>\n

<\/p>\n

Operazioni come codice<\/h3>\n

<\/p>\n

'Scriptiamo e va bene'.<\/p>\n

- ingegnere tre anni prima di inventare il 'ciclo' Terraform.<\/p><\/blockquote>\n

Quando si parla di sviluppo software, Go o un programma in Java non sono solo codice.<\/p>\n

<\/p>\n

\"Sono
\nCodice come codice<\/em><\/p>\n

<\/p>\n

Esiste anche l'infrastruttura su cui esso funziona.<\/p>\n

<\/p>\n

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

<\/p>\n

Ma da dove proviene? Come monitorarla? Dove risiede il tuo codice? I programmatori hanno bisogno di permessi per accedervi?<\/p>\n

<\/p>\n

\"Sono
\nOperazioni come codice<\/em><\/p>\n

<\/p>\n

Essere un sviluppatore di software non significa semplicemente scrivere codice.<\/p><\/blockquote>\n

Non \u00e8 solo AWS: sicuramente utilizzi anche i servizi di altri fornitori. SignalFx, PagerDuty o Github. Forse hai un server Jenkins interno per CI\/CD o un pannello di controllo Grafana interno per il monitoraggio. L'infra come codice viene scelto per diversi motivi, e ognuno \u00e8 ugualmente importante per tutto ci\u00f2 che riguarda il software.<\/p>\n

<\/p>\n

Quando lavoravo in Twitch, acceleravamo i servizi all'interno di sistemi embedded misti e dei sistemi AWS di Amazon. Creavamo e mantenevamo numerosi microservizi, aumentando i costi operativi. Le discussioni si tenevano pi\u00f9 o meno in questi termini:<\/p>\n

<\/p>\n