Rappresentare l'infrastruttura in codice in un formato testuale ripetibile è una pratica migliore semplice che non richiede un mouse. Questa pratica è stata battezzata come — , e al momento, per realizzarla, soprattutto in AWS, ci sono due strumenti popolari: e .
Confronto l'esperienza di lavoro con Terraform e CloudFormation
Prima di arrivare a (ovvero ) ho lavorato 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 è probabilmente la scelta migliore per un'organizzazione.
Terraform Terribile
Versione Beta del software
Terraform non ha nemmeno ancora raggiunto la versione 1.0, e questo è un motivo valido per non utilizzarlo. Da quando l'ho provato per la prima volta, è cambiato molto, ma all'epoca terraform apply spesso si rompeva dopo pochi aggiornamenti o semplicemente dopo un paio d'anni di utilizzo. Direi che «ora è tutto diverso», ma... così sembra dire tutti, giusto? Ci sono modifiche che non sono compatibili con le versioni precedenti, anche se sono appropriate, e persino la sensazione che la sintassi e le astrazioni dei repository delle risorse ora siano più che adeguate. Lo strumento sembra davvero migliore, ma... :-0
D'altra parte, AWS ha fatto un buon lavoro mantenendo la compatibilità con le versioni precedenti. Probabilmente è tutto perché i loro servizi vengono testati accuratamente all'interno dell'organizzazione prima di essere pubblicati, solo dopo averli rinominati. Quindi dire che ci hanno lavorato bene è un eufemismo. Mantenere la compatibilità con le versioni API precedenti per un sistema così variegato e complesso come AWS è incredibilmente difficile. Chiunque abbia dovuto mantenere API pubbliche utilizzate così ampiamente deve capire quanto sia difficile farlo per tanti anni. Tuttavia, il comportamento di CloudFormation, per quanto mi ricordi, non è cambiato nel tempo.
Fai conoscenza, gamba… è un proiettile
Per quanto ne so, eliminare una risorsa esterna Non è possibile importare uno stack CloudFormation in un altro stack CF. La situazione è simile con Terraform. Esso consente di importare risorse esistenti nel proprio stack. Una funzione, si può dire, straordinaria, ma con grande potere arriva anche una grande responsabilità. Non si può semplicemente aggiungere una risorsa allo stack, e mentre si lavora con il proprio stack, non è possibile eliminare o modificare quella risorsa. Una volta ciò 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… il gruppo di sicurezza (insieme al traffico in ingresso) è scomparso.
Terraform Il Grande
Ripristino da stati incompleti
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ò che ne risulta può essere un po' spaventoso: non si sa mai se CloudFormation sarà contento di essere manomesso, anche se per ripararlo. E se riuscirà a tornare allo stato precedente, non lo sa bene e di default rimane ore in attesa di un miracolo.
Terraform, al contrario, tende a recuperare in modo più elegante dopo passaggi non riusciti e offre strumenti di debug avanzati.
Modifiche più chiare negli stati del documento
«Va bene, bilanciatore di carico, stai cambiando. Ma come?»
— ingegnere preoccupato, pronto a premere il pulsante «accetta».
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.
Terraform è molto più trasparente in questo senso. A volte è addirittura troppo trasparente (leggi: irritante). Fortunatamente, nell'ultima versione è stata inclusa una visualizzazione migliorata delle modifiche — ora è chiaro cosa sta cambiando.
Flessibilità
Scrivi software al contrario.
Parlando chiaramente, la caratteristica distintiva più importante di un software a lungo termine è la capacità di adattarsi ai cambiamenti. Qualsiasi software va scritto al contrario. Io stesso mi sono spesso sbagliato prendendo un servizio 'semplice', solo per poi iniziare a infilare tutto in un unico stack CloudFormation o Terraform. E ovviamente, dopo mesi, scoprivo che avevo frainteso tutto e il servizio non era affatto semplice! Così, avevo bisogno in qualche modo di suddividere un grande stack in piccole parti. Quando lavori con CloudFormation, questo è possibile solo ricreando preliminarmente lo stack esistente, cosa che io, con i miei database, non faccio. Terraform, invece, permetteva di sezionare lo stack e di suddividerlo in parti più comprensibili.
Moduli in git
Condividere codice Terraform tra numerosi stack è molto più 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ò riutilizzare il codice condiviso. L'equivalente in CloudFormation è S3, ma non ha gli stessi vantaggi e non c'è alcuna ragione per cui dovremmo rinunciare a git a favore di S3.
L'organizzazione cresce e la capacità di condividere stack comuni ha raggiunto un livello critico. Con Terraform tutto ciò avviene in modo facile e naturale, mentre CloudFormation ti costringerà a saltare attraverso anelli prima che tu possa ottenere qualcosa di simile.
Operazioni come codice
"Fai uno script e va bene".
- ingegnere tre anni prima di inventare il 'ciclo' Terraform.
Quando si parla di sviluppo software, Go o un programma in Java non sono solo codice.
Codice come codice
Esiste anche l'infrastruttura su cui esso funziona.
Infrastructure as Code
Ma da dove proviene? Come monitorarla? Dove risiede il tuo codice? I programmatori hanno bisogno di permessi per accedervi?
Operazioni come codice
Essere un sviluppatore di software non significa semplicemente scrivere codice.
Non è 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 è ugualmente importante per tutto ciò che riguarda il software.
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 svolgevano più o meno in questo modo:
- Io: Accidenti, troppe manovre per avviare un solo microservizio. Dovrò usare questa cosa per creare un account AWS (stavamo puntando a 2 account su microservizio), poi questo — per configurare le notifiche, ancora questo — per il repository del codice, e questo — per l'elenco degli indirizzi email, e infine questo...
- Lead: Scriptiamolo e basta.
- Io: Va bene, ma lo script cambierà. Ci vorrà un modo per controllare che tutte queste cose incorporate di Amazon siano in uno stato attuale.
- Lead: Sembra una buona idea. E per questo scriviamo uno script.
- Io: Ottimo! Ma allo script serviranno sicuramente dei parametri. Li accetterà?
- Lead: Certo che li accetterà, non può fare altrimenti!
- Io: Il processo può cambiare, potrebbe perdere la retrocompatibilità. Servirà un qualche tipo di controllo semantico delle versioni.
- Lead: Ottima idea!
- Io: Gli strumenti possono essere modificati manualmente, all'interno dell'interfaccia utente. Ci servirà un modo per controllare e correggere questo.
…3 anni dopo:
- Lead: E così è nato Terraform.
La morale della favola è: anche se sei fino alle orecchie nel mondo di Amazon, utilizzi comunque qualcosa che non proviene da AWS, e questi servizi hanno uno stato che usa un linguaggio per la configurazione, per sincronizzare tale stato.
CloudFormation lambda vs moduli git di terraform
la lambda è la soluzione di CloudFormation per la logica personalizzata. Con la lambda puoi o . Questo approccio comporta complessità aggiuntive che non ci sono nel controllo semantico delle versioni dei moduli git in Terraform. Per me, il problema più urgente è stato la gestione dei permessi per tutte queste lambda personalizzate (che comportano decine di account AWS). Un altro problema importante è stata la questione 'cosa è venuto prima — il pollo o l'uovo?': era legata al codice della lambda. Questa funzione è sia infrastruttura che codice e ha bisogno di monitoraggio e aggiornamenti. L'ultima goccia nel secchio è stata la difficoltà nel fare aggiornamenti semantici delle modifiche al codice della lambda; era necessario 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 classico bilanciatore di carico. Sarebbe stato più semplice realizzare un secondo deployment per EB accanto all'ambiente di produzione, compiendo un ulteriore passo: unire automaticamente il gruppo scalabile del canary deploy con il bilanciatore di carico del deployment in produzione. E poiché Terraform utilizza , questo richiederà 4 righe di codice aggiuntive in Terraform. Quando ho chiesto se c'era una soluzione comparabile in CloudFormation, mi hanno indicato un intero repository su git con un pipeline di deployment e altro: e tutto questo — per ciò che avrebbero potuto fare 4 povere righe di codice in Terraform.
Rileva meglio il drift
Assicurati che la realtà corrisponda alle aspettative.
è una funzione molto potente delle operations as code, poiché aiuta a garantire che la realtà corrisponda alle aspettative. È disponibile sia con CloudFormation che con Terraform. Ma man mano che la pila di lavoro cresce, la ricerca del drift in CloudFormation produceva sempre più falsi positivi.
Con Terraform hai hook del ciclo di vita molto più avanzati per la rilevazione del drift. Ad esempio, puoi digitare il comando direttamente nella definizione del task ECS, se desideri ignorare le modifiche nella definizione di un particolare task, senza ignorare nel contempo le modifiche all'intero deployment ECS.
CDK e il futuro di CloudFormation
CloudFormation è difficile da gestire su larga scala inter-infrastrutturale. Molte di queste difficoltà sono state riconosciute, e lo strumento necessita di cose come , una struttura per definire l'infrastruttura cloud nel codice e implementarli tramite AWS CloudFormation. Sarà interessante vedere cosa riserva il futuro per aws-cdk, ma avrà difficoltà a competere con altri vantaggi di Terraform; per allineare CloudFormation ci vorranno cambiamenti globali.
Per evitare che Terraform deluda
Questo è "infrastruttura come CODICE", non "come testo".
La mia prima impressione di Terraform è stata piuttosto negativa. Penso che semplicemente non avessi compreso l'approccio. Quasi tutti gli ingegneri iniziano a percepirlo involontariamente come un formato di testo da trasformare nell'infrastruttura desiderata. NON È COSÌ.
Le verità fondamentali di un buon 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 questa esperienza solo perché stai lavorando con Terraform. I principi fondamentali di una buona sviluppo software si applicano anche a Terraform.
Come si può scrivere codice senza documentarlo?
Ho visto enormi stack Terraform completamente privi di documentazione. Come si può scrivere codice per pagine intere senza alcuna documentazione? Aggiungi documentazione che spiega il tuo codice Terraform (l'accento qui è sulla parola "codice"), perché questa sezione è così importante e cosa stai facendo.
Come puoi implementare servizi che una volta erano un'unica grande funzione main()?
Ho incontrato stack Terraform molto complessi presentati come un unico modulo. Perché non implementiamo il software in questo modo? Perché scomponiamo funzioni grandi in pezzi più piccoli? Le stesse risposte sono valide anche per Terraform. Se il tuo modulo è troppo grande, devi dividerlo in moduli più piccoli.
La tua azienda non utilizza librerie?
Ho visto ingegneri che, mentre avviavano un nuovo progetto con Terraform, copiava e incollava enormi porzioni di codice da altri progetti nei propri, per poi limarli finché non iniziavano a funzionare. In azienda lavorereste in questo modo con codice "di produzione"? Non utilizziamo le librerie per caso. Sì, ma dove saremmo senza librerie comuni in generale?!
Non segui PEP8 o gofmt?
Nella maggior parte dei linguaggi c'è uno standard di formattazione accettato. In Python è PEP8. In Go è gofmt. Terraform ha il suo: terraform fmt. Usalo liberamente!
Utilizzeresti React senza conoscere JavaScript?
I moduli Terraform possono semplificare alcune parti della complessa infrastruttura che stai creando, ma ciò non significa che puoi ignorarne completamente il funzionamento. Vuoi usare Terraform correttamente senza comprendere le risorse? Sei destinato a fallire: il tempo passerà e non riuscirai mai a padroneggiare Terraform.
Scrivi codice con singleton, o iniettando dipendenze?
L'iniezione delle dipendenze è una pratica riconosciuta come migliore per lo sviluppo del software, preferita dai singleton. Come può essere utile in Terraform? Ho incontrato moduli Terraform che dipendono da uno stato remoto. Invece di scrivere moduli che estraggono dallo stato remoto, scrivi 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 singolo compito che eseguono in modo eccellente. Invece di scrivere grandi moduli Terraform che cercano di fare tutto e subito, costruisci parti che fanno bene qualcosa di specifico. E poi combinane così come serve.
Come apporti modifiche alle librerie senza retrocompatibilità?
Un modulo Terraform generale, come una qualsiasi libreria, deve trovare un modo per comunicare agli utenti le modifiche senza retrocompatibilità. Quando ci sono modifiche nelle librerie, è fastidioso, e lo è altrettanto quando si apportano modifiche senza retrocompatibilità nei moduli Terraform. Si consiglia di utilizzare git tags e semver quando si usano i moduli Terraform.
Il servizio di produzione è in esecuzione 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 terraform.
Non scrivi test?
Gli ingegneri riconoscono che il codice deve essere testato, ma spesso trascurano i controlli mentre lavorano con Terraform. Per l'infrastruttura ciò può comportare momenti insidiosi. Ti consiglio di "testare" o "creare esempi" di stack utilizzando moduli che possono essere correttamente deployati per la verifica durante CI/CD.
Terraform e microservizi
La vita e la morte delle aziende di microservizi dipende dalla velocità, dall'aggiornamento e dalla distruzione di nuovi stack lavorativi di microservizi.
Il punto negativo più comune associato alle architetture a microservizi, dal quale non ci si può liberare, è legato al lavoro e non al codice. Se consideri Terraform solo come un modo per automatizzare l'aspetto infrastrutturale dell'architettura a microservizi, ti privi dei veri vantaggi di questo sistema. Oggi già .
Fonte: habr.com
