Comprensione dei moduli Terraform

Nell'ambito dell'infrastruttura come codice (IaC), un modulo è un blocco di codice autonomo che viene isolato e impacchettato per il riutilizzo. Il concetto di moduli è un aspetto inevitabile dello sviluppo di Terraform. Per ulteriori informazioni, consulta Moduli nella documentazione di Terraform. AWS CloudFormation supporta anche i moduli. Per ulteriori informazioni, consulta Introduzione ai AWS CloudFormation moduli nel blog AWS Cloud Operations and Migrations.

La differenza principale tra i moduli di Terraform e CloudFormation è che CloudFormation i moduli vengono importati utilizzando un tipo di risorsa speciale ()AWS::CloudFormation::ModuleVersion. In Terraform, ogni configurazione ha almeno un modulo, noto come modulo root. Le risorse Terraform che si trovano nel file.tf principale o i file in un file di configurazione Terraform sono considerate nel modulo root. Il modulo root può quindi chiamare altri moduli per l'inclusione nello stack. L'esempio seguente mostra un modulo root che fornisce un cluster Amazon Elastic Kubernetes Service (Amazon EKS) utilizzando il modulo eks open source.

terraform {
  required_providers {
    helm = {
      source  = "hashicorp/helm"
      version = "2.12.1"
    }
  }
  required_version = ">= 1.2.0"
}

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "20.2.1"
  vpc_id  = var.vpc_id
}

provider "helm" {
  kubernetes {
    host                   = module.eks.cluster_endpoint
    cluster_ca_certificate = base64decode(module.eks.cluster_certificate_authority_data)
  }
}

Avrai notato che il file di configurazione sopra riportato non include il Provider. AWS Questo perché i moduli sono autonomi e possono includere i propri provider. Poiché i provider Terraform sono globali, i provider di un modulo figlio possono essere utilizzati nel modulo root. Tuttavia, questo non è vero per tutti i valori dei moduli. Gli altri valori interni all'interno di un modulo rientrano di default solo nell'ambito di quel modulo e devono essere dichiarati come output per essere accessibili nel modulo root. Puoi sfruttare i moduli open source per semplificare la creazione di risorse all'interno del tuo stack. Ad esempio, il modulo eks non si limita a fornire un cluster EKS: fornisce un ambiente Kubernetes perfettamente funzionante. Usarlo può evitarti di scrivere dozzine di righe di codice aggiuntive, a condizione che la configurazione del modulo eks soddisfi le tue esigenze.

Moduli di chiamata

Due dei comandi CLI Terraform principali che esegui durante l'implementazione di Terraform sono terraform init e terraform apply. Uno dei passaggi predefiniti eseguiti dal terraform init comando consiste nell'individuare tutti i moduli figlio e importarli come dipendenze nella directory. .terraform/modules Durante lo sviluppo, ogni volta che aggiungete un nuovo modulo di origine esterna, dovete reinizializzarlo prima di utilizzare il comando. apply Quando senti un riferimento a un modulo Terraform, si riferisce ai pacchetti in questa directory. A rigor di termini, il modulo che dichiari nel codice è il modulo chiamante, quindi in pratica, la parola chiave module chiama il modulo effettivo, che viene memorizzato come dipendenza.

In questo modo, il modulo chiamante funge da rappresentante più succinto del modulo completo da sostituire al momento della distribuzione. Puoi sfruttare questa idea creando i tuoi moduli all'interno degli stack per applicare la separazione logica delle risorse utilizzando qualsiasi criterio desideri. Ricorda solo che l'obiettivo finale di questa operazione dovrebbe essere quello di ridurre la complessità dello stack. Poiché la condivisione dei dati tra i moduli richiede l'output dei dati dall'interno del modulo, a volte affidarsi troppo ai moduli può complicare eccessivamente le cose.

Il modulo root

Poiché ogni configurazione di Terraform ha almeno un modulo, può essere utile esaminare le proprietà del modulo con cui avrai a che fare di più: il modulo root. Ogni volta che lavori su un progetto Terraform, il modulo root è composto da tutti i .tf (o.tf.json) file nella tua directory di primo livello. Quando esegui terraform apply in quella directory di primo livello, Terraform tenta di eseguire ogni .tf file che trova lì. Tutti i file nelle sottodirectory vengono ignorati a meno che non vengano chiamati in uno di questi file di configurazione di primo livello.

Ciò offre una certa flessibilità nel modo in cui strutturate il codice. È anche il motivo per cui è più preciso fare riferimento alla distribuzione di Terraform come modulo piuttosto che come file, perché diversi file potrebbero essere coinvolti in un unico processo. Esiste una struttura di moduli standard che Terraform consiglia per le migliori pratiche. Tuttavia, se dovessi inserire un .tf file nella directory di primo livello, verrà eseguito insieme al resto dei file. In effetti, tutti i .tf file di primo livello in un modulo vengono distribuiti durante l'esecuzione. terraform apply Quindi quale file viene eseguito per primo Terraform? La risposta a questa domanda è molto importante.

Terraform esegue una serie di passaggi dopo l'inizializzazione e prima della distribuzione dello stack. Innanzitutto, vengono analizzate le configurazioni esistenti e quindi viene creato un grafico delle dipendenze. Il grafico delle dipendenze determina quali risorse sono necessarie e in quale ordine devono essere indirizzate. Le risorse che contengono proprietà a cui si fa riferimento in altre risorse, ad esempio, verrebbero gestite prima delle risorse dipendenti. Allo stesso modo, le risorse che dichiarano esplicitamente la dipendenza utilizzando il depends_on parametro verrebbero gestite dopo le risorse da esse specificate. Quando possibile, Terraform può implementare il parallelismo e gestire contemporaneamente risorse non dipendenti. È possibile visualizzare il grafico delle dipendenze prima della distribuzione utilizzando il comando terraform graph.

Dopo la creazione del grafico delle dipendenze, Terraform determina cosa deve essere fatto durante l'implementazione. Confronta il grafico delle dipendenze con il file di stato più recente. Il risultato di questo processo si chiama piano ed è molto simile a un set di CloudFormation modifiche. Puoi vedere il piano corrente usando il comando terraform plan.

Come buona pratica, si consiglia di rimanere il più vicino possibile alla struttura del modulo standard. Nei casi in cui i file di configurazione diventano troppo lunghi per essere gestiti in modo efficiente e le separazioni logiche potrebbero semplificare la gestione, è possibile distribuire il codice su più file. Tieni presente come funzionano il grafico delle dipendenze e il processo di pianificazione per far funzionare gli stack nel modo più efficiente possibile.