Presentare l'infrastruttura come codice in un formato di testo ripetibile è una delle migliori pratiche per i sistemi che non richiedono un'interazione visiva. Questa pratica è conosciuta come , e per implementarla, specialmente in AWS, ci sono due strumenti popolari: e .
Confronto tra Terraform e CloudFormation
Prima di arrivare a (ovvero ) ho lavorato 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ò 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 è probabilmente la scelta migliore per l'organizzazione.
Terraform è terribile
Beta software
Terraform non ha ancora rilasciato la versione 1.0, e questo è un motivo valido per non usarlo. Da quando l'ho provato per la prima volta, è molto cambiato, ma allora ancora terraform apply spesso si rompeva dopo alcuni aggiornamenti o semplicemente dopo un paio d'anni di utilizzo. Direi che "adesso è tutto diverso", ma... in effetti così dicono tutti, giusto? Ci sono cambiamenti che non sono compatibili con le versioni precedenti, anche se hanno senso, e c'è quasi la sensazione che la sintassi e le astrazioni delle risorse siano ora più adeguate. Lo strumento sembra veramente migliorato, ma… :-0
D'altro canto, AWS ha davvero fatto un buon lavoro nel mantenere la compatibilità con le versioni precedenti. Probabilmente perché i loro servizi vengono testati a fondo internamente e solo dopo, rinominati, vengono pubblicati. Quindi, dire che "hanno fatto bene" è un eufemismo. Mantenere la compatibilità con le versioni precedenti dell'API per un sistema così variegato e complesso come AWS è incredibilmente difficile. Chiunque abbia dovuto mantenere API pubbliche utilizzate così ampiamente, deve capire quanto sia complicato farlo per così tanto tempo. E il comportamento di CloudFormation, a mia memoria, non è mai cambiato nel corso degli anni.
Ehi, piede… questa è una pallottola
Per quanto ne so, rimuovere risorsa esterna стека CloudFormation из своего стека CF невозможно. Примерно так же дело обстоит и с Terraform. Он позволяет импортировать существующие ресурсы в свой стек. Функция, можно сказать, потрясающая, но с большой силой приходит и большая ответственность. Стоит только занести ресурс в стек и, пока ты работаешь со своим стеком, удалить или изменить этот ресурс нельзя. Однажды это аукнулось. Как-то на сайте Twitch кто-то, не замышляя ничего дурного, случайно импортировал чью-то группу безопасности AWS в свой собственный стек Terraform. Ввел несколько команд и… группа безопасности (вместе со входящим трафиком) исчезла.
Terraform Великий
Восстановление из неполных состояний
Иногда CloudFormation не может полностью перейти из одного состояния в другое. При этом он постарается вернуться к предыдущему. Жаль, это не всегда осуществимо. Отлаживать потом то, что получилось, бывает страшноватенько — никогда не знаешь, обрадуется ли CloudFormation, что его взламывают — пусть и для починки. А получится или нет вернуться к предыдущему состоянию, он толком определять не умеет и по умолчанию часами висит в ожидании чуда.
Terraform, al contrario, tende a riprendersi dopo transizioni fallite in modo più elegante e offre un set di strumenti di debug avanzato.
Cambiamenti più chiari nello stato del documento
«Va bene, bilanciatore di carico, stai cambiando. Ma come?»
— un ingegnere preoccupato, pronto a premere il pulsante 'accetta'.
A volte ho bisogno di fare alcune manovre con il bilanciatore di carico nello stack CloudFormation — 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.
In questo senso, Terraform è molto più trasparente. A volte è persino troppo trasparente (leggi: fastidioso). Fortunatamente, l'ultima versione ha introdotto un miglioramento nella visualizzazione delle modifiche — ora è chiaro cosa viene cambiato.
Flessibilità
Scrivi software al contrario.
Parlando chiaramente, la caratteristica più importante di un software durevole è la capacità di adattarsi ai cambiamenti. Qualsiasi software dovrebbe essere scritto a ritroso. Spesso mi sono trovato ad affrontare problemi pensando che un servizio "semplice" fosse sufficientemente facile, solo per poi cercare di includerlo in un unico stack CloudFormation o Terraform. E naturalmente, dopo mesi, emergeva che avevo capito tutto nel modo sbagliato, e il servizio non era affatto semplice! Così, avevo bisogno di smembrare un grande stack in componenti più piccoli. Quando si lavora con CloudFormation, questo è possibile solo ricreando preventivamente lo stack esistente, ma io, con i miei database, non faccio questo. Terraform, invece, consentiva di dissezionare lo stack e di dividerlo in parti più comprensibili.
Moduli in git
Condividere il codice Terraform tra molteplici stack è molto più semplice rispetto al codice CloudFormation. Con Terraform è possibile mettere il codice in un repository git e accedervi utilizzando il controllo versione semantico. Chiunque abbia accesso a quel repository può riutilizzare il codice condiviso. L'equivalente in CloudFormation è S3, ma non ha gli stessi vantaggi e non c'è alcun motivo per cui dovremmo rinunciare al git in favore di S3.
L'organizzazione è cresciuta e la capacità 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.
Operazioni come codice
«Facciamo tutto tramite script».
— un ingegnere tre anni prima di inventare il 'ciclo' Terraform.
Quando si tratta di sviluppo software, Go o un programma in Java non sono semplicemente codice.
Codice come codice
C'è anche l'infrastruttura su cui funziona.
Infrastructure as Code
Ma da dove viene? Come si monitora? Dove risiede il tuo codice? Serve l'autorizzazione degli sviluppatori per l'accesso?
Operazioni come codice
Essere uno sviluppatore software non significa solo scrivere codice.
Non è 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 è altrettanto importante per tutto ciò che riguarda il software.
Quando lavoravo in Twitch, acceleravamo i servizi all'interno di sistemi embedded misti e di AWS Amazon. Creavamo e gestivamo numerosi microservizi, aumentando i costi operativi. Le discussioni si svolgevano più o meno in questo modo:
- Io: Cavolo, troppe operazioni per far partire un solo microservizio. Dovrò usare questa cosa per creare un account AWS (stiamo puntando a 2 account su microservizio), poi questo — per impostare le notifiche, un altro — per il repository di codice, e questo — per la lista degli indirizzi email, e poi quest'altro...
- Lead: Scriptiamo e basta.
- Io: D'accordo, ma lo script cambierà. Servirà un modo per verificare che tutte queste integrazioni di Amazon siano aggiornate.
- Lead: Non suona male. E per questo scriviamo uno script.
- Io: Ottimo! E sicuramente lo script avrà bisogno di parametri. Li accetterà?
- Lead: Certo che sì, non ci sono problemi!
- Io: Il processo potrebbe cambiare, si perderà la retrocompatibilità. Ci vorrà qualche forma di controllo semantico delle versioni.
- Lead: Ottima idea!
- Io: Gli strumenti possono essere cambiati manualmente, all'interno dell'interfaccia utente. Avremo bisogno di un modo per controllare e correggere questo.
…3 anni dopo:
- Lead: E abbiamo finito per usare terraform.
La morale della favola è che, anche se sei fino al collo in tutto ciò che è amazoniano,stai comunque utilizzando qualcosa che non proviene da AWS, e questi servizi hanno uno stato che utilizza il linguaggio per la configurazione, per sincronizzare quello stato.
CloudFormation lambda vs moduli git terraform
lambda è la soluzione CloudFormation per la logica degli utenti. Con lambda puoi o . Questo approccio comporta difficoltà aggiuntive che non esistono nel controllo semantico delle versioni dei moduli git in Terraform. Per me, il problema più pressante è stata la gestione delle autorizzazioni per tutte queste lambda personalizzate (e sono decine di account AWS). Un altro problema significativo è stata la questione del «cosa è arrivato prima — l'uovo o la gallina?»: essa era legata al codice lambda. Questa funzione stessa è un'infrastruttura e codice, e ha anch'essa bisogno di monitoraggio e aggiornamenti. L'ultimo chiodo nella bara è stata la difficoltà nell'aggiornamento semantico delle modifiche al codice lambda; dovevamo anche assicurarci che le azioni dello stack non cambiassero tra le esecuzioni senza un comando diretto.
Ricordo che un giorno ho voluto creare un deploy canarino per l'ambiente Elastic Beanstalk con un bilanciatore di carico classico. La soluzione più semplice sarebbe stata fare un secondo deployment per EB accanto all'ambiente di produzione, facendo un ulteriore passo: unire il gruppo di deploy canarino scalabile automaticamente con il LB del deployment nell'ambiente di produzione. E dato che Terraform utilizza , questo richiederebbe 4 righe di codice extra in Terraform. Quando ho chiesto se esisteva una soluzione comparabile in CloudFormation, mi hanno indicato un intero repository su git con un pipeline di deploy e altro: tutto ciò per quanto avremmo potuto fare con 4 sfortunate righe di codice Terraform.
Rileva meglio il drift
Assicurati che la realtà corrisponda alle aspettative.
— è una funzione molto potente delle operations as code, perché aiuta a garantire che la realtà corrisponda alle aspettative. È disponibile sia con CloudFormation che con Terraform. Ma man mano che lo stack cresce, la ricerca del drift in CloudFormation restituiva sempre più falsi positivi.
Con Terraform hai hook del ciclo di vita molto più avanzati per la rilevazione del drift. Ad esempio, introduci il comando nel caso in cui si voglia ignorare le modifiche nella definizione di un'attività specifica, senza ignorare le modifiche a tutto il deployment di ECS.
CDK e il futuro di CloudFormation
CloudFormation è difficile da gestire su larga scala e tra infrastrutture diverse. Molti di questi problemi sono riconosciuti, e lo strumento necessita di elementi come , una struttura per definire l'infrastruttura cloud nel codice e gestirla tramite AWS CloudFormation. Sarà interessante vedere cosa riserva il futuro per aws-cdk, ma avrà difficoltà a competere con i vantaggi di Terraform; saranno necessarie trasformazioni globali per rendere CloudFormation competitivo.
Affinché Terraform non deluda
Questo è 'infrastruttura come CODICE', non 'come testo'.
La mia prima impressione di Terraform è stata piuttosto negativa. Credo semplicemente di non aver capito l'approccio. Quasi tutti gli ingegneri inizialmente lo percepiscono involontariamente come un formato testuale che deve essere trasformato nell'infrastruttura desiderata. NON È COSÌ.
Le verità fondamentali della buona sviluppo software si applicano anche a Terraform
Ho notato che molte pratiche adottate per scrivere codice di qualità vengono ignorate in Terraform. Hai studiato per anni per diventare un buon programmatore. Non rinunciare a quest'esperienza solo perché stai lavorando con Terraform. Le verità fondamentali di una buona sviluppo software si applicano anche a Terraform.
Come si può scrivere codice senza documentazione?
Ho visto enormi stack di Terraform completamente privi di documentazione. Come si può scrivere codice per pagine intere senza alcuna documentazione? Aggiungi documentazione che spieghi il tuo codice Terraform (con accento sulla parola «codice»), perché questa sezione è così importante e cosa stai facendo.
Come si possono implementare servizi che una volta erano tutte in un'unica funzione main()?
Ho trovato stack di Terraform molto complessi presentati come un unico modulo. Perché non implementiamo software in questo modo? Perché suddividiamo grandi funzioni in parti più piccole? Le stesse risposte valgono anche per Terraform. Se un modulo è troppo grande, è necessario suddividerlo in moduli più piccoli.
La tua azienda non utilizza librerie?
Ho visto ingegneri che, lanciando un nuovo progetto con Terraform, copiavano e incollavano in modo stupido grandi pezzi da altri progetti nei propri, poi li sistemavano finché non funzionavano. Voi nella vostra azienda lavorereste così con il codice "live"? Non utilizziamo le librerie per caso. Sì, ma dove saremmo senza librerie comuni in linea di principio?!
Non usate PEP8 o gofmt?
Nella maggior parte dei linguaggi esiste uno schema di formattazione standard accettato. In Python è PEP8. In Go — gofmt. Terraform ha il suo: terraform fmt. Usatelo pure!
Iniziereste a usare React senza conoscere JavaScript?
I moduli Terraform possono semplificare alcune parti dell'infrastruttura complessa che state creando, ma ciò non significa che non dovete capirci nulla. Volete usare Terraform correttamente senza comprendere le risorse? Siete destinati a fallire: il tempo passerà e non vi abituerete mai a Terraform.
Scrivete singleton o state iniettando dipendenze?
L'iniezione delle dipendenze è una best practice riconosciuta nello sviluppo software, particolarmente apprezzata nei singleton. Come può tornare utile in Terraform? Ho incontrato moduli Terraform che dipendono dallo stato remoto. Invece di scrivere moduli che estraggono dallo stato remoto, crea un modulo che accetta parametri. Poi passa questi parametri al modulo.
Le tue librerie fanno dieci cose bene o una – eccellente?
Le librerie funzionano meglio quando si concentrano su un compito che eseguono alla perfezione. Invece di scrivere grandi moduli Terraform che cercano di fare tutto in una volta, compila parti che svolgono bene una singola funzione. E poi combinile come necessario.
Come apporti modifiche alle librerie senza compromettere la retrocompatibilità?
Il modulo principale di Terraform, così come una libreria comune, deve comunicare agli utenti le modifiche senza retrocompatibilità. Quando si verificano tali cambiamenti nelle librerie, è fastidioso, e lo stesso vale quando vengono apportate modifiche senza retrocompatibilità nei moduli di Terraform. Si raccomanda di utilizzare git tags e semver quando si usano i moduli di Terraform.
Il servizio di produzione è attivo sul tuo laptop o nel data center?
Hashicorp ha strumenti come per eseguire il tuo terraform. Questi servizi centralizzati semplificano la gestione, l'audit e l'approvazione delle modifiche a terraform.
Non stai scrivendo test?
Gli ingegneri riconoscono che il codice deve essere testato, ma spesso trascurano i controlli mentre lavorano con Terraform. Questo può portare a situazioni insidiose per l'infrastruttura. Consiglio di 'testare' o 'creare esempi' di stack utilizzando moduli che possono essere correttamente deployati per verifiche durante il CI/CD.
Terraform e microservizi
La vita e la morte delle aziende di microservizi dipendono dalla velocità, dagli aggiornamenti e dalla creazione di nuovi stack di lavoro microservizi.
Il principale aspetto negativo associato alle architetture a microservizi, dal quale non si può sfuggire, riguarda il lavoro e non il codice. Se si considera Terraform solo come uno strumento per automatizzare l'aspetto infrastrutturale delle architetture a microservizi, ci si priva dei veri vantaggi di questo sistema. Ora è già .
Fonte: habr.com
