Best practice per i moduli principali

Questo documento fornisce linee guida e consigli da prendere in considerazione quando si utilizzano i moduli principali.

Le configurazioni principali o i moduli principali sono le directory di lavoro da cui eseguire l'interfaccia a riga di comando di Terraform. Assicurati che le configurazioni principali rispettino i seguenti standard (e le linee guida di Terraform precedenti, se applicabili). I suggerimenti espliciti per i moduli principali hanno la precedenza sulle linee guida generali.

Questa guida non è un'introduzione a Terraform. Per un'introduzione all'utilizzo di Terraform con Google Cloud, consulta Introduzione a Terraform.

Riduci al minimo il numero di risorse in ogni modulo principale

È importante evitare che una singola configurazione principale diventi troppo grande, con troppe risorse archiviate nella stessa directory e nello stesso stato. Tutte le risorse in un e una particolare configurazione root vengono aggiornate ogni volta che viene eseguito Terraform. Ciò può causare un'esecuzione lenta se in un singolo stato sono incluse troppe risorse. R Regola generale: non includere più di 100 risorse (idealmente solo dozzine) in un unico stato.

Usa directory separate per ogni applicazione

Per gestire applicazioni e progetti in modo indipendente l'uno dall'altro, inserisci le risorse per ogni applicazione e progetto nelle rispettive directory Terraform. Un servizio potrebbe rappresentare una determinata applicazione o un servizio comune come la condivisione della rete. Raggruppa tutto il codice Terraform per un determinato servizio in una directory (incluse le sottodirectory).

Suddividi le applicazioni in sottodirectory specifiche per l'ambiente

Quando esegui il deployment di servizi in Google Cloud, suddividi Terraform del servizio in due directory di primo livello: un modules che contiene la configurazione effettiva del servizio e una environments directory che contiene le configurazioni principali di ogni completamente gestito di Google Cloud.

-- SERVICE-DIRECTORY/
   -- OWNERS
   -- modules/
      -- <service-name>/
         -- main.tf
         -- variables.tf
         -- outputs.tf
         -- provider.tf
         -- README
      -- ...other…
   -- environments/
      -- dev/
         -- backend.tf
         -- main.tf

      -- qa/
         -- backend.tf
         -- main.tf

      -- prod/
         -- backend.tf
         -- main.tf

Utilizza le directory di ambiente

Per condividere il codice tra ambienti, fai riferimento ai moduli. In genere, potrebbe trattarsi di un di servizio che include la configurazione Terraform condivisa di base per completamente gestito di Google Cloud. Nei moduli di servizio, codifica gli input comuni e richiedi solo input specifici per l'ambiente come variabili.

Ogni directory dell'ambiente deve contenere i seguenti file:

  • Un file backend.tf che dichiara il Terraform backend località dello stato (in genere Cloud Storage)
  • Un file main.tf che esegue l'inizializzazione del modulo di servizio

Ogni directory di ambiente (dev, qa, prod) corrisponde a una directory predefinita Area di lavoro Terraform ed esegue il deployment di una versione del servizio in quell'ambiente. Queste aree di lavoro isolare le risorse specifiche dell'ambiente nei propri contesti. Utilizza solo area di lavoro predefinita.

Non è consigliabile avere più spazi di lavoro CLI all'interno di un ambiente per i seguenti motivi:

  • Può essere difficile ispezionare la configurazione in ogni spazio di lavoro.
  • Non è consigliabile avere un singolo backend condiviso per più aree di lavoro poiché il backend condiviso diventa un single point of failure se viene utilizzato la separazione degli ambienti.
  • Sebbene sia possibile riutilizzare il codice, è più difficile leggerlo e cambiare in base alla variabile dell'area di lavoro corrente (ad esempio, terraform.workspace == "foo" ? this : that).

Per ulteriori informazioni, consulta le seguenti risorse:

Esponi gli output tramite lo stato remoto

Assicurati di esporre output utili delle istanze del modulo da un modulo principale.

Ad esempio, il seguente snippet di codice passa l'output dell'ID progetto dall'istanza del modulo di fabbrica del progetto come output del modulo principale.

# Project root module
terraform {
  backend "gcs" {
    bucket  = "BUCKET"
  }
}

module "project" {
  source  = "terraform-google-modules/project-factory/google"
  ...
}

output "project_id" {
  value       = module.project.project_id
  description = "The ID of the created project"
}

Altri ambienti e applicazioni Terraform possono fare riferimento a livello di modulo principale .

Utilizzando lo stato remoto, puoi fare riferimento alle uscite del modulo principale. Consentire l'utilizzo di altre app dipendenti a configurazione, assicurati di esportare informazioni relative a dagli endpoint del servizio, allo stato remoto.

# Networks root module
data "terraform_remote_state" "network_project" {
  backend = "gcs"

  config = {
    bucket = "BUCKET"
  }
}

module "vpc" {
  source  = "terraform-google-modules/network/google"
  version = "~> 9.0"

  project_id   = data.terraform_remote_state.network_project.outputs.project_id
  network_name = "vpc-1"
  ...
}

A volte, ad esempio quando viene chiamato un modulo di servizio condiviso dalle directory dell'ambiente, è opportuno esportare nuovamente l'intero modulo secondario, come segue:

output "service" {
  value       = module.service
  description = "The service module outputs"
}

Bloccare le versioni secondarie del fornitore

Nei moduli principali, dichiara ogni provider e fissalo a una versione secondaria. In questo modo, è possibile eseguire l'upgrade automatico alle nuove release delle patch mantenendo un obiettivo solido. Per coerenza, assegna al file delle versioni il nome versions.tf.

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 4.0.0"
    }
  }
}

Archivia le variabili in un file tfvars

Per i moduli principali, fornisci le variabili usando un file di variabili .tfvars. Per mantenere la coerenza, assegna ai file delle variabili il nome terraform.tfvars.

Non specificare le variabili utilizzando opzioni di riga di comando alternative var-files o var='key=val'. Le opzioni a riga di comando sono temporanee facile da dimenticare. L'utilizzo di un file di variabili predefinite è più prevedibile.

Controlla in .terraform.lock.hcl file

Per i moduli principali, il blocco delle dipendenze .terraform.lock.hcl deve essere archiviato nel controllo del codice sorgente. In questo modo è possibile monitorare e esaminare le modifiche alle selezioni dei fornitori per una determinata configurazione.

Passaggi successivi