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.

GSP751

Panoramica

Man mano che gestisci la tua infrastruttura con Terraform, vengono create configurazioni sempre più complesse. Non esiste un limite intrinseco alla complessità di un file di configurazione o di una directory di Terraform, quindi puoi continuare a scrivere e aggiornare i file di configurazione in un'unica directory. Se procedi in questo modo, però, potresti riscontrare uno o più dei seguenti problemi:

• I file di configurazione diventeranno sempre più difficili da comprendere ed esplorare.
• L'aggiornamento della configurazione diventerà più rischioso perché un aggiornamento in un blocco può causare conseguenze indesiderate su altri blocchi della configurazione.
• Può aumentare la duplicazione di blocchi di configurazione simili; ad esempio, quando configuri ambienti di sviluppo/temporanei/di produzione separati, questi genereranno un carico maggiore in fase di aggiornamento di quelle parti della configurazione.
• Se vuoi condividere parti della configurazione tra progetti e team, tagliare e incollare i blocchi di configurazione in diversi progetti può essere una soluzione soggetta a errori e difficile da gestire.

In questo lab scoprirai in che modo i moduli possono risolvere questi problemi, qual è la struttura di un modulo Terraform e quali sono le best practice per l'utilizzo e la creazione di moduli.

A cosa servono i moduli?

Ecco alcuni modi in cui i moduli possono essere utili per risolvere i problemi indicati sopra:

• Organizzare la configurazione: i moduli consentono di esplorare, comprendere e aggiornare più facilmente la configurazione, mantenendo insieme parti della configurazione correlate tra loro. Anche un'infrastruttura di complessità moderata può richiedere l'implementazione di centinaia o migliaia di righe di configurazione. Grazie ai moduli, puoi organizzare la configurazione in componenti logici.

• Incapsulare la configurazione: un altro vantaggio dell'utilizzo dei moduli consiste nell'incapsulamento della configurazione in componenti logici separati. L'incapsulamento può contribuire a evitare conseguenze indesiderate, ad esempio una modifica in una parte della configurazione che causa modifiche in altre parti della configurazione, e riduce le possibilità di errori banali come l'utilizzo dello stesso nome per due risorse diverse.

• Riutilizzare la configurazione: scrivere tutta la configurazione senza utilizzare il codice esistente può essere un'attività lunga e soggetta a errori. I moduli ti consentono di risparmiare tempo e ridurre errori costosi attraverso il riutilizzo di una configurazione già scritta da te, da altri membri del tuo team o da altri professionisti di Terraform che hanno pubblicato moduli che puoi utilizzare. Puoi anche condividere i moduli scritti da te con il tuo team o con il pubblico, mettendo a loro disposizione i frutti del tuo lavoro.

• Assicurare coerenza e best practice: i moduli possono essere utili per garantire la coerenza delle tue configurazioni. Grazie alla coerenza, le configurazioni complesse diventano più facili da comprendere ed è possibile applicare le best practice in tutta la configurazione. Ad esempio, i cloud provider offrono molte opzioni per la configurazione di servizi di archiviazione di oggetti, come Amazon S3 (Simple Storage Service) o i bucket Cloud Storage di Google. Molti incidenti di sicurezza di alto profilo hanno coinvolto l'archiviazione non corretta di oggetti protetti e, dato il numero di opzioni di configurazione complesse coinvolte, è facile che questi servizi vengano accidentalmente configurati in modo errato.

L'uso dei moduli può aiutare a ridurre questi errori. Ad esempio, potresti creare un modulo per descrivere come verranno configurati tutti i bucket del sito web pubblico dell'organizzazione e un altro modulo per i bucket privati utilizzati per le applicazioni di logging. Inoltre, se è necessario aggiornare una configurazione per un tipo di risorsa, con i moduli è possibile apportare l'aggiornamento in un unico posto e fare in modo che venga applicato a tutti i casi in cui viene utilizzato quel modulo.

Obiettivi

In questo lab imparerai a:

• Utilizzare un modulo del registro
• Creare un modulo

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:

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

2. Fai clic su Apri console Google. 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.

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

3. Se necessario, copia il Nome utente dal riquadro Dettagli lab e incollalo nella finestra di dialogo di accesso. Fai clic su Avanti.

4. Copia la Password dal riquadro Dettagli lab e incollala nella finestra di dialogo di benvenuto. Fai clic su Avanti.

   Importante: devi utilizzare le credenziali presenti nel riquadro di sinistra. Non utilizzare le tue credenziali Google Cloud Skills Boost. Nota: utilizzare il tuo account Google Cloud per questo lab potrebbe comportare addebiti aggiuntivi.

5. 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: puoi visualizzare il menu con un elenco di prodotti e servizi Google Cloud facendo 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.

Che cos'è un modulo Terraform?

Un modulo Terraform è un set di file di configurazione di Terraform in un'unica directory. Anche una semplice configurazione composta da un'unica directory con uno o più file .tf è un modulo. Quando esegui comandi Terraform direttamente da una directory di questo tipo, viene considerata un modulo principale. In questo senso, quindi, ogni configurazione di Terraform fa parte di un modulo. Possono esistere semplici set di file di configurazione di Terraform come questo:

├── LICENSE ├── README.md ├── main.tf ├── variables.tf ├── outputs.tf

In questo caso, quando esegui comandi Terraform dalla directory minimal-module, il contenuto di quella directory è considerato il modulo principale.

Come richiamare i moduli

I comandi Terraform utilizzeranno direttamente solo i file di configurazione in una directory, che in genere è la directory di lavoro corrente. La tua configurazione, però, può utilizzare blocchi di moduli per richiamare i moduli in altre directory. Quando Terraform rileva un blocco di modulo, carica ed elabora i file di configurazione di quel modulo.

Un modulo che viene chiamato da un'altra configurazione a volte è definito "modulo figlio" di quella configurazione.

Moduli locali e remoti

I moduli possono essere caricati dal file system locale o da un'origine remota. Terraform supporta diverse origini remote, ad esempio il registro Terraform, la maggior parte dei sistemi di controllo delle versioni, gli URL HTTP e i registri di moduli privati Terraform Cloud o Terraform Enterprise.

Best practice relative ai moduli

Per molti aspetti, i moduli Terraform sono concettualmente simili alle librerie, ai pacchetti o ai moduli di altri linguaggi di programmazione e possono fornire molti degli stessi vantaggi. Analogamente a quasi tutti i programmi informatici di una certa pertinenza, le configurazioni di Terraform in scenari reali dovrebbero utilizzare quasi sempre i moduli per assicurare i vantaggi citati sopra.

È consigliabile che i professionisti Terraform utilizzino i moduli seguendo queste best practice:

• Iniziare a scrivere la configurazione con un piano per i moduli. Anche in configurazioni Terraform di complessità modesta gestite da un'unica persona, i vantaggi che derivano dell'utilizzo dei moduli giustificano ampiamente il tempo necessario per utilizzarli adeguatamente.

• Usare moduli logici per organizzare e incapsulare il codice. Anche se non usi o non pubblichi moduli remoti, organizzare la configurazione in termini di moduli fin dall'inizio ridurrà significativamente il carico di lavoro per la manutenzione e l'aggiornamento della configurazione man mano che l'infrastruttura diventa più complessa.

• Usare il registro Terraform pubblico per trovare moduli utili. Questo consente di implementare la configurazione modo in rapido e sicuro, attingendo al lavoro di altri.

• Pubblicare e condividere moduli con il team. L'infrastruttura è gestita per lo più da un team di persone e i moduli sono uno strumento importante a disposizione dei team per creare e mantenere l'infrastruttura. Come indicato in precedenza, è possibile pubblicare moduli pubblicamente o privatamente. In un modulo successivo di questa serie scoprirai come farlo.

Attività 1: utilizza i moduli del registro

In questa sezione vengono utilizzati i moduli del registro Terraform per eseguire il provisioning di un ambiente di esempio in Google Cloud. I concetti impiegati qui sono validi per qualsiasi modulo da qualsiasi origine.

• Apri la pagina del registro Terraform per il modulo Terraform Network in una nuova scheda o finestra del browser. La pagina sarà simile a questa:

La pagina include informazioni sul modulo e un link al repository di origine. Nella parte destra della pagina troverai un elenco a discesa per selezionare la versione del modulo e le istruzioni per utilizzare il modulo per eseguire il provisioning dell'infrastruttura.

Quando si chiama un modulo, è necessario l'argomento source. In questo esempio, Terraform cercherà nel registro Terraform un modulo che corrisponde alla stringa specificata. Per l'origine dei moduli si può utilizzare anche un URL o un percorso file locale. Vedi la documentazione di Terraform per un elenco di possibili origini di moduli.

L'altro argomento mostrato qui è version. Per le origini supportate, la versione consentirà di definire le versioni del modulo che verranno caricate. In questo lab specificherai un numero di versione esatto per i moduli utilizzati. Per conoscere altri modi per specificare le versioni, consulta la documentazione del modulo.

Gli altri argomenti per i blocchi di moduli vengono trattati come variabili di input per i moduli.

Crea una configurazione Terraform

1. Per iniziare, esegui il comando seguente in Cloud Shell per clonare il progetto di esempio dal repository GitHub di moduli Google Terraform e passare al ramo v6.0.1:

git clone https://github.com/terraform-google-modules/terraform-google-network cd terraform-google-network git checkout tags/v6.0.1 -b v6.0.1

In questo modo ti assicuri di usare il numero di versione corretto.

2. 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.

3. Nell'editor, passa a terraform-google-network/examples/simple_project e apri il file main.tf. La configurazione main.tf sarà analoga a quanto segue:

module "test-vpc-module" { source = "terraform-google-modules/network/google" version = "~> 6.0" project_id = var.project_id # Replace this with your project ID network_name = "my-custom-mode-network" mtu = 1460 subnets = [ { subnet_name = "subnet-01" subnet_ip = "10.10.10.0/24" subnet_region = "us-west1" }, { subnet_name = "subnet-02" subnet_ip = "10.10.20.0/24" subnet_region = "us-west1" subnet_private_access = "true" subnet_flow_logs = "true" }, { subnet_name = "subnet-03" subnet_ip = "10.10.30.0/24" subnet_region = "us-west1" subnet_flow_logs = "true" subnet_flow_logs_interval = "INTERVAL_10_MIN" subnet_flow_logs_sampling = 0.7 subnet_flow_logs_metadata = "INCLUDE_ALL_METADATA" subnet_flow_logs_filter = "false" } ] }

Questa configurazione include un blocco importante:

• module "test-vpc-module" definisce un VPC (Virtual Private Cloud), che fornirà i servizi di rete per il resto dell'infrastruttura.

Imposta i valori per le variabili di input del modulo

Alcune variabili di input sono obbligatorie. Ciò significa che il modulo non è in grado di fornire un valore predefinito, ma è necessario specificare un valore esplicito per la corretta esecuzione di Terraform.

• All'interno del blocco "test-vpc-module" del modulo, esamina le variabili di input che stai impostando. Ognuna di queste variabili di input è documentata nel registro Terraform. Gli input obbligatori per questo modulo sono:

  • network_name: il nome della rete che viene creata
  • project_id: l'ID del progetto in cui verrà creato questo VPC
  • subnets: l'elenco delle subnet che vengono create

Per utilizzare la maggior parte dei moduli, dovrai passare le variabili di input alla configurazione del modulo. La configurazione che chiama un modulo si occupa di impostare i propri valori di input, che vengono passati come argomenti al blocco del modulo. A parte source e version, gli argomenti per un blocco di modulo imposteranno per lo più valori variabili.

Nella pagina del registro Terraform per il modulo di rete Google Cloud, una scheda Inputs descrive tutte le variabili di input supportate da quel modulo.

Definisci le variabili di input principali

L'uso delle variabili di input con i moduli è molto simile all'uso delle variabili in qualsiasi configurazione Terraform. Un procedimento comune consiste nell'identificare le variabili di input del modulo che potrebbero essere modificate in futuro, quindi creare variabili corrispondenti nel file variables.tf della configurazione con valori predefiniti appropriati. Queste variabili possono quindi essere passate al blocco del modulo come argomenti.

1. Per recuperare l'ID progetto, esegui il comando seguente in Cloud Shell:

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

2. Nell'editor, sempre nella stessa directory, vai a variables.tf.

3. Compila la variabile project_id con l'output del comando precedente. Devi rispettare il formato seguente e impostare il valore default per la variabile:

variable "project_id" { description = "The project ID to host the network in" default = "FILL IN YOUR PROJECT ID HERE" }

4. In variables.tf, aggiungi la variabile network_name. Puoi utilizzare il nome example-vpc o un altro nome a tua scelta. Devi rispettare il formato seguente e impostare il valore default per la variabile:

variable "network_name" { description = "The name of the VPC network being created" default = "example-vpc" }

5. Tornando al file main.tf, aggiorna il parametro network_name per utilizzare la variabile appena definita impostando il valore su var.network_name.

module "test-vpc-module" { ... project_id = var.project_id network_name = var.network_name ...

6. Nel file main.tf, aggiorna le regioni di subnet alle righe 35, 40 e 47 da us-west1 a . In questo modo ti assicuri che le subnet vengano create nella regione consentita del progetto. Il modulo dovrebbe essere simile al seguente:

subnets = [ { subnet_name = "subnet-01" subnet_ip = "10.10.10.0/24" subnet_region = "{{{project_0.default_region | REGION}}}" }, { subnet_name = "subnet-02" subnet_ip = "10.10.20.0/24" subnet_region = "{{{project_0.default_region | REGION}}}" subnet_private_access = "true" subnet_flow_logs = "true" }, { subnet_name = "subnet-03" subnet_ip = "10.10.30.0/24" subnet_region = "{{{project_0.default_region | REGION}}}" ... .. }

Definisci i valori di output principali

I moduli hanno anche valori di output, che vengono definiti all'interno del modulo con la parola chiave output. Per accedere a questi valori, fai riferimento a module.<MODULE NAME>.<OUTPUT NAME>. Come le variabili di input, gli output del modulo sono elencati nella scheda outputs del registro Terraform.

In genere, gli output dei moduli vengono passati ad altre parti della configurazione o definiti come output nel modulo principale. In questo lab vedremo entrambi gli utilizzi.

• Passa al file outputs.tf nella directory della configurazione. Verifica che il file contenga quanto segue:

output "network_name" { value = module.test-vpc-module.network_name description = "The name of the VPC being created" } output "network_self_link" { value = module.test-vpc-module.network_self_link description = "The URI of the VPC being created" } output "project_id" { value = module.test-vpc-module.project_id description = "VPC project id" } output "subnets_names" { value = module.test-vpc-module.subnets_names description = "The names of the subnets being created" } output "subnets_ips" { value = module.test-vpc-module.subnets_ips description = "The IP and cidrs of the subnets being created" } output "subnets_regions" { value = module.test-vpc-module.subnets_regions description = "The region where subnets will be created" } output "subnets_private_access" { value = module.test-vpc-module.subnets_private_access description = "Whether the subnets will have access to Google API's without a public IP" } output "subnets_flow_logs" { value = module.test-vpc-module.subnets_flow_logs description = "Whether the subnets will have VPC flow logs enabled" } output "subnets_secondary_ranges" { value = module.test-vpc-module.subnets_secondary_ranges description = "The secondary ranges associated with these subnets" } output "route_names" { value = module.test-vpc-module.route_names description = "The routes associated with this VPC" }

Esegui il provisioning dell'infrastruttura

1. In Cloud Shell, passa alla tua directory simple_project:

cd ~/terraform-google-network/examples/simple_project

2. Inizializza la tua configurazione Terraform:

terraform init

3. Crea il tuo VPC:

terraform apply

4. Per applicare le modifiche e proseguire, rispondi yes alla richiesta.

Bene. Hai appena utilizzato il tuo primo modulo. L'output della configurazione dovrebbe essere simile a questo:

Outputs: network_name = "example-vpc" network_self_link = "https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-01-a68489b0625b/global/networks/example-vpc" project_id = "" route_names = [] subnets_flow_logs = [ false, true, true, ] subnets_ips = [ "10.10.10.0/24", "10.10.20.0/24", "10.10.30.0/24", ] subnets_names = [ "subnet-01", "subnet-02", "subnet-03", ] .... ....

Scopri come funzionano i moduli

La prima volta che utilizzi un nuovo modulo, devi eseguire terraform init o terraform get per installarlo. Quando viene eseguito uno di questi comandi, Terraform installa i nuovi moduli nella directory .terraform/modules all'interno della directory di lavoro della configurazione. Per i moduli locali, Terraform creerà un collegamento simbolico alla directory del modulo. Pertanto, le eventuali modifiche apportate ai moduli locali saranno applicate immediatamente, senza dover eseguire di nuovo terraform get.

Pulisci l'infrastruttura

A questo punto hai visto come utilizzare i moduli dal registro Terraform, come configurare quei moduli con variabili di input e come ottenere valori di output da quei moduli.

1. Elimina l'infrastruttura che hai creato:

terraform destroy

2. Rispondi yes alla richiesta. Terraform eliminerà l'infrastruttura che hai creato.

3. Dopo aver eliminato la risorsa, elimina la cartella terraform-google-network.

cd ~ rm -rd terraform-google-network -f

Fai clic su Controlla i miei progressi per verificare l'obiettivo. Esegui il provisioning dell'infrastruttura.

Attività 2: crea un modulo

Nell'ultima attività hai usato un modulo dal registro Terraform per creare una rete VPC in Google Cloud. Anche se utilizzare i moduli Terraform esistenti è un'abilità importante, è bene che ogni professionista Terraform impari a creare moduli. Ti consigliamo di creare ogni configurazione Terraform supponendo che venga utilizzata come modulo. Questo ti aiuterà a progettare una configurazione flessibile, riutilizzabile e componibile.

Come probabilmente sai già, in Terraform ogni configurazione viene trattata come modulo. Quando esegui i comandi terraform o usi Terraform Cloud o Terraform Enterprise per eseguire Terraform da remoto, la directory di destinazione che contiene la configurazione Terraform viene considerata il modulo principale.

In questa attività creerai un modulo per gestire i bucket Cloud Storage utilizzati per ospitare siti web statici.

Struttura del modulo

In Terraform, tutte le directory locali indicate nell'argomento source di un blocco module vengono considerate un modulo. Ecco una tipica struttura di file per un nuovo modulo:

├── LICENSE ├── README.md ├── main.tf ├── variables.tf ├── outputs.tf Nota: nessuno di questi file è obbligatorio o ha un significato particolare per Terraform quando utilizza il tuo modulo. Puoi creare un modulo con un singolo file .tf o utilizzare la struttura di file che preferisci.

Ognuno di questi file ha uno scopo:

• LICENSE contiene la licenza con cui il modulo verrà distribuito. Quando condividi il modulo, il file LICENSE fa sapere agli utenti quali sono i termini in base ai quali viene reso disponibile. Questo file non viene utilizzato da Terraform.
• README.md contiene la documentazione in formato markdown che descrive come utilizzare il modulo. Terraform non utilizza questo file, ma i servizi come il registro Terraform e GitHub ne mostreranno il contenuto ai visitatori della pagina del registro Terraform o di GitHub del tuo modulo.
• main.tf contiene il set principale di configurazioni per il modulo. Puoi anche creare altri file di configurazione e organizzarli nel modo più appropriato per il tuo progetto.
• variables.tf contiene le definizioni delle variabili per il modulo. Quando il modulo viene utilizzato da altri, le variabili verranno configurate come argomenti nel blocco del modulo. Dato che tutte le variabili di Terraform devono essere definite, le variabili che non includono valori predefiniti diventeranno argomenti obbligatori. Una variabile con un valore predefinito può essere fornita come argomento del modulo, con conseguente override del valore predefinito.
• outputs.tf contiene le definizioni dell'output per il modulo. Gli output del modulo vengono messi a disposizione della configurazione mediante il modulo, quindi spesso vengono utilizzati per passare informazioni sulle parti dell'infrastruttura definite dal modulo ad altre parti della configurazione.

Presta attenzione a questi file e assicurati che non vengano distribuiti come parte del modulo:

• I file terraform.tfstate e terraform.tfstate.backup contengono il tuo stato Terraform e rappresentano il modo in cui Terraform tiene traccia della relazione tra la tua configurazione e l'infrastruttura di cui esegue il provisioning.
• La directory .terraform contiene i moduli e i plug-in utilizzati per il provisioning dell'infrastruttura. Questi file sono specifici di una singola istanza di Terraform durante il provisioning dell'infrastruttura, non della configurazione dell'infrastruttura definita nei file .tf.
• I file *.tfvars non devono necessariamente essere distribuiti insieme al modulo, a meno che non siano utilizzati anche come configurazione Terraform autonoma perché le variabili di input del modulo vengono impostate tramite argomenti per il blocco del modulo nella configurazione.

Nota: se monitori le modifiche al tuo modulo in un sistema di controllo della versione come Git, è preferibile configurare il sistema in modo che ignori questi file. Per un esempio, vedi questo file .gitignore da GitHub.

Crea un modulo

Passa alla directory home e crea un modulo principale costruendo un nuovo file di configurazione main.tf. Poi crea una directory denominata modules che contiene un'altra cartella denominata gcs-static-website-bucket. Utilizzerai questi tre file di configurazione all'interno della directory gcs-static-website-bucket: website.tf, variables.tf e outputs.tf.

1. Crea la directory per il nuovo modulo:

cd ~ touch main.tf mkdir -p modules/gcs-static-website-bucket

2. Passa alla directory del modulo ed esegui i comandi seguenti per creare tre file vuoti:

cd modules/gcs-static-website-bucket touch website.tf variables.tf outputs.tf

3. Nella directory gcs-static-website-bucket, esegui il comando seguente per creare un file denominato README.md con i contenuti seguenti:

tee -a README.md <<EOF # GCS static website bucket This module provisions Cloud Storage buckets configured for static website hosting. EOF Nota: la scelta della licenza corretta per i tuoi moduli esula dall'ambito di questo lab. In questo lab viene utilizza la licenza open source Apache 2.0.

4. Crea un altro file denominato LICENSE con i contenuti seguenti:

tee -a LICENSE <<EOF Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. EOF Nota: nessuno di questi file è richiesto o utilizzato da Terraform. Rappresentano una best practice per i moduli che potrebbero essere condivisi con altri.

La struttura di directory del modulo corrente dovrebbe risultare così:

main.tf modules/ └── gcs-static-website-bucket ├── LICENSE ├── README.md ├── website.tf ├── outputs.tf └── variables.tf

5. Aggiungi questa risorsa del bucket Cloud Storage al tuo file website.tf all'interno della directory modules/gcs-static-website-bucket:

resource "google_storage_bucket" "bucket" { name = var.name project = var.project_id location = var.location storage_class = var.storage_class labels = var.labels force_destroy = var.force_destroy uniform_bucket_level_access = true versioning { enabled = var.versioning } dynamic "retention_policy" { for_each = var.retention_policy == null ? [] : [var.retention_policy] content { is_locked = var.retention_policy.is_locked retention_period = var.retention_policy.retention_period } } dynamic "encryption" { for_each = var.encryption == null ? [] : [var.encryption] content { default_kms_key_name = var.encryption.default_kms_key_name } } dynamic "lifecycle_rule" { for_each = var.lifecycle_rules content { action { type = lifecycle_rule.value.action.type storage_class = lookup(lifecycle_rule.value.action, "storage_class", null) } condition { age = lookup(lifecycle_rule.value.condition, "age", null) created_before = lookup(lifecycle_rule.value.condition, "created_before", null) with_state = lookup(lifecycle_rule.value.condition, "with_state", null) matches_storage_class = lookup(lifecycle_rule.value.condition, "matches_storage_class", null) num_newer_versions = lookup(lifecycle_rule.value.condition, "num_newer_versions", null) } } } }

La documentazione del fornitore si trova su GitHub.

6. Passa al file variables.tf nel modulo e aggiungi il codice seguente:

variable "name" { description = "The name of the bucket." type = string } variable "project_id" { description = "The ID of the project to create the bucket in." type = string } variable "location" { description = "The location of the bucket." type = string } variable "storage_class" { description = "The Storage Class of the new bucket." type = string default = null } variable "labels" { description = "A set of key/value label pairs to assign to the bucket." type = map(string) default = null } variable "bucket_policy_only" { description = "Enables Bucket Policy Only access to a bucket." type = bool default = true } variable "versioning" { description = "While set to true, versioning is fully enabled for this bucket." type = bool default = true } variable "force_destroy" { description = "When deleting a bucket, this boolean option will delete all contained objects. If false, Terraform will fail to delete buckets which contain objects." type = bool default = true } variable "iam_members" { description = "The list of IAM members to grant permissions on the bucket." type = list(object({ role = string member = string })) default = [] } variable "retention_policy" { description = "Configuration of the bucket's data retention policy for how long objects in the bucket should be retained." type = object({ is_locked = bool retention_period = number }) default = null } variable "encryption" { description = "A Cloud KMS key that will be used to encrypt objects inserted into this bucket" type = object({ default_kms_key_name = string }) default = null } variable "lifecycle_rules" { description = "The bucket's Lifecycle Rules configuration." type = list(object({ # Object with keys: # - type - The type of the action of this Lifecycle Rule. Supported values: Delete and SetStorageClass. # - storage_class - (Required if action type is SetStorageClass) The target Storage Class of objects affected by this Lifecycle Rule. action = any # Object with keys: # - age - (Optional) Minimum age of an object in days to satisfy this condition. # - created_before - (Optional) Creation date of an object in RFC 3339 (e.g. 2017-06-13) to satisfy this condition. # - with_state - (Optional) Match to live and/or archived objects. Supported values include: "LIVE", "ARCHIVED", "ANY". # - matches_storage_class - (Optional) Storage Class of objects to satisfy this condition. Supported values include: MULTI_REGIONAL, REGIONAL, NEARLINE, COLDLINE, STANDARD, DURABLE_REDUCED_AVAILABILITY. # - num_newer_versions - (Optional) Relevant only for versioned objects. The number of newer versions of an object to satisfy this condition. condition = any })) default = [] }

7. Aggiungi un output al modulo nel file outputs.tf all'interno del modulo stesso:

output "bucket" { description = "The created storage bucket" value = google_storage_bucket.bucket }

Come per le variabili, gli output nei moduli svolgono la stessa funzione che hanno nel modulo principale, ma sono accessibili in un modo diverso. Agli output di un modulo è possibile accedere come attributi di sola lettura nell'oggetto del modulo, che è disponibile all'interno della configurazione che chiama il modulo.

8. Torna al file main.tf nella directory root e aggiungi un riferimento al nuovo modulo:

module "gcs-static-website-bucket" { source = "./modules/gcs-static-website-bucket" name = var.name project_id = var.project_id location = "{{{project_0.default_region | REGION}}}" lifecycle_rules = [{ action = { type = "Delete" } condition = { age = 365 with_state = "ANY" } }] }

9. Nella directory root, crea un file outputs.tf per il modulo principale:

cd ~ touch outputs.tf

10. Aggiungi il codice seguente al file outputs.tf:

output "bucket-name" { description = "Bucket names." value = "module.gcs-static-website-bucket.bucket" }

11. Nella directory root, crea un file variables.tf:

touch variables.tf

12. Aggiungi il seguente codice al file variables.tf. Imposta le variabili project_id e name sul valore predefinito per il tuo ID progetto: .

variable "project_id" { description = "The ID of the project in which to provision resources." type = string default = "FILL IN YOUR PROJECT ID HERE" } variable "name" { description = "Name of the buckets to create." type = string default = "FILL IN A (UNIQUE) BUCKET NAME HERE" } Nota: il nome del bucket di archiviazione deve essere univoco a livello globale. In genere, un buon metodo per creare un nome di bucket univoco consiste nell'utilizzare il tuo nome e la data. Puoi anche usare l'ID progetto.

Installa il modulo locale

Quando aggiungi un nuovo modulo a una configurazione, Terraform deve installare il modulo prima di poterlo utilizzare. I comandi terraform get e terraform init consentono entrambi di installare e aggiornare i moduli. Il comando terraform init, inoltre, inizializza i backend e installa i plug-in.

1. Installa il modulo:

terraform init

2. Esegui il provisioning del bucket:

terraform apply

3. Rispondi yes alla richiesta. Verrà eseguito il provisioning del bucket e delle altre risorse.

Carica i file nel bucket

A questo punto hai configurato e utilizzato il tuo modulo per creare un sito web statico. Potresti avere l'esigenza di visitare il sito web statico. Al momento il bucket è vuoto, quindi non c'è niente da visualizzare sul sito web. Per vedere contenuti, dovrai caricare oggetti nel bucket. Puoi caricare i contenuti della directory www nel repository GitHub.

1. Scarica i contenuti di esempio nella tua directory home:

cd ~ curl https://raw.githubusercontent.com/hashicorp/learn-terraform-modules/master/modules/aws-s3-static-website-bucket/www/index.html > index.html curl https://raw.githubusercontent.com/hashicorp/learn-terraform-modules/blob/master/modules/aws-s3-static-website-bucket/www/error.html > error.html

2. Copia i file nel bucket, sostituendo YOUR-BUCKET-NAME con il nome del tuo bucket di archiviazione:

gsutil cp *.html gs://YOUR-BUCKET-NAME

3. In una nuova scheda del browser, vai al sito web https://storage.cloud.google.com/YOUR-BUCKET-NAME/index.html, sostituendo YOUR-BUCKET-NAME con il nome del tuo bucket di archiviazione.

Dovrebbe apparire una pagina web HTML di base che dice Niente da visualizzare.

Fai clic su Controlla i miei progressi per verificare l'obiettivo. Crea un modulo.

Pulisci il sito web e l'infrastruttura

In ultimo, pulirai il tuo progetto eliminando l'infrastruttura che hai appena creato.

1. Elimina le tue risorse Terraform:

terraform destroy

Quando rispondi yes alla richiesta, Terraform eliminerà tutte le risorse che hai creato durante questo lab.

Complimenti!

In questo lab hai appreso le nozioni fondamentali sui moduli Terraform e hai scoperto come utilizzare un modulo preesistente tratto dal registro. Quindi hai creato un modulo personalizzato per creare un sito web statico ospitato in un bucket Cloud Storage. Contestualmente, hai definito gli input, gli output e le variabili per i tuoi file di configurazione e hai imparato quali sono le best practice per la creazione di moduli.

Passaggi successivi/Scopri di più

Tramite questi link puoi accedere ad altre esercitazioni pratiche su 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.