Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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)
Tipo | Descrizione | Disponibilità |
---|---|---|
Tipo | Descrizione | Disponibilità |
---|---|---|
Sorgente:
Buono per moduli di infrastrutture piccoli e lineari come (per esempio, )
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
Sorgente: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform
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 una versione differente del moduleo di infrastruttura dallo scaffale infrastructure module (alb
) con sorgente Terraform Registry
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.
Esempi di moduli Terraform dovrebbero contenere la documentazione che spiega le features e come usarle.
Tutti i links nel README.md dovrebbero essere con path assoluti per fare in modo che il sito web Terraform Registry li mostri correttamente.
La documentation può includere diagrammi creati con mermaid e blueprints creati con cloudcraft.co.
Usa i Terraform pre-commit hooks per essere sicuri che il codice è valido, correttamente formattato e automaticamente documentation prima che venga pushato in git e controllato da altri sviluppatori.
pre-commit è un framework per amministrare e mantenere hooks per linguaggi multipli. È scritto in Python ed è un tool potente per fare qualcosa automaticamente sulla macchina dello sviluppatore prima che il codice venga committato sul repository git. Normalmente, è usato per far girare linters e formattare il codice (vedi supported hooks).
Con le configurazioni Terraform pre-commit
può essere usato per formattare e validare il codice, come per aggiornare la documentatione.
Dai un'occhiato al repository pre-commit-terraform per prendere confidenza e anche ai repositories (eg, terraform-aws-vpc) dov'è già usato.
terraform-docs è un tool che genera la documentaione dei moduli Terraform in vari formati di output. Puoi farlo girare manualmente (senza pre-commit hooks), oppure usare pre-commit-terraform hooks per fare in modo che la documentazione si aggiorni automaticamente.
@todo: Document module versions, release, GH actions
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.
È disponibile un workshop per chi volesse fare pratica con quello descritto in questa guida.
Il contenuto è disponibile qui -