Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Tipo | Descrizione | Disponibilità |
---|---|---|
Tipo | Descrizione | Disponibilità |
---|---|---|
Poche risorse, nessuna dipendenza esterna. Un solo AWS account. Una sola Regione. Un solo ambiente.
Si
Più account AWS e ambienti, moduli standard di infrastruttura Terraform.
Si
Molti accounts AWS, molte regioni, importanza di ridurre il copia-incolla, moduli di infrastruttura personalizzati , pesante uso di composizioni. Uso di Terraform.
Non ancora disponibile
molto-grande
Più providers (AWS, GCP, Azure). Deploy Multi-cloud. Uso di Terraform.
No
medio
Diversi account AWS e ambienti, moduli di infrastruttura standard, pattern di composizione usando Terragrunt.
No
large
Molti accounts AWS, molte regioni, importanza di ridurre il copia-incolla, moduli di infrastruttura personalizzati , pesante uso di composizioni. Uso di Terragrunt.
No
very-large
Più providers (AWS, GCP, Azure). Deploy Multi-cloud. Uso di Terragrunt.
No
Questo esempio contiene codice per la strutturazione delle configurazioni Terraform per un infrastruttura di piccole dimensioni, dove non sono usate dipendenze esterne.
Perfetto per iniziare e fare la rifattorizzazione mentre procedi.
Perfetto per moduli con poche risorse
Buono per un piccolo numero di risorse (meno di 20-30)
Un singolo file di stato per tutte le risorse, può rendere il processo di esecuzione di Terraform lento se il numero di risorse é in crescita (considera l'uso dell'argomento -target
per limitare il numero di risorse)
Sorgente:
Buono per moduli di infrastrutture piccoli e lineari come (per esempio, )
Questo documento è un tentativo di descrivere le best practices nell'uso di Terraform e fornire suggerimenti per i problemi che accadono più frequentemente nell'uso di Terraform.
Terraform é un nuovo progetto (come la maggior parte degli strumenti di DevOps) inizato nel 2014.
Terraform é un potente (se non il piú potente disponibile al momento) e uno dei tool più usati, che permette l'approccio infrastruttura come codice. Abilita agli sviluppatori di fare molte cose, e non li limita a fare cose in un modo che è difficile da supportare o integrare con altri strumenti.
Alcune informazioni descritte in questo libro potrebbero non sembrare delle best practices. Voglio distinguere cosa sono delle best practices certe e stabilite e cosa invece sono opinioni. Alcune volte userò note per specificare meglio il contesto e icone per il livello di maturitá di ogni sottosezione.
Il libro é iniziato nel 2018 in una soleggiata Madrid ed é disponibile gratuitamente qui - https://www.terraform-best-practices.com/ .
Qualche anno dopo é sto aggiornato con alcune delle piú recenti best practices in Terraform 1.0. Infine, questo libro dovrebbe contenere alcune delle più indiscutibili best practices e raccomandazioni per utenti di Terraform.
Nota del traduttore: sono stato molto combattuto (e ho chiesto consiglio ad altre persone che come me lavorano nell'informatica) se tradurre best practices oppure no. Alla fine ho deciso che le "pratiche migliori" , o "stato dell'arte", "pratiche buone" non rendeva bene il termine e quindi l'ho lasciato in inglese.
Please contact me if you want to become a sponsor.
Contattami se vuoi tradurre il libro in altre lingue.
Sono sempre alla ricerca di feedback e desidero aggiornare questo libro con il maturare della comunity. Nuove idee e implementazioni verranno valutate e verificate.
Se sei interessato in alcuni argomenti per favore fai una richiesta (open an issue), oppure mettipi un mi piace su una giá aperta a cui sei interessato. Se credi di porter fornire contenuti e vuoi contribuire, scrivi una bozza e manda una pull request (non preoccuparti di scrivere del buon contenuto in questa fase!)
Questo libro é mantenuto da Anton Babenko con l'aiuto di diversi traduttori e collaboratori.
Questo contenuto é sotto la licenza Apache 2. Controlla LICENSE per maggiori dettagli.
Gli autori e i collaboratori di questo contenuto non possono garantire la validitá delle informazioni. Per favore assicurati di capire che le informazioni fornite qui sono date in maniera gratuita, non c'é nessuno accordo o contratto tra te e ogni persona associata al contenuto e al progetto. Gli autori e i collaboratori non si assumano e con la presente declinano qualsivoglia responsabilitá a ogni parte per qualsiasi perdita, danneggiamento o discontinuitá causata da errori o omissioni nelle informazioni contenute, associate o collegate a questo contenuto, sia che siano errori o omissioni causate da negligenza, o qualsiasi altra causa.
Copyright © 2018-2023 Anton Babenko.
Questo esempio contiene codice per strutturare configurazioni Terraform per infrastrutture di grandi dimensioni che usano:
2 account AWS
2 regioni
2 ambienti separati (prod
e stage
che non hanno niente in condivisione). Ogni ambiente vive in un account AWS separato e si distribuisce tra 2 regioni
Ogni ambiente usa la stessa versione del modulo interno modules/network
dato che la sorgente di questo è una directory locale.
Perfetto per progetti dove l'infrastruttura é separata logicamente (account AWS separati)
Adatto dove non c'é necessità di modificare risorse condivise tra account AWS ( un ambiente = un account AWS = un file di stato)
Adatto dove non c'é necessità di orchestrare cambiamenti tra ambienti.
Adatto dove le risorse di infrastruttura sono intenzionalmente diverse per ambiente e non possono essere generalizzate. (esempio, alcune risorse sono assenti in un ambiente o in alcune regioni)
Quando il progetto crescerà, sarà più difficile tenere questi ambienti aggiornati uno con l'altro. Considera l'uso dei moduli infrastruttura (dallo scaffale o interni) per attività che si ripetono.
Questo esempio contiene codice per strurtturare le configurazioni Terraform per infrastture di dimensioni medie che usano:
2 account AWS
2 ambienti separati (prod
e stage
che non hanno niente in condivisione). Ogni ambiente vive in un account AWS separato
Ogni ambiente usa la stessa versione del modulo interno modules/network
dato che la sorgente di questo è una directory locale.
Perfetto per progetti dove l'infrastruttura é separata logicamente (account AWS separati)
Adatto dove non c'é necessità di modificare risorse condivise tra account AWS ( un ambiente = un account AWS = un file di stato)
Adatto dove non c'é necessità di orchestrare cambiamenti tra ambienti.
Adatto dove le risorse di infrastruttura sono intenzionalmente diverse per ambiente e non possono essere generalizzate. (esempio, alcune risorse sono assenti in un ambiente o in alcune regioni)
Con la crescita del progetto, diventerà difficile tenere questi ambienti aggiornati l'uno con l'altro. Va considerato l'uso di moduli di infrastruttura (dallo scaffale o interni) per task ripetibili.
Le domande collegate alla strutturazione del codice Terraform sono le piú frequenti nella community. Tutti hanno pensato alla migliore maniera per strutturare il codice a un certo punto del progetto.
Questa è una delle domande dove sono presenti molte soluzioni, è molto difficile dare un consiglio universale, andiamo a capire meglio con cosa abbiamo a che fare.
Qual'è la complessitá del tuo progetto?
Numero di risorse collegate
Numero di provider Terraform (guarda la nota sotto sui "provider logici" )
Con che frequenza cambia la tua infrastruttura Terraform?
Da una volta a mese/settimana/giorno
A continuamente (ogni volta quando c'e' un nuovo commit)
Un cambiamento del codice può scatenare un aggiornamento? É permesso al CI server di aggiornare i repository quando viene fatto il build di un nuovo artefatto?
Solo gli sviluppatori possono fare il push al repository di infrastruttura
Tutti possono proporre un cambiamento a qualsiasi parte del progetto aprendo una PR ( includendo i task automatici che girano sul server CI)
Quale piattaforma o servizio usi per il deployment?
AWS CodeDeploy, Kubernetes, o OpenShift richiedono degli approcci leggermente differenti
Come sono raggruppati il ambienti?
Per ambiente, regione, progetto
Mettere tutto il codice dentro il file main.tf
é una buona idea quando si sta cominciando o si sta scrivendo un codice di esempio. In tutti gli altri casi é meglio avere più file divisi logicamente in questo modo:
main.tf
- chiamate ad altri moduli, locals, e data sources per creare altre risorse
variables.tf
- contiene dichiarazioni di variabili usate dentro main.tf
outputs.tf
- contiene outputs di risorse create dentro main.tf
versions.tf
- contiene le versioni richieste per Terraform per per i providers
È piu facile e veloce lavorare con un numero di risorse piccolo.
terraform plan
e terraform apply
eseguono delle chiamate API cloud per verificare lo stato delle risorse.
Se si ha l'intera infrastruttura in una composizione singola fare queste chiamate API puó richiedere molto tempo.
I danni a causati di un evento catastrofico sono minori con meno risorse.
Isolare risorse non collegate mettendole in composizioni separate riduce il rischio in caso qualcosa vada male.
Inizia il progetto usando lo stato remoto perchè :
Il laptop non è il posto per tenere la "fonte della verità" riguardo all'infrastruttura.
Amministrare il file tfstate
in git é un incubo
Quando l'infrastruttura crescerà in direzioni multiple (aumentando il numero di risorse e dipendenze) sarà piú facile tenere tutto sotto controllo.
Come il codice procedurale, il codice Terraform dovrebbe essere scritto per essere letto dalle persone in prima istanza, la consistenza aiuterà quando ci sarà da fare cambiamenti dopo sei mesi.
È possibile spostare le risorse tra i file di stato di Terraform ma non sarà semplice se avrai una struttura di codice e un naming non consistente.
Tieni le risorse nei moduli nella maniera più pulita possibile.
Non fare hardcode di valori che possono essere passati come variabili o scoperti usando data sources
Usa data sources e terraform_remote_state
come una colla tra moduli di infrastruttura con diverse composizioni.
In questo libro, gli esempi dei progetti sono raggruppati per complessità - dall'infrastruttura più piccola a quella più grande. Anche se la separazione non é restrittiva.
Avere un'infrastruttura piccola significa un numero di dipendenze minori e poche risorse. Quando il progetto cresce, anche la necessità di collegare l'esecuzione di configurazioni Terraform, connettere moduli di infrastruttura diversi, e passare valori con composizioni diventa ovvia.
Ci sono almeno 5 gruppi distinti di soluzioni di orchestrazione che uno sviluppatore usa:
Solo Terraform. Approccio diretto, gli sviluppatori devono conoscere solo Terraform per compiere il lavoro.
Terragrunt. Un tool di orchestrazione puro, che può essere usato per orchestrare l'intera infrastruttura e gestire le dipendenze. Terragrunt opera con moduli di infrastruttura e composizioni native, in questo modo riduce la duplicazione del codice.
Scripts personalizzati. Spesso accade come punto di partenza verso l'orchestrazione e prima di scoprire Terragrunt.
Ansible o tool simili di automazione. Solitamente quando Terraform viene adottato dopo Ansible, o quando è usata la UI di Ansible.
Tenendo presente tutto questo, il libro rivede i primi due approcci Terraform da solo oppure con Terragrunt.
Sorgente:
Ogni ambiente usa una versione differente del moduleo di infrastruttura off-the-shelf infrastructure module (alb
) con sorgente
In un progetto grande come quello descritto i benefici di usare Terragrunt diventano molto evidenti. Vedi .
Sorgente:
Ogni ambiente usa una versione differente del moduleo di infrastruttura dallo scaffale infrastructure module (alb
) con sorgente
I provider logici lavorano interamente con la logica Terraform e spesso non interagiscono con altri servizi, pensiamo alla loro complessità come O(1). I provider logici più comuni sono , , , , .
terraform.tfvars
non dovrebbe essere mai usato eccetto nelle .
Per favore assicurati di aver capito i concetti chiave - , , e , dato che verranno usati negli esempi seguenti.
Fai pratica usando una struttura del codice consistente e una :
e altre solutioni ispiriate a Kubernetes. Alcune volte ha senso utilizzare l'ecosistema Kubernets e impiegare un "reconciliation loop feature" per raggiungere lo stato desiderato della nostra configurazione Terraform. Guarda il video per avere più informazioni.
Guarda gli esempi e la strutturazione del codice per o nel prossimo capitolo.