Struttura del codice Terraform

Terragrunt code structures

Questo esempio contiene codice per la strutturazione delle configurazioni Terraform per un infrastruttura di piccole dimensioni, dove non sono usate dipendenze esterne.

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.

Sponsors

Please contact me if you want to become a sponsor.

Traduzioni

Contattami se vuoi tradurre il libro in altre lingue.

Contributi

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!)

Autori

Questo libro é mantenuto da Anton Babenko con l'aiuto di diversi traduttori e collaboratori.

Licenza

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.

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.

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.

Come dovrei strutturare le mie configurazioni Terraform?

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

Cominciamo a strutturare le configurazioni Terraform.

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

Come organizzare la struttura delle configurazioni Terraform?

Raccomandazioni per la struttura del codice.

• È 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.

Orchestrazione di moduli infrastruttura e composizioni.

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:

1. Solo Terraform. Approccio diretto, gli sviluppatori devono conoscere solo Terraform per compiere il lavoro.

2. 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.

3. Scripts personalizzati. Spesso accade come punto di partenza verso l'orchestrazione e prima di scoprire Terragrunt.

4. 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.