Molte persone conoscono e utilizzano Terraform nel loro lavoro quotidiano, ma non sono ancora state definite le migliori pratiche per utilizzarlo. Ogni squadra deve inventare i propri approcci e metodi.
La tua infrastruttura quasi sicuramente inizia in modo semplice: poche risorse + alcuni sviluppatori. Nel corso del tempo, cresce in tutti i tipi di direzioni. Trovi modi per raggruppare le risorse in moduli Terraform, organizzare il codice in cartelle e cos'altro può andare storto? (le ultime parole famose)
Il tempo passa e ti senti come se la tua infrastruttura fosse il tuo nuovo animale domestico, ma perché? Sei preoccupato per cambiamenti inspiegabili nell'infrastruttura, hai paura di toccare l'infrastruttura e il codice - di conseguenza ritardi nuove funzionalità o riduci la qualità...
Dopo tre anni trascorsi a gestire una raccolta di moduli della community Terraform per AWS su Github e dopo la manutenzione a lungo termine di Terraform in produzione, Anton Babenko è pronto a condividere la sua esperienza: come scrivere moduli TF in modo che non danneggi in futuro.
Al termine della conferenza, i partecipanti avranno acquisito maggiore familiarità con i principi di gestione delle risorse in Terraform, le best practice associate ai moduli in Terraform e alcuni principi di integrazione continua associati alla gestione dell'infrastruttura.
Disclaimer: Prendo atto che questo rapporto è datato novembre 2018: sono già passati 2 anni. La versione di Terraform 0.11 discussa nel rapporto non è più supportata. Negli ultimi 2 anni sono state rilasciate 2 nuove versioni, che contengono molte innovazioni, miglioramenti e modifiche. Si prega di prestare attenzione a questo e di controllare la documentazione.
Links:
- +
- — codice e documentazione di formattazione automatica
- — generatore di moduli Terraform (WIP)
- — Generatore di codice Terraform da diagrammi visivi (WIP)
- www.terraform-best-practices.com
- (I nuovi post sono sul mio sito personale www.antonbabenko.com/)
- @antonbabenko - Twitter e un sacco di pantaloni diversi
Mi chiamo Anton Babenko. Alcuni di voi probabilmente hanno utilizzato il codice che ho scritto. Ora ne parlerò con più sicurezza che mai, perché ho accesso alle statistiche.
Lavoro su Terraform e partecipo attivamente e collaboro a un gran numero di progetti open source relativi a Terraform e Amazon dal 2015.
Da allora ho scritto abbastanza codice per dirlo in modo interessante. E proverò a parlartene adesso.
Parlerò delle complessità e delle specificità del lavoro con Terraform. Ma non è proprio questo l'argomento di HighLoad. E ora capirai perché.
Nel corso del tempo, ho iniziato a scrivere moduli Terraform. Gli utenti hanno scritto domande, io le ho riscritte. Quindi ho scritto varie utilità per formattare il codice utilizzando un hook pre-commit, ecc.
C'erano molti progetti interessanti. Mi piace la generazione di codice perché mi piace che il computer svolga sempre più lavoro per me e per il programmatore, quindi attualmente sto lavorando su un generatore di codice Terraform da diagrammi visivi. Forse alcuni di voi li hanno visti. Queste sono bellissime scatole con frecce. E penso che sia fantastico se puoi fare clic sul pulsante "Esporta" e ottenere tutto come codice.
Vengo dall'Ucraina. Vivo in Norvegia da molti anni.
Inoltre, le informazioni per questo rapporto sono state raccolte da persone che conoscono il mio nome e mi trovano sui social network. Ho quasi sempre lo stesso soprannome.
Come ho già detto, sono il principale manutentore dei moduli Terraform AWS, che è uno dei repository più grandi su GitHub dove ospitiamo moduli per le attività più comuni: VPC, Autoscaling, RDS.
E quello che hai sentito ora è il più elementare. Se dubiti di capire cos'è Terraform, allora è meglio trascorrere il tempo altrove. Ci saranno molti termini tecnici qui. E non ho esitato a dichiarare che il livello del rapporto è il più alto. Ciò significa che posso parlare usando tutti i termini possibili senza troppe spiegazioni.
Terraform è apparso nel 2014 come un'utilità che permetteva di scrivere, pianificare e gestire l'infrastruttura come codice. Il concetto chiave qui è “infrastruttura come codice”.
Tutta la documentazione, come ho detto, è scritta . Spero che la maggior parte delle persone conosca questo sito e abbia letto la documentazione. Se è così, allora sei nel posto giusto.
Ecco come appare un normale file di configurazione Terraform, in cui definiamo prima alcune variabili.
In questo caso definiamo "aws_region".
Quindi descriviamo quali risorse vogliamo creare.
Eseguiamo alcuni comandi, in particolare “terraform init” per caricare dipendenze e provider.
Ed eseguiamo il comando "terraform apply" per verificare se la configurazione specificata corrisponde alle risorse che abbiamo creato. Poiché non abbiamo creato nulla prima, Terraform ci chiede di creare queste risorse.
Lo confermiamo. Creiamo così un secchio chiamato lumaca di mare.
Esistono anche diverse utilità simili. Molti di voi che utilizzano Amazon conoscono AWS CloudFormation o Google Cloud Deployment Manager o Azure Resource Manager. Ognuno di essi ha la propria implementazione di qualche tipo per la gestione delle risorse all'interno di ciascuno di questi fornitori di cloud pubblico. Terraform è particolarmente utile perché ti consente di gestire oltre 100 provider. (Più dettagli )
Gli obiettivi che Terraform ha perseguito fin dall'inizio:
- Terraform fornisce una visualizzazione unica delle risorse.
- Ti consente di supportare tutte le piattaforme moderne.
- E Terraform è stato progettato fin dall'inizio come un'utilità che consente di modificare l'infrastruttura in modo sicuro e prevedibile.
Nel 2014 la parola “prevedibile” suonava molto insolita in questo contesto.
Terraform è un'utilità universale. Se disponi di un'API, puoi controllare assolutamente tutto:
- Puoi utilizzare più di 120 provider per gestire tutto ciò che desideri.
- Ad esempio, puoi utilizzare Terraform per descrivere l'accesso ai repository GitHub.
- Puoi persino creare e chiudere bug in Jira.
- Puoi gestire le metriche di New Relic.
- Puoi anche creare file in Dropbox se lo desideri davvero.
Tutto questo viene ottenuto utilizzando i provider Terraform, che dispongono di un'API aperta che può essere descritta in Go.
Diciamo che abbiamo iniziato a utilizzare Terraform, letto della documentazione sul sito, guardato alcuni video e iniziato a scrivere main.tf, come ho mostrato nelle diapositive precedenti.
E tutto è fantastico, hai un file che crea un VPC.
Se desideri creare un VPC, specifica circa queste 12 righe. Descrivi in quale regione vuoi creare, quale cidr_block di indirizzi IP utilizzare. È tutto.
Naturalmente il progetto crescerà gradualmente.
E aggiungerai un sacco di nuove cose lì: risorse, origini dati, ti integrerai con nuovi provider, all'improvviso vorrai utilizzare Terraform per gestire gli utenti nel tuo account GitHub, ecc. Potresti voler utilizzare diversi Provider DNS, incrocia tutto. Terraform rende tutto questo semplice.
Diamo un'occhiata al seguente esempio.
Aggiungi gradualmente internet_gateway perché desideri che le risorse del tuo VPC abbiano accesso a Internet. Questa è una buona idea.
Il risultato è questo main.tf:
Questa è la parte superiore di main.tf.
Questa è la parte inferiore di main.tf.
Quindi aggiungi la sottorete. Nel momento in cui desideri aggiungere gateway NAT, percorsi, tabelle di routing e una serie di altre sottoreti, non avrai 38 linee, ma circa 200-300 linee.
Cioè, il tuo file main.tf sta gradualmente crescendo. E molto spesso le persone mettono tutto in un unico file. 10-20 Kb appaiono in main.tf. Immagina che 10-20 Kb siano contenuti di testo. E tutto è collegato a tutto. Sta gradualmente diventando difficile lavorare con questo. 10-20 Kb sono un buon caso utente, a volte di più. E le persone non sempre pensano che questo sia un male.
Come nella programmazione normale, cioè non nell'infrastruttura come codice, siamo abituati a utilizzare una serie di classi, pacchetti, moduli e raggruppamenti diversi. Terraform ti consente di fare più o meno la stessa cosa.
- Il codice sta crescendo.
- Crescono anche le dipendenze tra le risorse.
E ne abbiamo un grande, grandissimo bisogno. Comprendiamo che non possiamo più vivere così. Il nostro codice sta diventando immenso. 10-20 Kb ovviamente non sono molto grandi, ma stiamo parlando solo dello stack di rete, cioè hai solo aggiunto risorse di rete. Non stiamo parlando di Application Load Balancer, cluster ES di distribuzione, Kubernetes, ecc., in cui è possibile inserire facilmente 100 Kb. Se scrivi tutto questo, imparerai presto che Terraform fornisce moduli Terraform.
I moduli Terraform sono una configurazione Terraform autonoma gestita come gruppo. Questo è tutto ciò che devi sapere sui moduli Terraform. Non sono affatto intelligenti, non ti permettono di creare connessioni complesse a seconda di qualcosa. Tutto questo ricade sulle spalle degli sviluppatori. Cioè, questa è solo una sorta di configurazione Terraform che hai già scritto. E puoi semplicemente chiamarlo come gruppo.
Stiamo quindi cercando di capire come ottimizzeremo i nostri 10-20-30 Kb di codice. Ci stiamo gradualmente rendendo conto che è necessario utilizzare alcuni moduli.
Il primo tipo di moduli che incontri sono i moduli di risorse. Non capiscono di cosa tratta la vostra infrastruttura, di cosa tratta la vostra attività, dove e quali sono le condizioni. Questi sono esattamente i moduli che io, insieme alla comunità open source, amministriamo e che proponiamo come elementi costitutivi iniziali della vostra infrastruttura.
Un esempio di modulo di risorse.
Quando chiamiamo un modulo di risorsa, specifichiamo da quale percorso dovremmo caricarne il contenuto.
Indichiamo quale versione vogliamo scaricare.
Passiamo un sacco di argomenti lì. È tutto. Questo è tutto ciò che dobbiamo sapere quando utilizziamo questo modulo.
Molte persone pensano che se utilizzano l'ultima versione, tutto sarà stabile. Ma no. L'infrastruttura deve essere dotata di versione; dobbiamo rispondere chiaramente a quale versione è stato distribuito questo o quel componente.
Ecco il codice che si trova all'interno di questo modulo. Modulo del gruppo di sicurezza. Qui la pergamena arriva alla 640a riga. Creare una risorsa di sicurezza in Amazon in ogni possibile configurazione è un compito non banale. Non è sufficiente creare semplicemente un gruppo di sicurezza e dirgli quali regole trasmettergli. Sarebbe molto semplice. Esistono milioni di restrizioni diverse all'interno di Amazon. Ad esempio, se usi Endpoint VPC, elenco di prefissi, varie API e cerca di combinare tutto questo con tutto il resto, Terraform non ti consente di farlo. E neanche l'API di Amazon lo consente. Pertanto, dobbiamo nascondere tutta questa terribile logica in un modulo e fornire all'utente un codice simile a questo.
L'utente non ha bisogno di sapere come è fatto all'interno.
Il secondo tipo di moduli, costituito da moduli di risorse, risolve già problemi più applicabili alla tua attività. Spesso questo è un luogo che è un'estensione di Terraform e stabilisce alcuni valori rigidi per i tag, per gli standard aziendali. Puoi anche aggiungere lì funzionalità che Terraform attualmente non ti consente di utilizzare. Questo è proprio adesso. Ora la versione 0.11, che sta per diventare un ricordo del passato. Tuttavia, i preprocessori, jsonnet, cookiecutter e un sacco di altre cose sono il meccanismo ausiliario che deve essere utilizzato per un lavoro a tutti gli effetti.
Successivamente mostrerò alcuni esempi di questo.
Il modulo infrastruttura si chiama esattamente allo stesso modo.
È indicata la fonte da cui scaricare il contenuto.
Un sacco di valori vengono passati e passati in questo modulo.
Successivamente, all'interno di questo modulo, vengono chiamati un gruppo di moduli di risorse per creare un VPC o un sistema di bilanciamento del carico dell'applicazione oppure per creare un gruppo di sicurezza o per un cluster del servizio Elastic Container.
Esistono due tipi di moduli. Questo è importante da capire perché la maggior parte delle informazioni che ho raggruppato in questo rapporto non sono scritte nella documentazione.
E la documentazione in Terraform in questo momento è piuttosto problematica perché dice semplicemente che ci sono queste funzionalità e che puoi usarle. Ma non dice come usare queste funzionalità, perché è meglio usarle. Pertanto, un numero molto elevato di persone scrive qualcosa con cui non può convivere.
Di seguito diamo un'occhiata a come scrivere questi moduli. Poi vedremo come chiamarli e come lavorare con il codice.
Registro Terraform -
Il suggerimento n. 0 è non scrivere moduli di risorse. La maggior parte di questi moduli sono già scritti per te. Come ho detto, sono open source, non contengono alcuna logica aziendale, non hanno valori codificati per indirizzi IP, password, ecc. Il modulo è molto flessibile. E molto probabilmente è già stato scritto. Esistono molti moduli per le risorse di Amazon. Circa 650. E la maggior parte sono di buona qualità.
In questo esempio, qualcuno è venuto da te e ti ha detto: “Voglio essere in grado di gestire un database. Crea un modulo così posso creare un database." La persona non conosce i dettagli di implementazione di Amazon o Terraform. Dice semplicemente: "Voglio gestire MSSQL". Cioè, intendiamo che chiamerà il nostro modulo, passerà lì il tipo di motore e indicherà il fuso orario.
E una persona non dovrebbe sapere che creeremo due diverse risorse all'interno di questo modulo: una per MSSQL, la seconda per tutto il resto, solo perché in Terraform 0.11 non è possibile specificare i valori del fuso orario come facoltativi.
E all'uscita da questo modulo, una persona potrà semplicemente ricevere un indirizzo. Non saprà da quale database, da quale risorsa stiamo creando tutto questo internamente. Questo è un elemento molto importante di occultamento. E questo vale non solo per quei moduli che sono pubblici in open source, ma anche per quei moduli che scriverai all'interno dei tuoi progetti e team.
Questo è il secondo argomento, che è abbastanza importante se usi Terraform da un po'. Hai un repository in cui inserisci tutti i moduli Terraform per la tua azienda. Ed è abbastanza normale che nel tempo questo progetto raggiunga una dimensione di uno o due megabyte. Questo va bene.
Ma il problema è il modo in cui Terraform chiama questi moduli. Ad esempio, se chiami un modulo per creare ogni singolo utente, Terraform caricherà prima l'intero repository e poi passerà alla cartella in cui si trova quel modulo specifico. In questo modo scaricherai un megabyte ogni volta. Se gestisci 100 o 200 utenti, scaricherai 100 o 200 megabyte e poi andrai in quella cartella. Quindi, naturalmente, non vuoi scaricare un sacco di cose ogni volta che premi "Terraform init".
Ci sono due soluzioni a questo problema. Il primo è usare percorsi relativi. In questo modo indichi nel codice che la cartella è locale (./). E prima di avviare qualsiasi cosa, esegui un clone Git di questo repository localmente. In questo modo lo fai una volta.
Naturalmente ci sono molti aspetti negativi. Ad esempio, non è possibile utilizzare il controllo delle versioni. E a volte è difficile convivere con questo.
Seconda soluzione. Se hai molti sottomoduli e hai già una sorta di pipeline consolidata, allora c'è il progetto MBT, che ti consente di raccogliere molti pacchetti diversi da un monorepository e caricarli su S3. Questo è un ottimo modo. Pertanto, il file iam-user-1.0.0.zip peserà solo 1 Kb, perché il codice per creare questa risorsa è molto piccolo. E funzionerà molto più velocemente.
Parliamo di ciò che non può essere utilizzato nei moduli.
Perché c'è questo male nei moduli? La cosa peggiore è dare per scontato che user. Supponiamo che l'utente sia un'opzione di autenticazione del provider che può essere utilizzata da persone diverse. Ad esempio, assimileremo tutti il ruolo. Ciò significa che Terraform assumerà questo ruolo. E poi con questo ruolo eseguirà altre azioni.
E il male è che se a Vasya piace connettersi ad Amazon in un modo, ad esempio, utilizzando la variabile d'ambiente predefinita, e a Petya piace usare la sua chiave condivisa, che ha in un luogo segreto, allora non puoi specificare entrambi in Terraformare. E affinché non provino sofferenza, non è necessario indicare questo blocco nel modulo. Questo deve essere indicato a un livello più alto. Cioè, abbiamo un modulo risorse, un modulo infrastruttura e una composizione in cima. E questo dovrebbe essere indicato da qualche parte più in alto.
Il secondo male è l’approvvigionamento. Qui il male non è così banale, perché se scrivi codice e funziona per te, allora potresti pensare che se funziona, allora perché cambiarlo.
Il male è che non sempre puoi controllare quando verrà lanciato questo provisioning, in primo luogo. E in secondo luogo, non controlli cosa significhi aws ec2, ovvero stiamo parlando di Linux o Windows adesso. Quindi non puoi scrivere qualcosa che funzioni allo stesso modo su diversi sistemi operativi o per diversi casi utente.
L'esempio più comune, che è indicato anche nella documentazione ufficiale, è che se scrivi aws_instance e specifichi una serie di argomenti, non c'è niente di sbagliato se specifichi lì il provisioner "local-exec" ed esegui il tuo ansible- playbook.
In effetti sì, non c'è niente di sbagliato in questo. Ma letteralmente presto ti renderai conto che questa cosa local-exec non esiste, ad esempio, in launch_configuration.
E quando usi launch_configuration e desideri creare un gruppo di scalabilità automatica da un'istanza, in launch_configuration non esiste il concetto di "provisioner". Esiste il concetto di “dati utente”.
Pertanto, una soluzione più universale è utilizzare i dati degli utenti. E verrà avviato sull'istanza stessa, quando l'istanza è accesa, o negli stessi dati utente, quando il gruppo di scalabilità automatica utilizza questo launch_configuration.
Se desideri comunque eseguire il provisioner, poiché è un componente di collegamento, quando viene creata una risorsa, in quel momento devi eseguire il provisioner, il tuo comando. Ci sono molte di queste situazioni.
E la risorsa più corretta per questo si chiama null_resource. Null_resource è una risorsa fittizia che non viene mai effettivamente creata. Non tocca nulla, nessuna API, nessuna scalabilità automatica. Ma ti consente di controllare quando eseguire il comando. In questo caso, il comando viene eseguito durante la creazione.
Collegamento
Ci sono diversi segnali. Non entrerò in tutti i segni in grande dettaglio. C'è un articolo su questo. Ma se hai lavorato con Terraform o utilizzato moduli di altre persone, avrai spesso notato che molti moduli, come la maggior parte del codice open source, sono scritti da persone per le proprie esigenze. Un uomo lo scrisse e risolse il suo problema. L'ho bloccato su GitHub, lascialo vivere. Vivrà, ma se non ci sono documentazione ed esempi lì, nessuno lo utilizzerà. E se non esiste alcuna funzionalità che ti permetta di risolvere qualcosa di più del suo compito specifico, allora nessuno la utilizzerà neanche. Esistono tanti modi per perdere utenti.
Se vuoi scrivere qualcosa in modo che le persone lo usino, allora ti consiglio di seguire questi segnali.
È Questo:
- Documentazione ed esempi.
- Funzionalità completa.
- Impostazioni predefinite ragionevoli.
- Codice pulito.
- Test.
I test sono una situazione diversa perché sono piuttosto difficili da scrivere. Credo di più nella documentazione e negli esempi.
Quindi, abbiamo esaminato come scrivere i moduli. Ci sono due argomenti. Il primo, che è il più importante, è non scrivere se puoi, perché un gruppo di persone ha già svolto questi compiti prima di te. E in secondo luogo, se decidi ancora, prova a non utilizzare i provider nei moduli e nei provisioner.
Questa è la parte grigia della documentazione. Ora potresti pensare: “Qualcosa non è chiaro. Non convinto." Ma vedremo tra sei mesi.
Ora parliamo di come chiamare questi moduli.
Comprendiamo che il nostro codice cresce nel tempo. Non abbiamo più un file, abbiamo già 20 file. Sono tutti in una cartella. O forse cinque cartelle. Forse stiamo iniziando in qualche modo a suddividerli per regione, per alcune componenti. Allora capiamo che ora abbiamo alcuni rudimenti di sincronizzazione e orchestrazione. Cioè, dobbiamo capire cosa dovremmo fare se cambiassimo le risorse di rete, cosa dovremmo fare con il resto delle nostre risorse, come causare queste dipendenze, ecc.
Ci sono due estremi. Il primo estremo è tutto in uno. Abbiamo un file principale. Per il momento, questa era la procedura consigliata ufficiale sul sito Web Terraform.
Ma ora è scritto come deprecato e rimosso. Nel corso del tempo, la comunità Terraform si è resa conto che questa era ben lungi dall'essere la pratica migliore, perché le persone hanno iniziato a utilizzare il progetto in modi diversi. E ci sono problemi. Ad esempio, quando elenchiamo tutte le dipendenze in un unico posto. Ci sono situazioni in cui facciamo clic su "Piano Terraform" e finché Terraform non aggiorna gli stati di tutte le risorse, può passare molto tempo.
Un sacco di tempo è, ad esempio, 5 minuti. Per alcuni questo è molto tempo. Ho visto casi in cui ci sono voluti 15 minuti. L'API AWS ha impiegato 15 minuti cercando di capire cosa stava succedendo con lo stato di ciascuna risorsa. Questa è un'area molto vasta.
E, naturalmente, apparirà un problema correlato quando desideri modificare qualcosa in un posto, quindi aspetti 15 minuti e ti verrà fornita una tela di alcune modifiche. Hai sputato, hai scritto "Sì" e qualcosa è andato storto. Questo è un esempio molto reale. Terraform non cerca di proteggerti dai problemi. Cioè, scrivi quello che vuoi. Ci saranno problemi: i tuoi problemi. Mentre Terraform 0.11 non sta cercando di aiutarti in alcun modo. Ci sono alcuni posti interessanti in 0.12 che ti permettono di dire: "Vasya, lo vuoi davvero, puoi tornare in te?"
Il secondo modo è ridurre quest'area, ovvero le chiamate da un luogo possono essere meno connesse da un altro luogo.
L'unico problema è che devi scrivere più codice, cioè devi descrivere le variabili in un gran numero di file e aggiornarlo. Ad alcune persone non piace. Questo è normale per me. E alcune persone pensano: "Perché scrivere questo in posti diversi, lo metterò tutto in un unico posto". Questo è possibile, ma questo è il secondo estremo.
Chi vive tutto questo in un unico posto? Una, due, tre persone, cioè qualcuno lo sta usando.
E chi chiama un determinato componente, un blocco o un modulo dell'infrastruttura? Da cinque a sette persone. Questo è bello.
La risposta più comune è da qualche parte nel mezzo. Se il progetto è grande, spesso ti troverai in una situazione in cui nessuna soluzione è adatta e non tutto funziona, quindi ti ritroverai con un miscuglio. Non c'è niente di sbagliato in questo, purché tu capisca che entrambi hanno dei vantaggi.
Se qualcosa è cambiato nello stack VPC e desideri applicare queste modifiche a EC2, ovvero desideri aggiornare il gruppo di scalabilità automatica perché avevi una nuova sottorete, allora chiamo questo tipo di orchestrazione delle dipendenze. Esistono alcune soluzioni: chi usa cosa?
Posso suggerire quali soluzioni ci sono. Puoi usare Terraform per fare la magia oppure puoi usare makefile per usare Terraform. E vedi se qualcosa è cambiato lì, puoi avviarlo qui.
Ti piace questa decisione? Qualcuno crede che questa sia una soluzione interessante? Vedo un sorriso, a quanto pare si sono insinuati dei dubbi.
Naturalmente, non provarlo a casa. Terraform non è mai stato progettato per essere eseguito da Terraform.
Ad un rapporto mi hanno detto: “No, non funzionerà”. Il punto è che non dovrebbe funzionare. Anche se sembra così impressionante quando puoi avviare Terraform da Terraform e poi da Terraform, non dovresti farlo. Terraform dovrebbe sempre avviarsi molto facilmente.
Se hai bisogno dell'orchestrazione delle chiamate quando qualcosa è cambiato in un posto, allora c'è Terragrunt.
Terragrunt è un'utilità, un componente aggiuntivo di Terraform, che consente di coordinare e orchestrare le chiamate ai moduli dell'infrastruttura.
Un tipico file di configurazione Terraform è simile al seguente.
Specifica quale modulo specifico vuoi chiamare.
Quali dipendenze ha il modulo?
E quali argomenti accetta questo modulo. Questo è tutto quello che c'è da sapere su Terragrunt.
La documentazione c'è e ci sono 1 stelle su GitHub. Ma nella maggior parte dei casi questo è ciò che devi sapere. E questo è molto facile da implementare nelle aziende che stanno appena iniziando a lavorare con Terraform.
Quindi l'orchestrazione è Terragrunt. Ci sono altre opzioni.
Ora parliamo di come lavorare con il codice.
Se devi aggiungere nuove funzionalità al tuo codice, nella maggior parte dei casi è semplice. Stai scrivendo una nuova risorsa, tutto è semplice.
Se hai qualche risorsa che hai creato in anticipo, ad esempio, hai conosciuto Terraform dopo aver aperto un account AWS e desideri utilizzare le risorse che già possiedi, allora sarebbe opportuno estendere il tuo modulo in questo modo, in modo che sostiene l'uso delle risorse esistenti.
E ha supportato la creazione di nuove risorse utilizzando la risorsa blocco.
In output restituiamo sempre l'id di output a seconda di cosa è stato utilizzato.
Il secondo problema molto significativo in Terraform 0.11 riguarda il lavoro con gli elenchi.
La difficoltà è che se disponiamo di un simile elenco di utenti.
E quando creiamo questi utenti utilizzando la risorsa blocco, tutto va bene. Esaminiamo l'intero elenco, creando un file per ciascuno. Va tutto bene. E poi, ad esempio, l'utente3, che è al centro, dovrebbe essere rimosso da qui, quindi tutte le risorse create dopo di lui verranno ricreate perché l'indice cambierà.
Utilizzo degli elenchi in un ambiente con stato. Cos'è un ambiente con stato? Questa è la situazione in cui viene creato un nuovo valore quando viene creata questa risorsa. Ad esempio, AWS Access Key o AWS Secret Key, ovvero quando creiamo un utente, riceviamo una nuova chiave di accesso o segreta. E ogni volta che eliminiamo un utente, questo utente avrà una nuova chiave. Ma questo non è feng shui, perché l'utente non vorrà essere nostro amico se creiamo per lui un nuovo utente ogni volta che qualcuno lascia la squadra.
Questa è la soluzione. Questo è il codice scritto in Jsonnet. Jsonnet è un linguaggio di template di Google.
Questo comando ti consente di accettare questo modello e come output restituisce un file json creato in base al tuo modello.
Il modello è simile a questo.
Terraform ti consente di lavorare sia con HCL che con Json allo stesso modo, quindi se hai la possibilità di generare Json, puoi inserirlo in Terraform. Il file con estensione .tf.json verrà scaricato correttamente.
E poi lo lavoriamo come al solito: terraform init, terramorm apply. E creiamo due utenti.
Adesso non abbiamo paura se qualcuno lascia la squadra. Modificheremo semplicemente il file json. Vasya Pupkin se ne andò, Petya Pyatochkin rimase. Petya Pyatochkin non riceverà una nuova chiave.
L'integrazione di Terraform con altri strumenti non è realmente il lavoro di Terraform. Terraform è stato creato come piattaforma per la creazione di risorse e basta. E tutto ciò che emerge in seguito non riguarda Terraform. E non c'è bisogno di intrecciarlo lì. C'è Ansible, che fa tutto ciò di cui hai bisogno.
Ma si verificano situazioni in cui vogliamo estendere Terraform e richiamare qualche comando dopo che qualcosa è stato completato.
Primo modo. Creiamo un output in cui scriviamo questo comando.
Quindi chiamiamo questo comando dall'output della shell terraform e specifichiamo il valore che vogliamo. Pertanto, il comando viene eseguito con tutti i valori sostituiti. È molto comodo
Secondo modo. Questo è l'uso di null_resource a seconda dei cambiamenti nella nostra infrastruttura. Possiamo chiamare lo stesso local-exe non appena l'ID di alcune risorse cambia.
Naturalmente tutto questo va liscio sulla carta, perché Amazon, come tutti gli altri fornitori pubblici, ha una serie di casi limite.
Il caso limite più comune è che quando apri un account AWS, è importante quali regioni utilizzi; questa funzione è abilitata lì; forse l'hai aperto dopo dicembre 2013; forse stai utilizzando l'impostazione predefinita in VPC ecc. Esistono molte restrizioni. E Amazon li ha sparsi in tutta la documentazione.
Ci sono alcune cose che consiglio di evitare.
Per iniziare, evita tutti gli argomenti non segreti all'interno del piano Terraform o della CLI Terraform. Tutto questo può essere inserito in un file tfvars o in una variabile d'ambiente.
Ma non è necessario memorizzare l'intero comando magico. Piano Terraform: var e si parte. La prima variabile è var, la seconda variabile è var, la terza, la quarta. Il principio più importante dell'infrastruttura come codice che utilizzo più spesso è che semplicemente guardando il codice, dovrei avere una chiara comprensione di cosa viene distribuito lì, in quale stato e con quali valori. E quindi non devo leggere la documentazione o chiedere a Vasya quali parametri ha utilizzato per creare il nostro cluster. Devo solo aprire un file con l'estensione tfvars, che spesso corrisponde all'ambiente, e guardare tutto lì.
Inoltre, non utilizzare argomenti di destinazione per ridurre l'ambito. Per questo è molto più semplice utilizzare piccoli moduli infrastrutturali.
Inoltre, non è necessario limitare e aumentare il parallelismo. Se ho 150 risorse e voglio aumentare il parallelismo di Amazon dal valore predefinito da 10 a 100, molto probabilmente qualcosa andrà storto. Oppure potrebbe andare bene adesso, ma quando Amazon ti dirà che stai facendo troppe chiamate, sarai nei guai.
Terraform tenterà di riavviare la maggior parte di questi problemi, ma non otterrai quasi nulla. Parallelism=1 è una cosa importante da utilizzare se ti imbatti in qualche bug all'interno dell'API AWS o all'interno del provider Terraform. E poi devi specificare: parallelism=1 e attendere finché Terraform non termina una chiamata, poi la seconda, poi la terza. Li lancerà uno per uno.
Le persone spesso mi chiedono: "Perché penso che gli spazi di lavoro Terraform siano malvagi?" Credo che il principio dell’infrastruttura come codice sia vedere quale infrastruttura è stata creata e con quali valori.
Gli spazi di lavoro non sono stati creati dagli utenti. Ciò non significa che gli utenti abbiano scritto su GitHub che non possiamo vivere senza gli spazi di lavoro Terraform. No, non così. Terraform Enterprise è una soluzione commerciale. Terraform di HashiCorp ha deciso che avevamo bisogno di spazi di lavoro, quindi l'abbiamo archiviato. Trovo molto più semplice inserirlo in una cartella separata. Poi ci saranno un po' più di file, ma sarà più chiaro.
Come lavorare con il codice? In effetti, lavorare con gli elenchi è l'unico problema. E prendi Terraform più facilmente. Questa non è la cosa che farà tutto alla grande per te. Non è necessario spingere lì tutto ciò che è scritto nella documentazione.
L’argomento del rapporto è stato scritto “per il futuro”. Ne parlerò molto brevemente. Per il futuro, ciò significa che la versione 0.12 verrà rilasciata presto.
0.12 contiene tantissime novità. Se provieni dalla programmazione regolare, ti perdi tutti i tipi di blocchi dinamici, loop, operazioni di confronto corrette e condizionali, in cui i lati sinistro e destro non vengono calcolati contemporaneamente, ma a seconda della situazione. Ti manca molto, quindi 0.12 lo risolverà per te.
Ma! Se scrivi sempre più semplicemente, utilizzando moduli già pronti e soluzioni di terze parti, non dovrai aspettare e sperare che arrivi 0.12 e sistemi tutto per te.
Grazie per la segnalazione! Hai parlato di infrastruttura come codice e hai detto letteralmente una parola sui test. Sono necessari test nei moduli? Di chi è questa responsabilità? Devo scriverlo io o è responsabilità dei moduli?
Il prossimo anno sarà pieno di rapporti che abbiamo deciso di testare tutto. Cosa testare è la domanda più grande. Ci sono molte dipendenze e molte restrizioni da parte di diversi fornitori. Quando tu ed io parliamo e dici: "Ho bisogno di test", allora chiedo: "Cosa testerai?" Dici che effettuerai il test nella tua regione. Poi dico che nella mia regione questo non funziona. Cioè, non saremo nemmeno in grado di essere d'accordo su questo. Senza contare che ci sono molti problemi tecnici. Cioè come scrivere questi test in modo che siano adeguati.
Sto ricercando attivamente questo argomento, ovvero come generare automaticamente test in base all'infrastruttura che hai scritto. Cioè, se hai scritto questo codice, allora devo eseguirlo, in base a questo posso creare dei test.
è una delle librerie citate più frequentemente che consente di scrivere test di integrazione per Terraform. Questa è una delle utilità. Preferisco il tipo DSL, ad esempio rspec.
Anton, grazie per la segnalazione! Mi chiamo Valery. Vorrei fare una piccola domanda filosofica. C'è, condizionatamente, il provisioning, c'è la distribuzione. Il provisioning crea la mia infrastruttura, durante la distribuzione la riempiamo con qualcosa di utile, ad esempio server, applicazioni, ecc. Ed è nella mia testa che Terraform sia più per il provisioning e Ansible sia più per la distribuzione, perché Ansible è anche per l'infrastruttura fisica ti permette di installare nginx, Postgres. Ma allo stesso tempo Ansible sembra consentire il provisioning, ad esempio, di risorse Amazon o Google. Ma Terraform ti consente anche di distribuire alcuni software utilizzando i suoi moduli. Dal tuo punto di vista, esiste una sorta di confine che corre tra Terraform e Ansible, dove e cosa è meglio usare? Oppure, ad esempio, pensi che Ansible sia già spazzatura, dovresti provare a usare Terraform per tutto?
Bella domanda, Valery. Credo che Terraform non sia cambiato in termini di scopo dal 2014. È stato creato per le infrastrutture ed è morto per le infrastrutture. Avevamo ancora e avremo bisogno della gestione della configurazione Ansible. La sfida è che ci sono dati utente all'interno di launch_configuration. E lì prendi Ansible, ecc. Questa è la distinzione standard che mi piace di più.
Se parliamo di belle infrastrutture, allora ci sono utility come Packer che raccolgono questa immagine. Quindi Terraform utilizza l'origine dati per trovare questa immagine e aggiornarne launch_configuration. Cioè, in questo modo la pipeline prevede che prima estraiamo Tracker, quindi estraiamo Terraform. E se si verifica la creazione, si verifica un nuovo cambiamento.
Ciao! Grazie per la segnalazione! Mi chiamo Misha, società RBS. Puoi chiamare Ansible tramite provisioner durante la creazione di una risorsa. Ansible ha anche un argomento chiamato inventario dinamico. E puoi prima chiamare Terraform e poi chiamare Ansible, che prenderà risorse dallo stato e lo eseguirà. Cosa c'è di meglio?
Le persone usano entrambi con uguale successo. Mi sembra che l'inventario dinamico in Ansible sia una cosa conveniente, se non si tratta di un gruppo di scalabilità automatica. Perché nel gruppo di scalabilità automatica abbiamo già il nostro toolkit, chiamato launch_configuration. In launch_configuration registriamo tutto ciò che deve essere lanciato quando creiamo una nuova risorsa. Pertanto, con Amazon, l'utilizzo dell'inventario dinamico e la lettura del file Terraform ts, a mio avviso, è eccessivo. E se usi altri strumenti in cui non esiste il concetto di "gruppo di scalabilità automatica", ad esempio, usi DigitalOcean o qualche altro provider in cui non esiste un gruppo di scalabilità automatica, allora dovrai estrarre manualmente l'API, trovare indirizzi IP, creare un file di inventario dinamico e Ansible lo esplorerà già. Cioè, per Amazon c'è launch_configuration e per tutto il resto c'è l'inventario dinamico.
Fonte: habr.com