Questo lab è stato sviluppato in collaborazione con il nostro partner Hashicorp. Le tue informazioni personali potrebbero essere condivise con Hashicorp, lo sponsor del lab, se hai acconsentito a ricevere aggiornamenti, annunci e offerte di prodotti nel profilo del tuo account.

GSP752

Panoramica

Terraform deve archiviare lo stato relativo alla tua infrastruttura gestita e alla configurazione. Questo stato viene utilizzato da Terraform per mappare risorse del mondo reale sulla tua configurazione, tenere traccia dei metadati e migliorare le prestazioni per infrastrutture di grandi dimensioni.

Per impostazione predefinita, lo stato viene archiviato in un file locale con nome terraform.tfstate, ma è anche possibile archiviarlo in una posizione remota, una soluzione migliore per ambienti con team.

Terraform usa questo stato locale per creare piani e apportare modifiche all'infrastruttura. Prima di qualsiasi operazione, Terraform esegue un aggiornamento in modo che lo stato rifletta l'infrastruttura reale.

Lo stato di Terraform ha lo scopo principale di archiviare le associazioni tra gli oggetti in un sistema remoto e le istanze di risorse dichiarate nella tua configurazione. Quando Terraform crea un oggetto remoto in risposta a una modifica della configurazione, ne registra l'identità a fronte di una particolare istanza di risorsa, dopodiché potrà aggiornare o eliminare l'oggetto in risposta a future modifiche della configurazione.

Obiettivi

In questo lab imparerai a eseguire le attività seguenti:

• Creare un backend locale.
• Creare un backend Cloud Storage.
• Aggiornare lo stato di Terraform.
• Importare una configurazione Terraform.
• Gestire la configurazione importata con Terraform.

Configurazione e requisiti

Prima di fare clic sul pulsante Avvia lab

Leggi le seguenti istruzioni. I lab sono a tempo e non possono essere messi in pausa. Il timer si avvia quando fai clic su Avvia lab e ti mostra per quanto tempo avrai a disposizione le risorse Google Cloud.

Con questo lab pratico avrai la possibilità di completare le attività in prima persona, in un ambiente cloud reale e non di simulazione o demo. Riceverai delle nuove credenziali temporanee che potrai utilizzare per accedere a Google Cloud per la durata del lab.

Per completare il lab, avrai bisogno di:

• Accesso a un browser internet standard (Chrome è il browser consigliato).

Nota: utilizza una finestra del browser in incognito o privata per eseguire questo lab. Ciò evita eventuali conflitti tra il tuo account personale e l'account Studente, che potrebbero causare addebiti aggiuntivi sul tuo account personale.

• È ora di completare il lab: ricorda che, una volta iniziato, non puoi metterlo in pausa.

Nota: se hai già un account o un progetto Google Cloud personale, non utilizzarlo per questo lab per evitare addebiti aggiuntivi al tuo account.

Come avviare il lab e accedere alla console Google Cloud

1. Fai clic sul pulsante Avvia lab. Se devi effettuare il pagamento per il lab, si apre una finestra popup per permetterti di selezionare il metodo di pagamento. A sinistra, trovi il riquadro Dettagli lab con le seguenti informazioni:

   • Il pulsante Apri console Google Cloud
   • Tempo rimanente
   • Credenziali temporanee da utilizzare per il lab
   • Altre informazioni per seguire questo lab, se necessario

2. Fai clic su Apri console Google Cloud (o fai clic con il tasto destro del mouse e seleziona Apri link in finestra di navigazione in incognito se utilizzi il browser Chrome).

   Il lab avvia le risorse e apre un'altra scheda con la pagina di accesso.

   Suggerimento: disponi le schede in finestre separate posizionate fianco a fianco.

   Nota: se visualizzi la finestra di dialogo Scegli un account, fai clic su Usa un altro account.

3. Se necessario, copia il Nome utente di seguito e incollalo nella finestra di dialogo di accesso.

   {{{user_0.username | "Username"}}}

   Puoi trovare il Nome utente anche nel riquadro Dettagli lab.

4. Fai clic su Avanti.

5. Copia la Password di seguito e incollala nella finestra di dialogo di benvenuto.

   {{{user_0.password | "Password"}}}

   Puoi trovare la Password anche nel riquadro Dettagli lab.

6. Fai clic su Avanti.

   Importante: devi utilizzare le credenziali fornite dal lab. Non utilizzare le credenziali del tuo account Google Cloud. Nota: utilizzare il tuo account Google Cloud per questo lab potrebbe comportare addebiti aggiuntivi.

7. Fai clic nelle pagine successive:

   • Accetta i termini e le condizioni.
   • Non inserire opzioni di recupero o l'autenticazione a due fattori, perché si tratta di un account temporaneo.
   • Non registrarti per le prove gratuite.

Dopo qualche istante, la console Google Cloud si apre in questa scheda.

Nota: per visualizzare un menu con un elenco di prodotti e servizi Google Cloud, fai clic sul menu di navigazione in alto a sinistra.

Attiva Cloud Shell

Cloud Shell è una macchina virtuale in cui sono caricati strumenti per sviluppatori. Offre una home directory permanente da 5 GB e viene eseguita su Google Cloud. Cloud Shell fornisce l'accesso da riga di comando alle risorse Google Cloud.

1. Fai clic su Attiva Cloud Shell nella parte superiore della console Google Cloud.

Quando la connessione è attiva, l'autenticazione è già avvenuta e il progetto è impostato sul tuo PROJECT_ID. L'output contiene una riga che dichiara il PROJECT_ID per questa sessione:

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud è lo strumento a riga di comando di Google Cloud. È preinstallato su Cloud Shell e supporta il completamento tramite tasto Tab.

2. (Facoltativo) Puoi visualizzare il nome dell'account attivo con questo comando:

gcloud auth list

3. Fai clic su Autorizza.

4. L'output dovrebbe avere ora il seguente aspetto:

Output:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (Facoltativo) Puoi elencare l'ID progetto con questo comando:

gcloud config list project

Output:

[core] project = <project_ID>

Output di esempio:

[core] project = qwiklabs-gcp-44776a13dea667a6 Nota: per la documentazione completa di gcloud, in Google Cloud, fai riferimento alla Panoramica dell'interfaccia a riga di comando gcloud.

Scopo dello stato di Terraform

Lo stato è un requisito necessario per il funzionamento di Terraform. Una domanda comune è se Terraform possa funzionare senza stato o se sia possibile evitare di utilizzare lo stato limitandosi a ispezionare le risorse cloud a ogni esecuzione. Negli scenari in cui Terraform potrebbe riuscire a funzionare senza stato, questo richiederebbe il trasferimento di un'enorme complessità da una parte (lo stato) a un'altra (il concetto di sostituzione). Questa sezione spiega perché lo stato di Terraform è necessario.

Mappatura sul mondo reale

Terraform richiede un database per la mappatura della configurazione Terraform sul mondo reale. Quando la configurazione contiene una risorsa resource "google_compute_instance" "foo", Terraform utilizza questa mappatura per sapere che la risorsa rappresenta l'istanza i-abcd1234.

Terraform prevede che ogni oggetto remoto sia associato a una sola istanza di risorsa, il che normalmente è garantito, dal momento che è Terraform a provvedere alla creazione degli oggetti e alla registrazione delle loro identità nello stato. Se invece importi oggetti creati fuori da Terraform, devi verificare che ogni singolo oggetto sia importato su una sola istanza di risorsa.

Se un oggetto remoto è collegato a due o più istanze di risorsa, Terraform potrebbe agire in modo imprevisto nei confronti dell'oggetto, perché la mappatura tra configurazione e stato dell'oggetto remoto è diventata ambigua.

Metadati

Oltre a monitorare le mappature tra risorse e oggetti remoti, Terraform deve monitorare anche metadati come le dipendenze delle risorse.

Terraform in genere utilizza la configurazione per determinare l'ordine delle dipendenze. Se rimuovi una risorsa da una configurazione, Terraform deve sapere come eliminare questa risorsa. Terraform può rilevare l'esistenza di una mappatura per una risorsa non presente nel file di configurazione e pianificarne l'eliminazione. Tuttavia, poiché la risorsa non esiste più, l'ordine non può essere stabilito in base alla sola configurazione.

Per assicurare un funzionamento corretto, Terraform conserva una copia del set di dipendenze più recente all'interno dello stato. Adesso, quando elimini uno o più elementi dalla configurazione, Terraform è ancora in grado di determinare l'ordine corretto per l'eliminazione in base allo stato.

Si potrebbe evitare questa situazione se Terraform conoscesse un ordinamento obbligatorio tra i tipi di risorse. Ad esempio, Terraform potrebbe sapere che è necessario eliminare i server prima delle subnet di cui fanno parte. Tuttavia, la complessità di questo approccio diventa rapidamente ingestibile: oltre a comprendere la semantica dell'ordinamento di ogni risorsa per ogni cloud, Terraform deve comprendere anche l'ordinamento nei diversi provider.

Terraform archivia anche altri metadati per motivi analoghi, tra cui un puntatore alla configurazione del provider utilizzato più di recente con la risorsa laddove sono presenti più provider con alias.

Prestazioni

Oltre alla mappatura base, Terraform archivia una cache dei valori degli attributi per tutte le risorse nello stato. Questa è una funzionalità facoltativa dello stato di Terraform e viene utilizzata solo come miglioramento delle prestazioni.

Durante l'esecuzione di un comando terraform plan, Terraform deve conoscere lo stato attuale delle risorse per poter determinare efficacemente le modifiche necessarie per raggiungere la configurazione desiderata.

Per le infrastrutture di dimensioni ridotte, Terraform può inviare query ai tuoi provider e sincronizzare gli attributi più recenti di tutte le tue risorse. Questo è il comportamento predefinito di Terraform: per ogni comando plan e apply, Terraform sincronizza tutte le risorse nel tuo stato.

Per le infrastrutture più grandi, l'esecuzione di query per ogni risorsa richiede troppo tempo. Molti cloud provider non forniscono API per eseguire contemporaneamente query su più risorse, inoltre il tempo di round trip per ogni risorsa è di centinaia di millisecondi. A questo si aggiunge il fatto che i cloud provider prevedono quasi sempre una limitazione di frequenza delle API, per cui Terraform può richiedere solo un numero limitato di risorse in un dato periodo di tempo. Gli utenti di Terraform con organizzazioni più grandi usano spesso sia il flag -refresh=false che il flag -target per aggirare questa limitazione. In scenari del genere, lo stato memorizzato nella cache viene considerato come l'effettiva situazione nel mondo reale.

Sincronizzazione

Nella configurazione predefinita, Terraform archivia lo stato in un file nella directory di lavoro attuale in cui è stato eseguito. Questa soluzione funziona quando si muovono i primi passi, ma quando a utilizzare Terraform è un team, è importante che tutti lavorino con lo stesso stato, in modo da applicare le operazioni agli stessi oggetti remoti.

Lo stato remoto è la soluzione consigliata per questo problema. Un backup dello stato con funzionalità complete consente di utilizzare il blocco remoto per impedire che più utenti eseguano accidentalmente Terraform nello stesso momento e assicurare così che ogni esecuzione di Terraform inizi con lo stato aggiornato più recente.

Blocco dello stato

Se la funzionalità è supportata dal tuo backend, Terraform blocca lo stato per tutte le operazioni che potrebbero comportarne una scrittura. In questo modo si impedisce che altri acquisiscano il blocco, con il rischio di danneggiare il tuo stato.

Il blocco dello stato viene applicato automaticamente per tutte le operazioni che potrebbero comportarne la scrittura. Non verranno visualizzati messaggi in merito. Se il blocco dello stato non riesce, Terraform interrompe l'operazione. Puoi disabilitare il blocco dello stato con il flag -lock per la maggior parte dei comandi, ma questa operazione è sconsigliata.

Se l'acquisizione del blocco richiede più tempo del previsto, Terraform genera un messaggio di stato. L'assenza di un messaggio di Terraform indica che il blocco dello stato è ancora in corso.

Il blocco non è supportato da tutti i backend. Visualizza l'elenco dei tipi di backend per i dettagli sul supporto del blocco per ogni backend.

Aree di lavoro

Ogni configurazione Terraform ha un backend associato, che definisce le modalità di esecuzione delle operazioni e la posizione di archiviazione di dati permanenti come lo stato di Terraform.

I dati permanenti archiviati nel backend appartengono a un'area di lavoro. Inizialmente, il backend ha una sola area di lavoro, denominata default, e quindi un solo stato di Terraform associato alla configurazione.

Alcuni backend supportano più aree di lavoro con nome, permettendo quindi di associare più stati a un'unica configurazione. La configurazione continua ad avere un solo backend, ma è possibile eseguire il deployment di più istanze distinte della configurazione senza dover configurare un nuovo backend o cambiare le credenziali di autenticazione.

Attività 1: uso dei backend

Un backend in Terraform determina come viene caricato lo stato e come vengono eseguite le operazioni, ad esempio apply. Questa astrazione consente l'archiviazione dello stato in un file non locale, l'esecuzione remota e altro ancora.

Per impostazione predefinita, Terraform utilizza il backend "local", il comportamento normale a cui siamo abituati. Questo è il backend che veniva richiamato nei lab precedenti.

Ecco alcuni vantaggi dei backend:

• Lavoro in team: i backend supportano l'archiviazione remota dello stato e la sua protezione con blocchi per evitarne il danneggiamento. Alcuni backend, come Terraform Cloud, sono anche in grado di archiviare automaticamente una cronologia di tutte le revisioni dello stato.
• Conservazione di informazioni sensibili non su disco: lo stato viene recuperato dai backend on demand e archiviato solo in memoria.
• Operazioni remote: per le infrastrutture più grandi o per determinate modifiche, terraform apply può richiedere molto tempo. Alcuni backend supportano le operazioni remote, che consentono l'esecuzione remota dell'operazione. Anche dopo che avrai spento il tuo computer, l'operazione continuerà fino al completamento. In combinazione con l'archiviazione remota e il blocco remoto dello stato descritti sopra, questo è un aspetto utile negli ambienti con team.

I backend sono completamente facoltativi: puoi usare correttamente Terraform senza doverli mai studiare o utilizzare. Tuttavia, offrono una soluzione ad aspetti problematici del lavoro per i team di una certa grandezza. Se lavori in autonomia, probabilmente non avrai bisogno di utilizzare i backend per conseguire i tuoi obiettivi.

Anche se intendi utilizzare solo il backend "local", una conoscenza dei backend in generale può essere comunque utile, dato che puoi modificare il comportamento del backend locale.

Aggiungi un backend locale

In questa sezione configurerai un backend locale.

Durante la configurazione iniziale di un backend (dall'assenza di un backend definito all'esplicita configurazione), Terraform ti offre l'opzione di migrare lo stato al nuovo backend. In questo modo puoi adottare backend senza perdere lo stato esistente.

Come misura di ulteriore cautela, consigliamo sempre di eseguire anche un backup manuale dello stato. Per farlo, è sufficiente copiare il tuo file terraform.tfstate in un'altra posizione. Anche il processo di inizializzazione prevede la creazione di un backup, ma la prudenza non è mai troppa!

La configurazione iniziale di un backend non è diversa dalla modifica di una configurazione in un secondo momento: dovrai creare la nuova configurazione ed eseguire terraform init. Terraform ti guiderà nei passaggi successivi.

1. In una nuova finestra di Cloud Shell, crea il tuo file di configurazione main.tf:

touch main.tf

2. Per recuperare l'ID progetto, esegui questo comando:

gcloud config list --format 'value(core.project)'

3. Nella barra degli strumenti di Cloud Shell fai clic su Apri editor. Per passare da Cloud Shell all'editor di codice o viceversa, fai clic su Apri editor o Apri terminale, a seconda del caso, oppure fai clic su Apri in una nuova finestra per lasciare aperto l'editor in una scheda separata.

4. Copia il codice risorsa del bucket Cloud Storage nel file di configurazione main.tf, sostituendo le definizioni delle variabili project e name con il tuo ID progetto:

provider "google" { project = "# REPLACE WITH YOUR PROJECT ID" region = "{{{project_0.default_region | REGION}}}" } resource "google_storage_bucket" "test-bucket-for-state" { name = "# REPLACE WITH YOUR PROJECT ID" location = "US" uniform_bucket_level_access = true }

Scopri di più sulle risorse Cloud Storage nella documentazione di Terraform.

5. Aggiungi un backend locale al tuo file main.tf:

terraform { backend "local" { path = "terraform/state/terraform.tfstate" } }

Questo aggiunge un riferimento a un file terraform.tfstate nella directory terraform/state. Per specificare un percorso file diverso, modifica la variabile path.

Il backend locale archivia lo stato sul file system locale, lo blocca utilizzando le API di sistema ed esegue le operazioni localmente.

Terraform deve inizializzare gli eventuali backend configurati prima dell'uso. Per farlo, dovrai eseguire terraform init. Il comando terraform init deve essere eseguito come primo passo da qualsiasi membro del tuo team su qualunque configurazione Terraform. Il comando può essere utilizzato anche più volte ed esegue tutte le azioni richieste per un ambiente Terraform, compresa l'inizializzazione del backend.

È richiesta una chiamata al comando init:

• Per qualsiasi nuovo ambiente che configura un backend
• Per qualsiasi modifica della configurazione del backend (compreso il tipo di backend)
• Per la rimozione completa della configurazione del backend

Non c'è bisogno di ricordare questi casi esatti. Terraform rileverà quando è richiesta l'inizializzazione e, in tal caso, mostrerà un messaggio di errore. Terraform non esegue automaticamente l'inizializzazione perché potrebbe richiedere ulteriori informazioni dall'utente o dover eseguire migrazioni degli stati e così via.

6. Nella barra degli strumenti di Cloud Shell, fai clic su Apri terminale, quindi inizializza Terraform:

terraform init

7. Applica le modifiche. Digita yes quando richiesto per confermare:

terraform apply

A questo punto, nell'editor di Cloud Shell dovrebbe essere visualizzato il file di stato, denominato terraform.tfstate, nella directory terraform/state.

8. Esamina il file di stato:

terraform show

Dovresti vedere la tua risorsa google_storage_bucket.test-bucket-for-state.

Aggiungi un backend Cloud Storage

Un backend Cloud Storage archivia lo stato come un oggetto in un prefisso configurabile in un determinato bucket in Cloud Storage. Questo backend supporta anche il blocco dello stato. Lo stato viene bloccato per tutte le operazioni che potrebbero comportarne la scrittura. In questo modo si impedisce che altri acquisiscano il blocco, con il rischio di danneggiare il tuo stato.

Il blocco dello stato viene applicato automaticamente per tutte le operazioni che potrebbero comportarne la scrittura. Non verranno visualizzati messaggi in merito. Se il blocco dello stato non riesce, Terraform interrompe l'operazione. Puoi disabilitare il blocco dello stato per la maggior parte dei comandi con il flag -lock, ma questa operazione è sconsigliata.

1. Torna al tuo file main.tf nell'editor. Ora sostituirai l'attuale backend locale con un backend gcs.

2. Per cambiare la configurazione del backend locale esistente, copia la configurazione seguente nel file, sostituendo il backend local:

terraform { backend "gcs" { bucket = "# REPLACE WITH YOUR BUCKET NAME" prefix = "terraform/state" } } Nota: assicurati di aggiornare la definizione della variabile del bucket. Se non hai ancora modificato la configurazione, sarà il valore di name della risorsa google_storage_bucket. Il file di stato sarà ospitato in questo bucket.

3. Inizializza di nuovo il tuo backend, questa volta per eseguire automaticamente la migrazione dello stato:

terraform init -migrate-state

Digita yes quando richiesto per confermare.

4. Nella console Cloud, nel menu di navigazione, fai clic su Cloud Storage > Bucket.

5. Fai clic sul tuo bucket e passa al file terraform/state/default.tfstate. Il tuo file di stato è ora presente in un bucket Cloud Storage.

Nota: se non vuoi più utilizzare i backend, sarà sufficiente rimuovere la configurazione dal file. Terraform rileverà questa modifica come tutte le altre e chiederà di ripetere l'inizializzazione.

Nell'ambito della nuova inizializzazione, Terraform richiederà se eseguire la migrazione dello stato per riportarlo a un normale stato locale. Al termine, Terraform torna al comportamento predefinito.

Aggiorna lo stato

Il comando terraform refresh consente di riconciliare lo stato noto a Terraform (tramite il file di stato) con l'infrastruttura reale. Può essere utilizzato per rilevare eventuali deviazioni rispetto all'ultimo stato noto e aggiornare il file di stato.

Non modifica l'infrastruttura, modifica però il file di stato. Un cambiamento nello stato può provocare cambiamenti durante i successivi comandi plan o apply.

1. Torna al tuo bucket di archiviazione nella console Cloud. Seleziona la casella di controllo accanto al nome.

2. Fai clic sulla scheda Etichette.

3. Fai clic su Aggiungi etichetta. Imposta Chiave 1 = key e Valore 1 = value.

4. Fai clic su Salva.

5. Torna a Cloud Shell e usa il comando seguente per aggiornare il file di stato:

terraform refresh

6. Esamina gli aggiornamenti:

terraform show

La coppia chiave-valore "key" = "value" dovrebbe essere visualizzata nell'attributo labels della configurazione.

Fai clic su Controlla i miei progressi per verificare l'obiettivo. Uso dei backend

Pulisci l'area di lavoro

Prima di continuare con l'attività successiva, elimina l'infrastruttura di cui hai eseguito il provisioning.

1. Per prima cosa, ripristina il backend su local per poter eliminare il bucket di archiviazione. Copia e sostituisci la configurazione gcs con la seguente:

terraform { backend "local" { path = "terraform/state/terraform.tfstate" } }

2. Inizializza di nuovo il backend local:

terraform init -migrate-state

Digita yes quando richiesto per confermare.

3. Nel file main.tf, aggiungi l'argomento force_destroy = true alla tua risorsa google_storage_bucket. Quando elimini un bucket, questa opzione booleana elimina tutti gli oggetti contenuti. Se provi a eliminare un bucket che contiene oggetti, Terraform non può completare l'esecuzione. La configurazione della risorsa dovrebbe essere simile a questa:

resource "google_storage_bucket" "test-bucket-for-state" { name = "qwiklabs-gcp-03-c26136e27648" location = "US" uniform_bucket_level_access = true force_destroy = true }

4. Applica le modifiche:

terraform apply

Digita yes quando richiesto per confermare.

5. Ora puoi eliminare correttamente la tua infrastruttura:

terraform destroy

Digita yes quando richiesto per confermare.

Attività 2: importa la configurazione Terraform

In questa sezione importerai un container e un'immagine Docker esistenti in un'area di lavoro Terraform vuota. Durante questa attività imparerai strategie e considerazioni per l'importazione dell'infrastruttura reale in Terraform.

Il flusso di lavoro predefinito di Terraform prevede che l'infrastruttura venga creata e gestita interamente con Terraform.

• Scrivi una configurazione Terraform che definisce l'infrastruttura da creare.

• Rivedi il piano Terraform per assicurarti che la configurazione produrrà lo stato e l'infrastruttura come previsto.

• Applica la configurazione per creare il tuo stato e la tua infrastruttura Terraform.

Dopo aver creato l'infrastruttura con Terraform, puoi aggiornare la configurazione e pianificare e applicare le modifiche. Alla fine, utilizzerai Terraform per eliminare l'infrastruttura quando non è più necessaria. Questo flusso di lavoro presuppone che Terraform crei un'infrastruttura completamente nuova.

Tuttavia, potresti aver bisogno di gestire un'infrastruttura che non è stata creata da Terraform. Il comando terraform import risolve questo problema caricando le risorse supportate nello stato dell'area di lavoro Terraform.

Il comando di importazione non genera però automaticamente la configurazione per gestire l'infrastruttura. Per questo motivo, per importare un'infrastruttura esistente in Terraform sono richiesti più passaggi.

Per portare sotto il controllo di Terraform l'infrastruttura esistente sono richiesti cinque passaggi principali:

• Identifica l'infrastruttura esistente da importare.
• Importa l'infrastruttura nello stato di Terraform.
• Scrivi una configurazione Terraform corrispondente all'infrastruttura.
• Rivedi il piano Terraform per assicurarti che la configurazione produrrà lo stato e l'infrastruttura come previsto.
• Applica la configurazione per aggiornare lo stato di Terraform.

In questa sezione, per prima cosa creerai un container Docker con l'interfaccia a riga di comando di Docker. Quindi lo importerai in una nuova area di lavoro Terraform. Successivamente, aggiornerai la configurazione del container utilizzando Terraform, per poi eliminarlo alla fine dell'attività.

Avviso: l'importazione dell'infrastruttura manipola lo stato di Terraform in modi che potrebbero compromettere la validità dei progetti Terraform esistenti. Prima di utilizzare il comando terraform import su un progetto Terraform reale, crea una copia di backup del tuo file terraform.tfstate e della directory .terraform e archiviala in una posizione sicura.

Crea un container Docker

1. Crea un container denominato hashicorp-learn utilizzando la più recente immagine NGINX in Docker Hub e ottieni un'anteprima del container sulla macchina virtuale Cloud Shell attraverso la porta 80 (HTTP):

docker run --name hashicorp-learn --detach --publish 8080:80 nginx:latest

2. Verifica che il container sia in esecuzione:

docker ps

3. Nel riquadro Cloud Shell, fai clic su Anteprima web, quindi fai clic su Anteprima sulla porta 8080.

Cloud Shell apre l'URL di anteprima sul suo servizio di proxy in una nuova finestra del browser e visualizza la pagina indice predefinita NGINX. Ora hai un'immagine e un container Docker da importare nell'area di lavoro e gestire con Terraform.

Importa il container in Terraform

1. Clona il repository di esempio:

git clone https://github.com/hashicorp/learn-terraform-import.git

2. Passa alla directory:

cd learn-terraform-import

Questa directory contiene due file di configurazione Terraform che costituiscono la configurazione utilizzata in questa guida:

• Il file main.tf configura il provider Docker.
• Il file docker.tf contiene la configurazione necessaria per gestire il container Docker creato in un passaggio precedente.

3. Inizializza la tua area di lavoro Terraform:

terraform init Nota: se appare un errore simile a Errore: impossibile eseguire query sui pacchetti di provider disponibili, esegui questo comando: terraform init -upgrade

4. Nell'editor di Cloud Shell, passa a learn-terraform-import/main.tf.

5. Trova la risorsa provider: docker e commenta o elimina l'argomento host:

provider "docker" { # host = "npipe:////.//pipe//docker_engine" } Nota: questa è attualmente una soluzione alternativa per un problema noto con un errore di inizializzazione di Docker.

6. Quindi, passa a learn-terraform-import/docker.tf.

7. Sotto il codice commentato, definisci una risorsa docker_container vuota nel tuo file docker.tf, che rappresenta un container Docker con l'ID risorsa Terraform docker_container.web:

resource "docker_container" "web" {}

8. Trova il nome del container da importare: in questo caso, il container creato nel passaggio precedente:

docker ps

9. Esegui il comando terraform import riportato di seguito per collegare il container Docker esistente alla risorsa docker_container.web appena creata. Il comando terraform import richiede l'ID risorsa Terraform e l'ID container Docker completo. Il comando docker inspect -f {{.ID}} hashicorp-learn restituisce l'ID container SHA256 completo:

terraform import docker_container.web $(docker inspect -f {{.ID}} hashicorp-learn) Nota: l'ID accettato da terraform import varia in base al tipo di risorsa ed è specificato nella documentazione del provider per qualsiasi risorsa che può essere importata in Terraform. Per questo esempio, consulta la documentazione del provider Docker

10. Verifica che il container sia stato importato nel tuo stato di Terraform:

terraform show

Questo stato contiene tutte le informazioni note a Terraform sul container Docker appena importato. Tuttavia, il comando terraform import non crea la configurazione per la risorsa.

Crea la configurazione

Per poter utilizzare Terraform per gestire il container, dovrai prima creare la configurazione Terraform.

1. Esegui questo codice:

terraform plan Nota: Terraform mostrerà errori per gli argomenti mancanti image e name. Terraform non può generare un piano per una risorsa priva degli argomenti obbligatori.

Per aggiornare la configurazione in docker.tf in modo che corrisponda allo stato importato esistono due approcci. Puoi accettare l'intero stato attuale della risorsa nella configurazione così com'è, oppure selezionare gli attributi obbligatori nella configurazione uno per uno. Ognuno di questi approcci può essere utile in circostanze diverse.

• L'uso dello stato attuale è spesso più rapido, ma può comportare una configurazione con un livello di dettaglio eccessivo, dal momento che ogni attributo è incluso nello stato, che sia necessario o meno nella configurazione.

• La selezione dei singoli attributi obbligatori può portare a una configurazione più gestibile, ma richiede che tu sappia quali attributi devi impostare.

Ai fini di questo lab, utilizzerai come risorsa lo stato attuale.

2. Copia il tuo stato di Terraform nel file docker.tf:

terraform show -no-color > docker.tf Nota: il simbolo > sostituisce l'intero contenuto di docker.tf con l'output del comando terraform show. L'operazione funziona per questo esempio. Tuttavia, per importare una risorsa in una configurazione che già gestisce delle risorse, dovrai modificare l'output di terraform show per rimuovere le risorse esistenti di cui non vuoi sostituire completamente la configurazione e unire le nuove risorse alla configurazione esistente.

3. Esamina il file docker.tf e vedrai che i contenuti sono stati sostituiti dall'output del comando terraform show che hai appena eseguito.

4. Esegui questo codice:

terraform plan

Terraform visualizzerà avvisi ed errori relativi a un argomento deprecato ("links") e a diversi argomenti di sola lettura (ip_address, network_data, gateway, ip_prefix_length, id).

Questi argomenti di sola lettura sono valori che Terraform archivia nel suo stato per i container Docker, ma che non può impostare tramite configurazione perché sono gestiti internamente da Docker. Terraform può impostare l'argomento links con la configurazione, ma continuerà a visualizzare un avviso perché questo è deprecato e potrebbe non essere supportato dalle versioni future del provider Docker.

Poiché l'approccio qui mostrato carica tutti gli attributi rappresentati nello stato di Terraform, la configurazione include attributi facoltativi che mantengono i valori predefiniti. Gli attributi facoltativi e i loro valori predefiniti variano a seconda del provider e sono elencati nella documentazione del provider.

5. Ora puoi rimuovere selettivamente gli attributi facoltativi. Rimuovi tutti questi attributi, mantenendo solo quelli obbligatori: image, name e ports. Dopo la rimozione degli attributi facoltativi, la configurazione dovrebbe essere la seguente:

resource "docker_container" "web" { image = "sha256:87a94228f133e2da99cb16d653cd1373c5b4e8689956386c1c12b60a20421a02" name = "hashicorp-learn" ports { external = 8080 internal = 80 ip = "0.0.0.0" protocol = "tcp" } }

Quando importi un'infrastruttura reale, consulta la documentazione del provider per sapere gli effetti di ciascun argomento. Sarà più facile stabilire come gestire eventuali errori o avvisi del passaggio di pianificazione. Ad esempio, la documentazione dell'argomento links si trova nella documentazione del provider Docker.

6. Verifica che gli errori siano stati risolti:

terraform plan

Il comando plan ora dovrebbe venire eseguito correttamente. Nota che il piano indica che Terraform aggiornerà il container per aggiungere gli attributi attach, logs, must_run e start.

Terraform usa questi attributi per creare container Docker, ma Docker non li archivia. Di conseguenza, terraform import non aveva caricato i relativi valori nello stato. Quando pianifichi e applichi la configurazione, il provider Docker assegna i valori predefiniti per questi attributi e li salva nello stato, ma questi non influiscono sul container in esecuzione.

7. Applica le modifiche e completa il processo di sincronizzazione della configurazione e dello stato di Terraform aggiornati con il container Docker che rappresentano. Digita yes quando richiesto per confermare.

terraform apply

Ora il file di configurazione, lo stato di Terraform e il container sono tutti sincronizzati e puoi usare Terraform per gestire il container Terraform nel modo consueto.

Crea la risorsa immagine

In alcuni casi, puoi portare risorse sotto il controllo di Terraform senza utilizzare il comando terraform import. Questo è frequente per risorse definite da un singolo ID o tag univoco, come le immagini Docker.

Nel tuo file docker.tf, la risorsa docker_container.web specifica l'ID hash SHA256 dell'immagine utilizzata per creare il container. Questa è la modalità di archiviazione interna dell'ID immagine in Docker, per cui terraform import ha caricato l'ID immagine direttamente nel tuo stato. Tuttavia, l'ID immagine non è facilmente leggibile quanto il tag o il nome dell'immagine e potrebbe non soddisfare le tue necessità. Ad esempio, potresti voler usare l'ultima versione dell'immagine "nginx".

1. Per recuperare il nome tag dell'immagine, esegui il comando riportato di seguito, sostituendo <IMAGE-ID> con l'ID immagine in docker.tf:

docker image inspect -f {{.RepoTags}}

2. Aggiungi la configurazione seguente al tuo file docker.tf per rappresentare questa immagine come una risorsa:

resource "docker_image" "nginx" { name = "nginx:latest" } Nota: non sostituire ancora il valore di image nella risorsa docker_container.web altrimenti Terraform eliminerà il container e lo creerà di nuovo. Poiché non ha ancora caricato la risorsa docker_image.nginx nello stato, Terraform non ha un ID immagine da confrontare con quello impostato come hardcoded e quindi deduce che il container deve essere sostituito. Per evitare questa situazione, prima crea l'immagine, quindi aggiorna il container per utilizzarla, come mostrato in questo lab.

3. Crea una risorsa per l'immagine nello stato:

terraform apply

Ora che Terraform ha creato una risorsa per l'immagine, puoi farvi riferimento nella configurazione del tuo container.

4. Cambia il valore di image per docker_container.web in modo che faccia riferimento alla nuova risorsa immagine:

resource "docker_container" "web" { image = docker_image.nginx.image_id name = "hashicorp-learn" ports { external = 8080 internal = 80 ip = "0.0.0.0" protocol = "tcp" } }

5. Cerca le modifiche:

terraform apply

Poiché docker_image.nginx.latest corrisponde all'ID immagine impostato come hardcoded che hai sostituito, l'esecuzione di terraform apply a questo punto non mostrerà alcuna modifica.

Nota: se l'ID immagine del tag "nginx:latest" è cambiato tra la creazione iniziale del container Docker e l'esecuzione di questo comando, il container sarà eliminato e ricreato con la nuova immagine.

Gestisci il container con Terraform

Ora che Terraform gestisce il container Docker, usa Terraform per cambiare la configurazione.

1. Nel tuo file docker.tf, cambia la porta esterna del container da 8080 a 8081:

resource "docker_container" "web" { name = "hashicorp-learn" image = docker_image.nginx.image_id ports { external = 8081 internal = 80 ip = "0.0.0.0" protocol = "tcp" } }

2. Applica la modifica:

terraform apply

Digita yes quando richiesto per confermare.

Terraform elimina e ricrea il container con la nuova configurazione della porta.

3. Verifica che il container sia stato sostituito con uno nuovo con la nuova configurazione:

docker ps

Nota che l'ID container è cambiato. Poiché per modificare la configurazione della porta è stato necessario eliminare e ricreare il container, questo è completamente nuovo.

Elimina l'infrastruttura

Ora hai importato in Terraform il tuo container Docker e l'immagine utilizzata per crearlo.

1. Elimina il container e l'immagine:

terraform destroy

Digita yes quando richiesto per confermare.

2. Verifica che il container sia stato eliminato:

docker ps --filter "name=hashicorp-learn" Nota: dato che l'hai aggiunta sia alla configurazione Terraform che al container, l'immagine sarà rimossa sia da Docker che dal container. Se un altro container utilizza la stessa immagine, il passaggio di eliminazione non riesce. Ricorda che l'importazione di una risorsa in Terraform significa che Terraform ne gestirà l'intero ciclo di vita, compresa l'eliminazione.

Limitazioni e altre considerazioni

Sono vari gli aspetti importanti da considerare per l'importazione di risorse in Terraform.

Il comando terraform import può conoscere solo lo stato attuale dell'infrastruttura segnalato dal provider Terraform. Non può sapere:

• Se l'infrastruttura funziona correttamente.
• L'intento dell'infrastruttura.
• Le modifiche apportate all'infrastruttura e non controllate da Terraform; ad esempio, lo stato del file system di un container Docker.

L'importazione comporta passaggi manuali che possono essere soggetti a errori, specie se chi importa le risorse non conosce il contesto e non sa quindi come e perché quelle risorse erano state inizialmente create.

L'importazione manipola il file di stato di Terraform; ti consigliamo di creare un backup prima di importare una nuova infrastruttura.

Il comando terraform import non rileva né genera relazioni nell'infrastruttura.

Terraform non rileva gli attributi predefiniti che non devono essere impostati nella tua configurazione.

Non tutti i provider e non tutte le risorse supportano il comando terraform import.

Quando un'infrastruttura è importata in Terraform, questo non significa che Terraform possa eliminarla e ricrearla. Ad esempio, l'infrastruttura importata potrebbe basarsi su un'altra infrastruttura o configurazione non gestita.

L'adesione alle best practice di Infrastructure as Code (IaC), come l'infrastruttura immutabile, può contribuire a evitare molti di questi problemi, ma è improbabile che un'infrastruttura creata manualmente sia conforme alle best practice di IaC.

Puoi utilizzare strumenti come Terraformer per automatizzare alcuni dei passaggi manuali associati all'importazione dell'infrastruttura. Tuttavia, questi strumenti non fanno parte di Terraform e non sono approvati o supportati da HashiCorp.

Complimenti!

In questo lab, hai imparato come gestire i backend e lo stato con Terraform. Hai creato backend locali e in Cloud Storage per gestire il tuo file di stato, hai aggiornato lo stato e importato la configurazione in Terraform. Hai quindi aggiornato e modificato manualmente la configurazione per gestire completamente il container Docker con Terraform.

Prossimi passi/Scopri di più

Dai uno sguardo ai link seguenti per esercitarti ulteriormente con Terraform:

• Hashicorp su Google Cloud Marketplace!
• Hashicorp Learn
• Community Terraform
• Esempi Terraform Google

Formazione e certificazione Google Cloud

… per utilizzare al meglio le tecnologie Google Cloud. I nostri corsi ti consentono di sviluppare competenze tecniche e best practice per aiutarti a metterti subito al passo e avanzare nel tuo percorso di apprendimento. Offriamo vari livelli di formazione, dal livello base a quello avanzato, con opzioni di corsi on demand, dal vivo e virtuali, in modo da poter scegliere il più adatto in base ai tuoi impegni. Le certificazioni ti permettono di confermare e dimostrare le tue abilità e competenze relative alle tecnologie Google Cloud.

Ultimo aggiornamento del manuale: 26 gennaio 2024

Ultimo test del lab: 11 dicembre 2023

Copyright 2024 Google LLC Tutti i diritti riservati. Google e il logo Google sono marchi di Google LLC. Tutti gli altri nomi di società e prodotti sono marchi delle rispettive società a cui sono associati.