Comprensione degli stati e dei backend di Terraform

Uno dei concetti più importanti nell'infrastruttura come codice (IaC) è il concetto di stato. I servizi IaC mantengono lo stato, che consente di dichiarare una risorsa in un file IAc senza doverla ricreare ogni volta che si distribuisce. I file IaC documentano lo stato di tutte le risorse al termine di una distribuzione in modo che possa quindi confrontare tale stato con lo stato di destinazione, come dichiarato nella distribuzione successiva. Quindi, se lo stato corrente contiene un bucket Amazon Simple Storage Service (Amazon S3) my-s3-bucket denominato e le modifiche in arrivo contengono anche lo stesso bucket, il nuovo processo applicherà tutte le modifiche rilevate al bucket esistente anziché provare a creare un bucket completamente nuovo.

La tabella seguente fornisce esempi del processo generale di stato IAc.

Stato attuale	Stato di destinazione	Azione
Nessun bucket S3 denominato my-s3-bucket	Bucket S3 denominato my-s3-bucket	Crea un bucket S3 denominato my-s3-bucket
my-s3-bucketsenza che sia configurato il controllo delle versioni del bucket	my-s3-bucketsenza che sia configurato il controllo delle versioni del bucket	Nessuna operazione
my-s3-bucketsenza che sia configurato il controllo delle versioni del bucket	my-s3-bucketcon il controllo delle versioni del bucket configurato	Configura my-s3-bucket per avere il controllo delle versioni del bucket
my-s3-bucketcon il controllo delle versioni del bucket configurato	Nessun bucket S3 denominato my-s3-bucket	Tentativo di eliminazione my-s3-bucket

Per comprendere i diversi modi in cui AWS CloudFormation Terraform traccia lo stato, è importante ricordare la prima differenza fondamentale tra i due strumenti: CloudFormation è ospitato all'interno di e Terraform è essenzialmente remoto. Cloud AWS Questo fatto consente di CloudFormation mantenere lo stato internamente. Puoi accedere alla CloudFormation console e visualizzare la cronologia degli eventi di un determinato stack, ma il CloudFormation servizio stesso applica le regole statali per te.

Le tre modalità che CloudFormation operano in base a una determinata risorsa sono CreateUpdate, e. Delete La modalità corrente viene determinata in base a ciò che è accaduto nell'ultima distribuzione e non può essere influenzata in altro modo. Forse è possibile aggiornare CloudFormation le risorse manualmente per influenzare la modalità determinata, ma non è possibile passare un comando CloudFormation che dica «Per questa risorsa, operate in Create modalità».

Poiché Terraform non è ospitato in Cloud AWS, il processo di mantenimento dello stato deve essere più configurabile. Per questo motivo, lo stato Terraform viene mantenuto all'interno di un file di stato generato automaticamente. Uno sviluppatore Terraform ha a che fare con lo stato in modo molto più diretto di quanto farebbe. CloudFormation La cosa importante da ricordare è che lo stato di tracciamento è altrettanto importante per entrambi gli strumenti.

Per impostazione predefinita, il file di stato Terraform viene archiviato localmente al livello superiore della directory principale che esegue lo stack Terraform. Se esegui il terraform apply comando dal tuo ambiente di sviluppo locale, puoi vedere Terraform generare il file terraform.tfstate che utilizza per mantenere lo stato in tempo reale. Nel bene e nel male, questo ti dà molto più controllo sullo stato in Terraform rispetto a quello che hai. CloudFormation Sebbene non dovresti mai aggiornare direttamente il file di stato, puoi eseguire diversi comandi CLI Terraform che aggiorneranno lo stato tra le distribuzioni. Ad esempio, terraform import ti consente di aggiungere risorse create al di fuori di Terraform allo stack di implementazione. Al contrario, puoi rimuovere una risorsa dallo stato eseguendo terraform state rm.

Il fatto che Terraform debba memorizzare il suo stato da qualche parte porta a un altro concetto che non si applica a CloudFormation: il backend. Un backend Terraform è il luogo in cui uno stack Terraform memorizza il proprio file di stato dopo la distribuzione. Questo è anche il luogo in cui si aspetta di trovare il file di stato all'inizio di una nuova distribuzione. Quando esegui lo stack localmente, come descritto sopra, puoi conservare una copia dello stato di Terraform nella directory locale di primo livello. Questo è noto come backend locale.

Quando si sviluppa per un ambiente di integrazione e distribuzione continue (CI/CD), il file di stato locale viene generalmente incluso nel file.gitignore per non consentirne il controllo della versione. Quindi non è presente alcun file di stato locale all'interno della pipeline. Per funzionare correttamente, quella fase della pipeline deve trovare da qualche parte il file di stato corretto.Questo è il motivo per cui i file di configurazione Terraform contengono spesso un blocco di backend. Il blocco di backend indica allo stack Terraform che deve cercare da qualche parte oltre alla propria directory di primo livello per trovare il file di stato.

Un backend Terraform può essere posizionato quasi ovunque: un bucket Amazon S3, un endpoint API o persino uno spazio di lavoro Terraform remoto. Di seguito è riportato un esempio di backend Terraform archiviato in un bucket Amazon S3.

terraform {
  backend "s3" {
    bucket = "my-s3-bucket"
    key    = "state-file-folder"
    region = "us-east-1"
  }
}

Per evitare di archiviare informazioni sensibili all'interno dei file di configurazione Terraform, i backend supportano anche configurazioni parziali. Nell'esempio precedente, le credenziali necessarie per accedere al bucket non sono presenti nella configurazione. Le credenziali possono essere ottenute da variabili di ambiente o utilizzando altri mezzi, ad esempio. AWS Secrets Manager Per ulteriori informazioni, consulta Proteggere i dati sensibili utilizzando AWS Secrets Manager e HashiCorp Terraform.

Uno scenario di backend comune è un backend locale utilizzato nell'ambiente locale a scopo di test. Il file terraform.tfstate è incluso nel file.gitignore in modo che non venga inviato al repository remoto. Quindi, ogni ambiente all'interno della pipeline CI/CD manterrebbe il proprio backend. In questo scenario, più sviluppatori potrebbero avere accesso a questo stato remoto, quindi è consigliabile proteggere l'integrità del file di stato. Se più distribuzioni sono in esecuzione e aggiornano lo stato contemporaneamente, il file di stato potrebbe danneggiarsi. Per questo motivo, in situazioni con backend non locali, il file di stato viene in genere bloccato durante la distribuzione.