{"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":"

Presentare l'infrastruttura come codice in un formato di testo ripetibile \u00e8 una delle migliori pratiche per i sistemi che non richiedono un'interazione visiva. Questa pratica \u00e8 conosciuta come Infrastructure as Code<\/a><\/noindex>, e per implementarla, specialmente in AWS, ci sono due strumenti popolari: Terraform<\/a><\/noindex> e CloudFormation<\/a><\/noindex>.<\/p>\n

<\/p>\n

\"Sono
\nConfronto tra 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 utilizzato Terraform. Nel mio nuovo posto ho continuato a utilizzare Terraform, ma poi l'azienda ha spinto per una transizione verso tutto ci\u00f2 che era simile ad Amazon, incluso CloudFormation. Ho lavorato duramente per sviluppare le migliori pratiche per entrambi, utilizzando entrambi gli strumenti in processi lavorativi molto complessi su scala organizzativa. In seguito, riflettendo attentamente sulle implicazioni del passaggio da Terraform a CloudFormation, mi sono reso conto che Terraform \u00e8 probabilmente la scelta migliore per l'organizzazione.<\/p>\n

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

Terraform \u00e8 terribile<\/h2>\n

<\/p>\n

Beta software<\/h3>\n

<\/p>\n

Terraform non ha ancora rilasciato la versione 1.0, e questo \u00e8 un motivo valido per non usarlo. Da quando l'ho provato per la prima volta, \u00e8 molto cambiato, ma allora ancora terraform apply<\/code> spesso si rompe dopo alcuni aggiornamenti o semplicemente dopo un paio d'anni di utilizzo. Direi che \"adesso \u00e8 tutto diverso\", ma... cos\u00ec dicono tutti, giusto? Ci sono cambiamenti incompatibili con le versioni precedenti, anche se sono appropriati, e si ha quasi la sensazione che la sintassi e le astrazioni del repository siano ora ci\u00f2 che serviva. Lo strumento sembra essere davvero migliorato, ma...<\/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 testati accuratamente all'interno dell'organizzazione e solo successivamente pubblicati con un nuovo nome. Quindi, \"sta facendo bene\" \u00e8 ancora un modo per dire poco. Mantenere la compatibilit\u00e0 con le versioni precedenti dell'API per un sistema complesso e variegato come AWS \u00e8 incredibilmente difficile. Chiunque abbia dovuto mantenere API pubbliche utilizzate cos\u00ec ampiamente dovrebbe capire quanto sia difficile farlo per tanti anni. E il comportamento di CloudFormation, a mia memoria, non \u00e8 mai cambiato nel tempo.<\/p>\n

<\/p>\n

Ehi, piede\u2026 questa \u00e8 una pallottola<\/h3>\n

<\/p>\n

Per quanto ne so, rimuovere risorsa esterna<\/strong> \u00c8 impossibile importare uno stack CloudFormation nel proprio stack CF. La situazione \u00e8 simile con Terraform. Consente di importare risorse esistenti nel proprio stack. Questa funzione \u00e8, si pu\u00f2 dire, straordinaria, ma con grande potere arrivano anche grandi responsabilit\u00e0. Non si pu\u00f2 modificare o eliminare una risorsa una volta che \u00e8 stata inserita nello stack mentre si lavora sullo stesso. Una volta, \u00e8 successo qualcosa di simile. Qualcuno su Twitch, senza cattive intenzioni, ha accidentalmente importato un gruppo di sicurezza AWS nel proprio stack Terraform. Ha eseguito alcuni comandi e... il gruppo di sicurezza (insieme al traffico in entrata) \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 a un altro. Cercher\u00e0 di tornare allo stato precedente. Peccato che non sia sempre possibile. \u00c8 piuttosto preoccupante dover debugare quello che ne risulta: non si sa mai se CloudFormation sar\u00e0 contento di essere \u201chackerato\u201d \u2014 anche se per ripararlo. E non riesce nemmeno a determinare se sar\u00e0 possibile tornare allo stato precedente e, per default, rimane in attesa di un miracolo per ore.<\/p>\n

<\/p>\n

Terraform, al contrario, tende a riprendersi dopo transizioni fallite in modo pi\u00f9 elegante e offre un set di strumenti di debug avanzato.<\/p>\n

<\/p>\n

Cambiamenti pi\u00f9 chiari nello stato del documento<\/h3>\n

<\/p>\n

\"Va bene, bilanciatore di carico, tu ti cambi. Ma come?\"<\/p>\n

- un ingegnere preoccupato, pronto a premere il pulsante \"accettare\".<\/p><\/blockquote>\n

A volte ho bisogno di fare alcune manovre con il bilanciatore di carico nello stack CloudFormation \u2014 ad esempio, aggiungere un numero di porta o modificare il gruppo di sicurezza. Le modifiche in CloudFormation sono poco visibili. Io, come un nervoso, 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

In questo senso, Terraform \u00e8 molto pi\u00f9 trasparente. A volte \u00e8 persino troppo trasparente (leggi: fastidioso). Fortunatamente, l'ultima versione ha introdotto un miglioramento nella visualizzazione delle modifiche \u2014 ora \u00e8 chiaro cosa viene cambiato.<\/p>\n

<\/p>\n

Flessibilit\u00e0<\/h3>\n

<\/p>\n

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

Detto in modo diretto, la caratteristica distintiva pi\u00f9 importante di un software duraturo \u00e8 la capacit\u00e0 di adattarsi ai cambiamenti. Qualsiasi software, scrivetelo al contrario. Io di solito mi sono imbattuto nel problema di prendere un servizio \"semplice\" e poi provare a inglobarlo in un unico stack CloudFormation o Terraform. E naturalmente, dopo mesi, si scopriva che avevo capito tutto male e il servizio non era affatto semplice! E quindi avevo bisogno di qualche modo per suddividere un grande stack in piccole componenti. Quando lavori con CloudFormation, questo \u00e8 possibile solo ricostruendo prima lo stack esistente, cosa che io non faccio con i miei database. Terraform, invece, permetteva di disassemblare lo stack e segmentarlo in parti pi\u00f9 comprensibili.<\/p>\n

<\/p>\n

Moduli in git<\/h3>\n

<\/p>\n

Condividere il codice Terraform tra molteplici stack \u00e8 molto pi\u00f9 semplice rispetto al codice CloudFormation. Con Terraform \u00e8 possibile mettere il codice in un repository git e accedervi utilizzando il controllo versione semantico. Chiunque abbia accesso a quel repository pu\u00f2 riutilizzare il codice condiviso. L'equivalente in CloudFormation \u00e8 S3, ma non ha gli stessi vantaggi e non c'\u00e8 alcun motivo per cui dovremmo rinunciare al git in favore di S3.<\/p>\n

<\/p>\n

L'organizzazione \u00e8 cresciuta e la capacit\u00e0 di condividere stack comuni ha raggiunto un livello critico. Con Terraform tutto questo risulta facile e naturale, mentre CloudFormation richiede di saltare attraverso anelli prima che si possa avere qualcosa di simile.<\/p>\n

<\/p>\n

Operazioni come codice<\/h3>\n

<\/p>\n

\"Scripting e via cos\u00ec\".<\/p>\n

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

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

<\/p>\n

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

<\/p>\n

C'\u00e8 anche l'infrastruttura su cui funziona.<\/p>\n

<\/p>\n

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

<\/p>\n

Ma da dove viene? Come si monitora? Dove risiede il tuo codice? Serve l'autorizzazione degli sviluppatori per l'accesso?<\/p>\n

<\/p>\n

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

<\/p>\n

Essere uno sviluppatore software non significa solo scrivere codice.<\/p><\/blockquote>\n

Non \u00e8 solo AWS: sicuramente stai usando 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 as Code viene scelto per vari motivi, e ciascuno di essi \u00e8 altrettanto importante per tutto ci\u00f2 che riguarda il software.<\/p>\n

<\/p>\n

Quando lavoravo a Twitch, facevamo accelerare i servizi all'interno di sistemi ibridi e dei sistemi AWS di Amazon. Creavamo e gestivamo numerosi microservizi, aumentando i costi operativi. Le discussioni avvenivano pi\u00f9 o meno in questo modo:<\/p>\n

<\/p>\n