Rappresentare l'infrastruttura come codice in un formato di testo ripetibile è una semplice best practice per i sistemi che non richiedono di armeggiare con i mouse. Questa pratica ha un nome: , e finora ci sono due strumenti popolari per implementarlo, soprattutto in AWS: и .
Confronto dell'esperienza con Terraform e CloudFormation
Prima di venire a (Aka ) Ho lavorato e ha utilizzato Terraform per tre anni. Nella nuova sede, ho utilizzato anche Terraform con tutte le mie forze, quindi l'azienda ha spinto la transizione verso tutto ciò che è alla Amazon, incluso CloudFormation. Ho sviluppato diligentemente le migliori pratiche per entrambi e ho utilizzato entrambi gli strumenti in flussi di lavoro molto complessi a livello di organizzazione. Successivamente, dopo aver valutato attentamente le implicazioni della migrazione da Terraform a CloudFormation, mi sono convinto che Terraform fosse probabilmente la scelta migliore per l'organizzazione.
Terraformare orribile
Software beta
Terraform non ha ancora rilasciato nemmeno la versione 1.0, il che è un buon motivo per non usarlo. È cambiato molto da quando l'ho provato per la prima volta io stesso, ma allora terraform apply spesso si rompeva dopo diversi aggiornamenti o semplicemente dopo un paio d'anni di utilizzo. Direi che “ora è tutto diverso”, ma... è quello che sembrano dire tutti, no? Ci sono modifiche che sono incompatibili con le versioni precedenti, sebbene siano appropriate, e sembra addirittura che la sintassi e le astrazioni degli archivi di risorse siano ora ciò di cui abbiamo bisogno. Lo strumento sembra essere davvero migliorato, ma... :-0
D'altra parte, AWS ha fatto un buon lavoro mantenendo la compatibilità con le versioni precedenti. Questo probabilmente perché i loro servizi vengono spesso testati approfonditamente all'interno dell'organizzazione e solo poi, rinominati, vengono pubblicati. Quindi “hanno provato duramente” è un eufemismo. Mantenere la compatibilità con le API per un sistema così vario e complesso come AWS è incredibilmente difficile. Chiunque abbia dovuto mantenere API pubbliche così ampiamente utilizzate dovrebbe capire quanto sia difficile farlo per così tanti anni. Ma il comportamento di CloudFormation, a quanto ricordo, non è mai cambiato nel corso degli anni.
Ti presento la gamba... è un proiettile
Per quanto ne so, elimina la risorsa fuori dagli schemi Lo stack CloudFormation dal tuo stack CF non è possibile. Lo stesso vale con Terraform. Ti consente di importare risorse esistenti nel tuo stack. Si può dire che la funzione sia sorprendente, ma da un grande potere derivano grandi responsabilità. Devi solo aggiungere una risorsa allo stack e mentre lavori con il tuo stack non puoi eliminare o modificare questa risorsa. Un giorno fallì. Un giorno su Twitch, qualcuno ha importato accidentalmente il gruppo di sicurezza AWS di qualcun altro nel proprio stack Terraform senza aver commesso alcun danno. Ho inserito diversi comandi e... il gruppo di sicurezza (insieme al traffico in entrata) è scomparso.
Terraformazione fantastica
Recupero da stati incompleti
A volte CloudFormation non riesce a passare completamente da uno stato all'altro. Allo stesso tempo, proverà a tornare a quello precedente. È un peccato che questo non sia sempre fattibile. Può essere piuttosto spaventoso eseguire il debug di ciò che è accaduto in seguito - non si sa mai se CloudFormation sarà felice di essere stato violato - anche solo per risolverlo. Se sarà possibile tornare allo stato precedente o meno, non sa davvero come determinarlo e, per impostazione predefinita, resta sospeso per ore in attesa di un miracolo.
Terraform, d'altro canto, tende a riprendersi dalle transizioni fallite in modo molto più agevole e offre strumenti di debug avanzati.
Modifiche più chiare allo stato del documento
“Okay, bilanciatore del carico, stai cambiando. Ma come?"
—ingegnere ansioso, pronto a premere il pulsante “accetta”.
A volte ho bisogno di eseguire alcune manipolazioni con il bilanciatore del carico nello stack CloudFormation, come aggiungere un numero di porta o modificare un gruppo di sicurezza. ClouFormation visualizza male le modifiche. Io, puntualmente, ricontrollo il file yaml dieci volte per assicurarmi di non aver cancellato nulla di necessario e di non aver aggiunto nulla di non necessario.
Terraform è molto più trasparente a questo riguardo. A volte è anche troppo trasparente (leggi: fastidioso). Fortunatamente, l'ultima versione include una migliore visualizzazione delle modifiche in modo che ora tu possa vedere esattamente cosa sta cambiando.
Flessibilità
Scrivere il software al contrario.
Per dirla senza mezzi termini, la caratteristica più importante del software di lunga durata è la capacità di adattarsi al cambiamento. Scrivi qualsiasi software al contrario. Molto spesso ho commesso degli errori prendendo un servizio "semplice" e poi iniziando a stipare tutto in un unico stack CloudFormation o Terraform. E ovviamente mesi dopo si è scoperto che avevo capito tutto male, e il servizio in realtà non era semplice! E ora devo in qualche modo suddividere un grande stack in piccoli componenti. Quando lavori con CloudFormation, questo può essere fatto solo ricreando prima lo stack esistente e io non lo faccio con i miei database. Terraform, d'altro canto, ha reso possibile sezionare lo stack e scomporlo in parti più piccole e più comprensibili.
Moduli in Git
Condividere il codice Terraform su più stack è molto più semplice che condividere il codice CloudFormation. Con Terraform, puoi inserire il tuo codice in un repository git e accedervi utilizzando il controllo della versione semantica. Chiunque abbia accesso a questo repository può riutilizzare il codice condiviso. L'equivalente di CloudFormation è S3, ma non ha gli stessi vantaggi e non c'è motivo per cui dovremmo abbandonare git a favore di S3.
L'organizzazione è cresciuta e la capacità di condividere stack comuni ha raggiunto un livello critico. Terraform rende tutto questo semplice e naturale, mentre CloudFormation ti farà fare i salti mortali prima che tu possa far funzionare qualcosa di simile.
Operazioni come codice
"Scriviamolo e va bene."
—un ingegnere 3 anni prima di inventare la bicicletta Terraform.
Quando si tratta di sviluppo software, Go o un programma Java non sono solo codice.
Codice come codice
C’è anche l’infrastruttura su cui funziona.
Infrastruttura come codice
Ma lei da dove viene? Come monitorarlo? Dove vive il tuo codice? Gli sviluppatori hanno bisogno dell'autorizzazione di accesso?
Operazioni come codice
Essere uno sviluppatore di software non significa solo scrivere codice.
AWS non è l'unico: probabilmente usi altri provider. SignalFx, PagerDuty o Github. Forse hai un server Jenkins interno per CI/CD o un dashboard Grafana interno per il monitoraggio. Infra as Code viene scelto per diversi motivi e ognuno è ugualmente importante per tutto ciò che riguarda il software.
Quando lavoravo presso Twitch, abbiamo accelerato i servizi all'interno dei sistemi misti embedded e AWS di Amazon. Abbiamo sfornato e supportato molti microservizi, aumentando i costi operativi. Le discussioni sono andate più o meno così:
- Я: Accidenti, ci vogliono un sacco di gesti per overcloccare un microservizio. Dovrò utilizzare questa spazzatura per creare un account AWS (siamo andati a 2 account in seguito microservizio), poi questo per impostare gli avvisi, questo per un repository di codici, e questo per una lista di posta elettronica, e poi questo...
- Condurre: Scriviamolo e va bene.
- Я: Ok, ma la sceneggiatura stessa cambierà. Avremo bisogno di un modo per verificare che tutti questi aggeggi Amazon integrati siano aggiornati.
- Condurre: Suona bene. E scriveremo una sceneggiatura per questo.
- Я: Grande! E probabilmente lo script dovrà ancora impostare i parametri. Li accetterà?
- Condurre: Lascialo portare dove va!
- Я: Il processo potrebbe cambiare e la compatibilità con le versioni precedenti andrà persa. Sarà richiesto un qualche tipo di controllo della versione semantica.
- Condurre: Grande idea!
- Я: Gli strumenti possono essere modificati manualmente, all'interno dell'interfaccia utente. Avremo bisogno di un modo per verificare e risolvere questo problema.
…3 anni dopo:
- Condurre: E abbiamo la terraformazione.
La morale della favola è: anche se tu perdutamente in tutto ciò che riguarda Amazon, stai ancora utilizzando qualcosa che non è AWS e questi servizi hanno uno stato che utilizza un linguaggio di configurazione per mantenere tale stato sincronizzato.
Terraform dei moduli lambda e git di CloudFormation
lambda è la soluzione di CloudFormation al problema della logica personalizzata. Con lambda puoi o . Questo approccio introduce ulteriori complessità che non sono presenti nel controllo delle versioni semantico dei moduli git di Terraform. Per me, il problema più urgente era la gestione delle autorizzazioni per tutti questi lambda utente (e si tratta di dozzine di account AWS). Un altro problema importante era il problema “cosa è venuto prima, l’uovo o la gallina?”: era legato al codice lambda. Questa funzione stessa è infrastruttura e codice e necessita di monitoraggio e aggiornamenti. L’ultimo chiodo nella bara è stata la difficoltà nell’aggiornare semanticamente le modifiche al codice lambda; dovevamo anche assicurarci che le azioni dello stack senza un comando diretto non cambiassero tra le esecuzioni.
Ricordo che una volta volevo creare una distribuzione Canary per l'ambiente Elastic Beanstalk con un classico sistema di bilanciamento del carico. La cosa più semplice da fare sarebbe realizzare una seconda distribuzione per l'EB accanto all'ambiente di produzione, facendo un ulteriore passo avanti: combinando il gruppo di distribuzione Canary con scalabilità automatica con il distribuzione LB nell'ambiente di produzione. E poiché Terraform utilizza , ciò richiederà 4 righe di codice aggiuntive in Terraform. Quando ho chiesto se esistesse una soluzione comparabile in CloudFormation, mi hanno indicato un intero repository git con una pipeline di distribuzione e tutto il resto, tutto per il bene di qualcosa che le povere 4 righe di codice Terraform potevano fare.
Rileva meglio la deriva
Assicurati che la realtà corrisponda alle aspettative.
è un'operazione molto potente come funzionalità del codice perché aiuta a garantire che la realtà corrisponda alle aspettative. È disponibile sia con CloudFormation che con Terraform. Ma man mano che lo stack di produzione cresceva, la ricerca di derive in CloudFormation ha prodotto sempre più falsi rilevamenti.
Con Terraform hai hook del ciclo di vita molto più avanzati per il rilevamento della deriva. Ad esempio, inserisci il comando direttamente nella definizione dell'attività ECS se desideri ignorare le modifiche a una definizione di attività specifica senza ignorare le modifiche all'intera distribuzione ECS.
CDK e il futuro di CloudFormation
CloudFormation è difficile da gestire su larga scala e tra infrastrutture. Molte di queste difficoltà sono riconosciute e lo strumento ha bisogno di cose come , un framework per definire l'infrastruttura cloud nel codice ed eseguirla tramite AWS CloudFormation. Sarà interessante vedere cosa riserva il futuro ad aws-cdk, ma avrà difficoltà a competere con gli altri punti di forza di Terraform; Per aggiornare CloudFormation, saranno necessarie modifiche globali.
In modo che Terraform non deluda
Si tratta di “infrastruttura come codice” e non “come testo”.
La mia prima impressione di Terraform è stata piuttosto negativa. Penso di non aver capito l'approccio. Quasi tutti gli ingegneri lo percepiscono involontariamente come un formato di testo che deve essere convertito nell'infrastruttura desiderata. NON FARLO IN QUESTO MODO.
I principi di un buon sviluppo software si applicano anche a Terraform.
Ho visto molte pratiche adottate per creare un buon codice ignorate in Terraform. Hai studiato per anni per diventare un buon programmatore. Non rinunciare a questa esperienza solo perché lavori con Terraform. I principi fondamentali di un buon sviluppo software si applicano a Terraform.
Come è possibile che il codice non venga documentato?
Ho visto enormi stack Terraform senza alcuna documentazione. Come puoi scrivere codice in pagine, senza alcuna documentazione? Aggiungi la documentazione che spiega il tuo codice Terraform (enfasi sulla parola "codice"), perché questa sezione è così importante e cosa fai.
Come possiamo distribuire servizi che una volta erano un'unica grande funzione main()?
Ho visto stack Terraform molto complessi presentati come un singolo modulo. Perché non distribuiamo il software in questo modo? Perché dividiamo le funzioni grandi in funzioni più piccole? Le stesse risposte si applicano a Terraform. Se il tuo modulo è troppo grande, devi suddividerlo in moduli più piccoli.
La tua azienda non utilizza biblioteche?
Ho visto come gli ingegneri, avviando un nuovo progetto utilizzando Terraform, hanno stupidamente copiato e incollato enormi pezzi di altri progetti nei propri, e poi hanno armeggiato con essi finché non hanno iniziato a funzionare. Lavoreresti in questo modo con il codice “combattimento” nella tua azienda? Non usiamo solo le biblioteche. SÌ, ma dove siamo senza le librerie condivise in linea di principio?!
Non usi PEP8 o gofmt?
La maggior parte delle lingue dispone di uno schema di formattazione standard accettato. In Python questo è PEP8. In Go-gofmt. Terraform ha il suo: terraform fmt. Divertitevi per la vostra salute!
Utilizzerai React senza conoscere JavaScript?
I moduli Terraform possono semplificare parte della complessa infrastruttura che crei, ma ciò non significa che non puoi armeggiarci affatto. Vuoi utilizzare Terraform correttamente senza comprendere le risorse? Sei condannato: il tempo passerà e non riuscirai mai a padroneggiare Terraform.
Stai codificando con singleton o inserimento di dipendenze?
L'inserimento delle dipendenze è una best practice riconosciuta per lo sviluppo software ed è preferibile rispetto ai singleton. In che modo è utile in Terraform? Ho visto moduli Terraform che dipendono dallo stato remoto. Invece di scrivere moduli che recuperano lo stato remoto, scrivi un modulo che accetta parametri. E poi passa questi parametri al modulo.
Le vostre biblioteche fanno dieci cose bene o una cosa eccezionale?
Le biblioteche che funzionano meglio sono quelle che si concentrano su un compito che svolgono molto bene. Invece di scrivere grandi moduli Terraform che tentano di fare tutto in una volta, creane parti che facciano bene una cosa. E poi combinarli secondo necessità.
Come si apportano modifiche alle librerie senza compatibilità con le versioni precedenti?
Un modulo Terraform comune, come una normale libreria, deve in qualche modo comunicare le modifiche agli utenti senza essere retrocompatibile. È fastidioso quando queste modifiche si verificano nelle librerie ed è altrettanto fastidioso quando vengono apportate modifiche non compatibili con le versioni precedenti nei moduli Terraform. Si consiglia di utilizzare tag git e semver quando si utilizzano i moduli Terraform.
Il tuo servizio di produzione è in esecuzione sul tuo laptop o in un data center?
Hashicorp ha strumenti come per eseguire la tua terraformazione. Questi servizi centralizzati semplificano la gestione, il controllo e l'approvazione delle modifiche alla terraformazione.
Non scrivi i test?
Gli ingegneri riconoscono che il codice deve essere testato, ma spesso loro stessi dimenticano di eseguire i test quando lavorano con Terraform. Per le infrastrutture, questo è irto di momenti pericolosi. Il mio consiglio è di "testare" o "creare esempi" di stack utilizzando moduli che possono essere distribuiti correttamente per i test durante CI/CD.
Terraform e microservizi
La vita e la morte delle aziende di microservizi dipendono dalla velocità, dall’innovazione e dall’interruzione dei nuovi workstack di microservizi.
L’aspetto negativo più comune associato alle architetture a microservizi, e che non può essere eliminato, è legato al lavoro, non al codice. Se pensi a Terraform semplicemente come un modo per automatizzare solo il lato infrastrutturale di un'architettura di microservizi, ti stai perdendo i veri vantaggi del sistema. Ora è già .
Fonte: habr.com