1 of 6

Esempi di strutturazione del codice

Struttura del codice Terraform

Questi esempi sono realizzati con il provider AWS ma la maggior parte dei principi mostrati possono essere applicati anche ad altri provider cloud e non (DNS, DB, Monitoring, ecc)

Tipo

Descrizione

Disponibilità

Terragrunt code structures

Tipo

Descrizione

Disponibilità

Terragrunt

Terraform

Terraform per infrastrutture di piccole dimensioni

Sorgente: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform

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 moduli di infrastrutture piccoli e lineari come (per esempio, terraform-aws-atlantis)
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)

Terraform per infrastrutture di media dimensione

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.

Terraform per infrastrutture di grandi dimensioni

Sorgente: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform

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 una versione differente del moduleo di infrastruttura off-the-shelf infrastructure module (alb) con sorgenteTerraform Registry
Ogni ambiente usa la stessa versione del modulo interno modules/network dato che la sorgente di questo è una directory locale.

In un progetto grande come quello descritto i benefici di usare Terragrunt diventano molto evidenti. Vedi Code Structures examples with Terragrunt.

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.

Terraform per infrastrutture di grandi dimensioni

Sorgente: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform

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 una versione differente del moduleo di infrastruttura off-the-shelf infrastructure module (alb) con sorgenteTerraform Registry
Ogni ambiente usa la stessa versione del modulo interno modules/network dato che la sorgente di questo è una directory locale.

In un progetto grande come quello descritto i benefici di usare Terragrunt diventano molto evidenti. Vedi Code Structures examples with Terragrunt.

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)

Terraform per infrastrutture di media dimensione

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)