Questa pagina è stata tradotta dall'API Cloud Translation.

Guida introduttiva al toolkit di Cloud Foundation

1. Introduzione al corso CFT 101

Ultimo aggiornamento: 2022-02-11

Cos'è Cloud Foundation Toolkit?

In sostanza, CFT fornisce modelli di best practice per iniziare rapidamente a utilizzare la piattaforma Google Cloud. In questo tutorial imparerai a contribuire al Cloud Foundation Toolkit.

Che cosa ti serve

Un account GitHub.
Docker installato sulla macchina o utilizza Cloud Shell ( installazione per Mac, installazione Windows)
Editor di codice per la modifica del codice (ad esempio: codice Visual Studio)
Familiarità di base con Git e GitHub
Una certa esperienza con Terraform e con Infrastructure as Code
Autorizzazione per concedere il ruolo Autore progetto a un account di servizio
Un'organizzazione Google Cloud, una cartella di test e un account di fatturazione

Cosa creerai

In questo codelab, imparerai come contribuire al Cloud Foundation Toolkit (CFT).

Imparerai a:

Imposta un ambiente di sviluppo per contribuire a CFT
Aggiungere una funzionalità a un modulo CFT
Aggiungi test per la funzionalità aggiunta
Esegui test di integrazione in CFT
Esegui test lint
Esegui il commit del codice su GitHub e invia una richiesta di pull (PR)

Eseguirai tutti i passaggi precedenti aggiungendo una nuova funzionalità al modulo CFT di Google Cloud Storage. Stai aggiungendo un'etichetta denominata "silly_label" che viene aggiunta automaticamente a tutti i bucket creati tramite il modulo CFT di GCS. Inoltre, potrai scrivere test per convalidare la tua caratteristica e garantire l'integrazione end-to-end.

2. Configura l'ambiente di sviluppo

Se vuoi, puoi utilizzare Cloud Shell per i tuoi scopi di sviluppo. Se non vuoi utilizzare Cloud Shell per contribuire a CFT, puoi configurare il tuo ambiente di sviluppo sulla tua macchina.

Configura Git

GitHub si basa su un sistema di controllo della versione (VCS) open source chiamato Git. Git è responsabile di tutto ciò che riguarda GitHub che avviene localmente sulla tua macchina o su Cloud Shell.

Quando utilizzi Cloud Shell, non è necessario installare Git perché è preinstallato.

$ git --version
# This will display the git version on the Cloud Shell.

Se stai configurando il tuo ambiente di sviluppo sulla tua macchina, devi installare Git.

Impostazione del nome utente e dell'email in Git

Git utilizza un nome utente per associare i commit a un'identità. Il nome utente Git non è uguale al nome utente GitHub.

Puoi modificare il nome associato ai tuoi commit Git utilizzando il comando git config. La modifica del nome associato ai commit Git utilizzando git config influirà solo sui commit futuri e non cambierà il nome utilizzato per i commit precedenti.

Hai configurato Git correttamente e dovresti essere in grado di creare un fork, creare e clonare i rami. Useremo molto Git in questo codelab.

3. Repository GCS di Fork CFT

Crea un fork di un repository CFT

Hai configurato Git sulla tua macchina locale o su Cloud Shell nel passaggio precedente. Ora devi creare il fork del repository CFT di Google Cloud Storage per iniziare a contribuire.

Un fork è una copia di un repository. Il forking di un repository ti consente di sperimentare liberamente le modifiche senza influire sul progetto originale.

Di solito i fork sono usati per proporre modifiche al progetto di un'altra persona o per usare il progetto di un'altra persona come punto di partenza per la tua idea.

Ad esempio, puoi utilizzare i fork per proporre modifiche relative alla correzione di un bug. Per correggere un bug, puoi:

Crea un fork del repository.
Apporta la correzione.
Invia una richiesta di pull al proprietario del progetto.

Procedura per il fork di un repository CFT:

Apri il browser web e vai al repository terraform-google-modules/terraform-google-cloud-storage. Utilizzeremo questo repository per l'intero codelab.
Nell'angolo in alto a destra della pagina, fai clic su Fork.

Verrà visualizzata un'opzione per scegliere dove inserire il fork, scegliere il tuo profilo e verrà creato un fork del repository.

Clonare la fork in locale

Il fork che hai creato è una copia del repository del modulo GCS. Ora clonerai questo repository nel tuo ambiente locale per aggiungere la tua nuova caratteristica.

Procedura per clonare la forchetta:

Apri il browser web e vai al tuo fork su terraform-google-modules/terraform-google-cloud-storage.
Nell'angolo in alto a destra, troverai il "Codice" fai clic sul pulsante.

Dopo aver fatto clic sul pulsante fai clic sul pulsante "Copia" per copiare l'URL della forchetta. Utilizzerai questo URL per clonare il tuo fork nel tuo ambiente locale.

Vai a un terminale nel tuo VSCode o nella tua macchina e clona il fork.

$ git clone <url>
# This command will clone your fork locally.
# Paste the copied URL from the previous step.

Ora che hai clonato il fork in locale, devi accedere al repository, creare un nuovo ramo dal fork e apportare modifiche al codice nel ramo temporaneo.

Per convenzione, puoi denominare il ramo come segue:

Per le richieste di funzionalità: feature/feature-name
Per gli aggiornamenti interni, internal/change-name
Per correzioni di bug: bugfix/issue-name

Poiché stai aggiungendo una nuova funzionalità, puoi chiamare la tua filiale temporanea feature/silly_label

$ cd terraform-google-cloud-storage
# This command takes you into the cloned directory on your local machine.

$ git branch
# This command tells your current branch
# When you run this for the first time after you have cloned, your 
# output should say "master", that is your fork.

$ git checkout -b feature/silly_label
# This command creates a new branch on your fork and switches your 
# branch to the newly created branch.

$ git branch
# This command will confirm your current branch to be "feature/silly_label"

Ora è tutto pronto per iniziare a lavorare sul Cloud Foundation Toolkit.

4. Crea un ambiente di test

Il processo di sviluppo standard di CFT si basa sull'utilizzo di un progetto di test isolato per i test. Questo passaggio ti guiderà nella creazione del progetto di test (basato su una configurazione standard) tramite un account di servizio.

0. Installa Docker Engine

Se utilizzi la macchina a scopo di sviluppo, devi installare Docker Engine.

1. Installa Google Cloud SDK

Non è necessario installare Google Cloud SDK se utilizzi Cloud Shell di Google Cloud.

Vai a Google Cloud SDK e scarica il programma di installazione interattivo per la tua piattaforma.

2. Imposta configurazione

Per creare un ambiente di test, devi avere un'organizzazione Google Cloud, una cartella di test e un account di fatturazione. Questi valori devono essere impostati tramite le variabili di ambiente:

export TF_VAR_org_id="your_org_id"
export TF_VAR_folder_id="your_folder_id"
export TF_VAR_billing_account="your_billing_account_id"

3. Configura l'account di servizio

Prima di creare un ambiente di test, devi scaricare una chiave dell'account di servizio nell'ambiente di test. Questo account di servizio avrà bisogno dei ruoli Autore progetto, Utente account di fatturazione e Visualizzatore organizzazione. Questi passaggi ti aiutano a creare un nuovo account di servizio, ma puoi anche riutilizzare un account esistente.

3.1 Creare o selezionare un progetto Google Cloud di origine

Prima di creare il tuo account di servizio, devi selezionare un progetto in cui ospitarlo. Puoi anche creare un nuovo progetto.

gcloud config set core/project YOUR_PROJECT_ID

3.2 Abilita le API Google Cloud

Abilita le seguenti API Google Cloud nel tuo progetto di origine:

gcloud services enable cloudresourcemanager.googleapis.com
gcloud services enable iam.googleapis.com
gcloud services enable cloudbilling.googleapis.com

3.3 Creare l'account di servizio

Crea un nuovo account di servizio per gestire l'ambiente di test:

# Creating a service account for CFT.
gcloud iam service-accounts create cft-onboarding \
  --description="CFT Onboarding Terraform Service Account" \
  --display-name="CFT Onboarding"

# Assign SERVICE_ACCOUNT environment variable for later steps
export SERVICE_ACCOUNT=cft-onboarding@$(gcloud config get-value core/project).iam.gserviceaccount.com

Verifica che l'account di servizio sia stato creato:

gcloud iam service-accounts list --filter="EMAIL=${SERVICE_ACCOUNT}"

3.4 Concedi i ruoli Creatore progetto, Utente account di fatturazione e Visualizzatore organizzazione all'account di servizio:

gcloud resource-manager folders add-iam-policy-binding ${TF_VAR_folder_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/resourcemanager.projectCreator"
gcloud organizations add-iam-policy-binding ${TF_VAR_org_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/billing.user"
gcloud beta billing accounts add-iam-policy-binding ${TF_VAR_billing_account} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/billing.user"
gcloud organizations add-iam-policy-binding ${TF_VAR_org_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/resourcemanager.organizationViewer"

Ora hai un account di servizio che può essere utilizzato per gestire l'ambiente di test.

4. prepara la credenziale Terraform

Per creare l'ambiente di test, devi scaricare la chiave dell'account di servizio nella shell.

4.1 Chiave dell'account di servizio

Crea e scarica una chiave dell'account di servizio per Terraform

gcloud iam service-accounts keys create cft.json --iam-account=${SERVICE_ACCOUNT}

4.2 Configurare la credenziale Terraform

Fornisci la chiave a Terraform utilizzando la variabile di ambiente SERVICE_ACCOUNT_JSON, impostando il valore su contents della chiave dell'account di servizio.

export SERVICE_ACCOUNT_JSON=$(< cft.json)

Dopo aver archiviato le informazioni sulle credenziali nella variabile di ambiente, rimuovi il file della chiave. Se necessario, puoi ricreare una chiave in un secondo momento utilizzando lo stesso comando riportato sopra.

rm -rf cft.json

5. Crea un progetto di test per i deployment Terraform

Ora che è tutto pronto, puoi creare il progetto di test con un singolo comando. Esegui questo comando dalla directory radice di terraform-google-cloud-storage:

make docker_test_prepare

Quando esegui make docker_test_prepare vedrai l'output riportato di seguito. Al termine, riceverai il project_id di test creato, dove eseguirai il deployment e testerai il modulo Cloud Storage con la nuova funzionalità. Se riscontri problemi con il collegamento di un account di fatturazione, consulta la procedura di risoluzione dei problemi.

macbookpro3:terraform-google-cloud-storage user$ make docker_test_prepare
docker run --rm -it \
                -e SERVICE_ACCOUNT_JSON \
                -e TF_VAR_org_id \
                -e TF_VAR_folder_id \
                -e TF_VAR_billing_account \
                -v /Users/cft/terraform-google-cloud-storage:/workspace \
                gcr.io/cloud-foundation-cicd/cft/developer-tools:0.8.0 \
                /usr/local/bin/execute_with_credentials.sh prepare_environment
Activated service account credentials for: [cft-onboarding@<project_id>.iam.gserviceaccount.com]
Activated service account credentials for: [cft-onboarding@<project_id>.iam.gserviceaccount.com]
Initializing modules...

Initializing the backend...

Initializing provider plugins...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.google-beta: version = "~> 3.9"
* provider.null: version = "~> 2.1"
* provider.random: version = "~> 2.2"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
module.project.module.project-factory.null_resource.preconditions: Refreshing state... [id=8723188031607443970]
module.project.module.project-factory.null_resource.shared_vpc_subnet_invalid_name[0]: Refreshing state... [id=5109975723938185892]
module.project.module.gsuite_group.data.google_organization.org[0]: Refreshing state...
module.project.module.project-factory.random_id.random_project_id_suffix: Refreshing state... [id=rnk]
module.project.module.project-factory.google_project.main: Refreshing state... [id=<project-id>]
module.project.module.project-factory.google_project_service.project_services[0]: Refreshing state... [id=<project-id>/storage-api.googleapis.com]
module.project.module.project-factory.google_project_service.project_services[1]: Refreshing state... [id=<project-id>/cloudresourcemanager.googleapis.com]
module.project.module.project-factory.google_project_service.project_services[2]: Refreshing state... [id=<project-id>/compute.googleapis.com]
module.project.module.project-factory.data.null_data_source.default_service_account: Refreshing state...
module.project.module.project-factory.google_service_account.default_service_account: Refreshing state... [id=projects/ci-cloud-storage-ae79/serviceAccounts/project-service-account@<project-id>.iam.gserv
iceaccount.com]
module.project.module.project-factory.google_project_service.project_services[3]: Refreshing state... [id=<project-id>/serviceusage.googleapis.com]
module.project.module.project-factory.null_resource.delete_default_compute_service_account[0]: Refreshing state... [id=3576396874950891283]
google_service_account.int_test: Refreshing state... [id=projects/<project-id>/serviceAccounts/cft-onboarding@<project-id>.iam.gserviceaccount.com]
google_service_account_key.int_test: Refreshing state... [id=projects/<project-id>/serviceAccounts/cft-onboarding@<project-id>.iam.gserviceaccount.com/keys/351009a1e011e88049ab2097994d1c627a61
6961]
google_project_iam_member.int_test[1]: Refreshing state... [id=<project-id>/roles/iam.serviceAccountUser/serviceaccount:cft-onboarding@<project-id>.iam.gserviceaccount.com]
google_project_iam_member.int_test[0]: Refreshing state... [id=<project-id>/roles/storage.admin/serviceaccount:cft-onboarding@<project-id>.iam.gserviceaccount.com]

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

project_id = <test-project-id>
sa_key = <sensitive>
Found test/setup/make_source.sh. Using it for additional explicit environment configuration.

Hai creato un progetto di test a cui fa riferimento il parametro project_id, come puoi vedere nell'output della console. L'ambiente di sviluppo e test è configurato.

5. Aggiungi una nuova funzionalità al modulo CFT

Ora che l'ambiente di sviluppo e test è configurato, iniziamo ad aggiungere "silly_label" al modulo CFT di google-cloud-storage.

Assicurati di essere in terraform-google-cloud-storage e apri il file main.tf come mostrato di seguito nella struttura delle cartelle.

Da "silly_label" è un'etichetta, aggiungerai la caratteristica alla riga 27 nella variabile "labels" in main.tf, come mostrato sotto:

terraform-google-cloud-storage/main.tf

resource "google_storage_bucket" "buckets" {
 <...>
 storage_class = var.storage_class
 // CODELAB:Add silly label in labels variable
 labels        = merge(var.labels, { name = replace("${local.prefix}${lower(each.value)}", ".", "-") }, { "silly" = var.silly_label })
 force_destroy = lookup(
 <...>
}

Ora aggiungerai la variabile silly_label nel file variables.tf che vedi nella struttura di cartelle precedente.

Copia e incolla il codice riportato di seguito e aggiungilo alla riga 31 in variables.tf e assicurati di avere un nuovo carattere di riga sopra e sotto il blocco di variabili che aggiungi.

terraform-google-cloud-storage/variables.tf

variable "names" {
 description = "Bucket name suffixes."
 type        = list(string)
}

// CODELAB: Add "silly_label" variable to variables.tf between "names" and "location"
variable "silly_label" {
 description = "Sample label for bucket."
 type        = string
}

variable "location" {
 description = "Bucket location."
 default     = "EU"
}

6. Aggiungi una nuova caratteristica a un esempio di bucket di archiviazione

Hai aggiunto la tua caratteristica al file main.tf del modulo e ora testerai la caratteristica aggiunta attraverso un esempio.

"silly_label" dovrà essere aggiunto al file example/multiple-buckets/main.tf

Questo esempio verrà utilizzato nel passaggio successivo per eseguire i test di integrazione.

Copia e incolla la riga seguente della variabile silly_label nella riga 27 di main.tf su terraform-google-cloud-storage/examples/multiple-buckets/ come illustrato nella struttura delle cartelle:

terraform-google-cloud-storage/examples/multiple-buckets/main.tf

module "cloud_storage" {
 <...>
 // CODELAB: Add "silly_label" as an example to main.tf.
 silly_label        = "awesome"

 <..>
}

7. Aggiorna il test del progetto per verificare la funzionalità

Hai aggiunto la tua caratteristica al file main.tf del modulo e quindi l'hai aggiunta all'esempio di multiple_buckets. A questo punto, devi testare la tua caratteristica tramite un test di integrazione del progetto scritto in Golang.

Aggiungerai i nuovi test nel file multiple_buckets_test.go che si trova nella seguente struttura di cartelle:

Hai aggiunto "silly_label" su tutti i bucket creati tramite il modulo multiple_buckets e ora dovrai scrivere dei test per testare la nuova funzionalità.

Nel codice riportato di seguito, ottieni l'etichetta di ciascun bucket tramite il comando gcloud alpha storage, quindi controlli l'output restituito dal comando.

test/integration/multiple_buckets/multiple_buckets_test.go

func TestMultipleBuckets(t *testing.T) {
 <..>
op := gcloud.Run(t, fmt.Sprintf("alpha storage ls --buckets gs://%s", bucketName), gcloudArgs).Array()[0]

// verify silly label on each bucket
assert.Equal("awesome", op.Get("metadata.labels.silly").String(), "should have silly label set to awesome")

// verify lifecycle rules
...
}

8. Esegui test di integrazione in CFT

Test di integrazione

I test di integrazione vengono utilizzati per verificare il comportamento del modulo principale, dei sottomoduli e degli esempi. Aggiunte, modifiche e correzioni devono essere accompagnate da test.

I test di integrazione vengono scritti utilizzando il framework per il test del progetto ed eseguiti utilizzando l'interfaccia a riga di comando CFT. Questi strumenti vengono pacchettizzati all'interno di un'immagine Docker per praticità.

La strategia generale per questi test consiste nel verificare il comportamento dei moduli di esempio, garantendo così che il modulo principale, i sottomoduli e i moduli di esempio siano tutti funzionalmente corretti.

Nell'esecuzione interattiva, ogni passaggio viene eseguito tramite più comandi.

Esegui make docker_run per avviare il container Docker di test in modalità interattiva.

Make è uno strumento di automazione delle build che crea automaticamente librerie e programmi eseguibili dal codice sorgente leggendo file chiamati Makefiles che specificano come ricavare il programma di destinazione. Quando apporti modifiche al file, il contenitore Docker deve essere aggiornato automaticamente.

Quando esegui make docker_run, crei un'area di lavoro nel container Docker e attivi le credenziali per il tuo account di servizio. L'area di lavoro verrà utilizzata nei passaggi successivi per eseguire i test.

Nel terminale verrà visualizzato l'output seguente:

Activated service account credentials for: [cft@<PROJECT_ID>.iam.gserviceaccount.com]

Esegui cft test list per elencare tutti i test dei progetti nella tua area di lavoro.

Nel terminale verrà visualizzato l'output seguente:

[root@CONTAINER_ID workspace]# cft test list
 NAME                           | CONFIG                    | LOCATION                                                   
--------------------------------+---------------------------+------------------------------------------------------------
 TestAll/examples/simple_bucket | examples/simple_bucket    | test/integration/discover_test.go                          
 TestMultipleBuckets            | examples/multiple_buckets | test/integration/multiple_buckets/multiple_buckets_test.go

Esegui cft test run <EXAMPLE_NAME> --stage init per inizializzare l'esempio. In questo caso, per inizializzare l'esecuzione di test TestMultipleBuckets, cft test run TestMultipleBuckets --stage init. Puoi anche utilizzare il flag --verbose per ottenere maggiori informazioni quando esegui i test.

Questa fase di inizializzazione inizializza l'esempio di Terraform.

Vedrai l'output seguente nel tuo terminale.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage init --verbose
INFO[02-09|08:24:31] using test-dir: test/integration 
...
TestMultipleBuckets 2022-02-09T08:24:35Z command.go:179: Terraform has been successfully initialized!
...
TestMultipleBuckets 2022-02-09T08:24:35Z command.go:100: Running command terraform with args [validate]
TestMultipleBuckets 2022-02-09T08:24:36Z command.go:179: Success! The configuration is valid.
...
--- PASS: TestMultipleBuckets (4.05s)

Esegui cft test run <EXAMPLE_NAME> --stage apply per applicare il modulo di esempio.

Questo passaggio applica l'esempio inizializzato nella fase precedente al progetto Google Cloud creato in precedenza nel codelab.

Vedrai l'output seguente nel tuo terminale.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage apply --verbose
INFO[02-09|08:28:11] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: Apply complete! Resources: 6 added, 0 changed, 0 destroyed.
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: 
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: Outputs:
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: 
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: names = {
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179:   "one" = "multiple-buckets-erp1-eu-one"
...
--- PASS: TestMultipleBuckets (6.51s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    6.548s

Esegui cft test run <EXAMPLE_NAME> --stage verify per verificare che l'esempio abbia creato l'infrastruttura prevista.

Questo passaggio eseguirà la funzione di verifica in TestMultipleBuckets. In genere la verifica viene eseguita tramite l'esecuzione di un comando gcloud per recuperare l'output JSON per lo stato attuale di una risorsa e affermando che lo stato attuale è come dichiarato nell'esempio.

Se ricevi degli errori, vedrai ciò che ci aspettavi e cosa è stato ricevuto dal comando per il test.

Vedrai l'output seguente nel tuo terminale.

cft test run TestMultipleBuckets --stage verify --verbose
INFO[02-09|08:30:19] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:100: Running command terraform with args [output -no-color -json names_list]
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:179: ["multiple-buckets-erp1-eu-one","multiple-buckets-erp1-eu-two"]
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:100: Running command gcloud with args [alpha storage ls --buckets gs://multiple-buckets-erp1-eu-one --project ci-cloud-storage-8ce9 --json]
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179: [
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179: {
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179:   "url": "gs://multiple-buckets-erp1-eu-one/",
...
TestMultipleBuckets 2022-02-09T08:30:33Z command.go:179: ]
2022/02/09 08:30:33 RUN_STAGE env var set to verify
2022/02/09 08:30:33 Skipping stage teardown
--- PASS: TestMultipleBuckets (12.32s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    12.359s

Esegui cft test run <EXAMPLE_NAME> --stage teardown per eliminare l'esempio.

Questo passaggio elimina l'infrastruttura che hai creato nei passaggi precedenti. Questo passaggio distruggerà anche i bucket GCS creati nel progetto insieme all'etichetta che hai aggiunto al modulo GCS.

Puoi visualizzare l'output di seguito nel tuo terminale.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage teardown --verbose
INFO[02-09|08:36:02] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:36:06Z command.go:100: Running command terraform with args [destroy -auto-approve -input=false -lock=false]
TestMultipleBuckets 2022-02-09T08:36:07Z command.go:179: module.cloud_storage.random_id.bucket_suffix: Refreshing state... [id=mNA]
TestMultipleBuckets 2022-02-09T08:36:07Z command.go:179: random_string.prefix: Refreshing state... [id=erp1]
TestMultipleBuckets 2022-02-09T08:36:08Z command.go:179: module.cloud_storage.google_storage_bucket.buckets["two"]: Refreshing state... [id=multiple-buckets-erp1-eu-two]
...
TestMultipleBuckets 2022-02-09T08:36:10Z command.go:179: Destroy complete! Resources: 6 destroyed.
TestMultipleBuckets 2022-02-09T08:36:10Z command.go:179: 
--- PASS: TestMultipleBuckets (6.62s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    6.654s

Esegui exit per uscire dal container di test.

9. Generazione della documentazione per gli input e gli output

Le tabelle di input e output nei README del modulo principale, dei sottomoduli e dei moduli di esempio vengono generate automaticamente in base ai valori variables e outputs dei rispettivi moduli. Queste tabelle devono essere aggiornate se le interfacce del modulo vengono modificate.

Esegui:

make generate_docs
# This will generate new Inputs and Outputs tables

10. Esegui test lint in CFT

Un linter è uno strumento che analizza il codice sorgente per segnalare errori di programmazione, bug, errori stilistici e costrutti sospetti.

Molti dei file nel repository possono essere sottoposti a lint o formattati per mantenere uno standard di qualità. Per garantire la qualità in CFT, utilizzerai un test lint.

Esegui:

make docker_test_lint
# This will run all lint tests on your repo

11. Invio di un PR su GitHub

Ora che hai modificato il codice localmente e testato tramite i test di integrazione, vuoi pubblicare il codice nel repository principale.

Per rendere disponibile il codice nel repository master, dovrai eseguire il commit delle modifiche al codice nel ramo ed eseguirne il push nel repository master. Per aggiungere il codice al repository principale che hai creato con fork all'inizio del codelab, devi inviare una richiesta di pull (PR) al repository master dopo aver eseguito il commit del codice nel repository.

Quando presenti un PR, l'amministratore del repository viene informato di esaminare le modifiche al codice proposte. Inoltre, puoi aggiungere altri utenti come revisori per ricevere feedback sulle modifiche apportate al codice. Il PR attiverà Cloud Build che eseguirà test sul repository.

In base alle modifiche apportate al codice, i revisori del codice ti forniranno commenti e ti chiederanno se sia necessario apportare modifiche in base alle best practice e alla documentazione. L'amministratore esaminerà le tue modifiche al codice, si assicurerà che il codice sia conforme al repository e potrebbe chiederti nuovamente di apportare alcune modifiche prima di unire il codice nel repository principale.

Esegui questi passaggi per eseguire il commit del codice nel ramo creato con fork ed eseguire il push del codice al ramo creato con fork:

Il primo passaggio consiste nell'aggiungere i file modificati al repository locale.

$ git add main.tf
$ git add README.md
$ git add variables.tf
$ git add examples/multiple-buckets/main.tf
$ git add test/integration/multiple_buckets/multiple_buckets_test.go
# The ‘git add' command adds the file in the local repository and 
# stages the file for commit. To unstage a file, use git reset HEAD YOUR-FILE

I file sono ora in fase temporanea. Successivamente, eseguirai il commit delle modifiche.

$ git commit -m "First CFT commit"
# This will commit the staged changes and prepares them to be pushed 
# to a remote repository. To remove this commit and modify the file, 
# use 'git reset --soft HEAD~1' and commit and add the file again.

Esegui il push delle modifiche sottoposte a commit nel tuo repository locale in GitHub per la creazione di una richiesta di pull (PR).

$ git push -u origin feature/silly_label
# Pushes the changes in your local repository up to the remote
# repository you specified as the origin

Le modifiche al codice sono pronte per una richiesta di pull.

Esegui questi passaggi per creare un PR per il repository terraform-google-modules/terraform-google-cloud-storage :

Nel browser web, vai alla pagina principale del repository.
Vedrai un suggerimento tramite un banner per aprire un PR dalla tua fork. Fai clic su "Richiesta di confronto e pull".

Inserisci un titolo e una descrizione per la richiesta di pull in modo da descrivere le modifiche al codice. Sii il più specifico possibile, ma conciso.

Per creare una richiesta di pull pronta per la revisione, fai clic su "Crea richiesta di pull".
Vedrai in esecuzione i trigger di Cloud Build, che vengono attivati a causa del PR.
In caso di problemi, consulta la documentazione ufficiale di GitHub sull'apertura delle richieste di pull dai fork.

Hai eseguito correttamente il push della prima modifica del codice al ramo creato con fork e hai aumentato la tua prima PR CFT rispetto al ramo master.

12. Complimenti

Congratulazioni. Hai aggiunto correttamente una funzionalità a un modulo CFT e inviato un PR per la revisione.

Hai aggiunto una funzionalità a un modulo CFT, l'hai testata localmente tramite un esempio ed eseguito test prima di eseguire il commit del codice su GitHub. Infine, hai inviato un PR per la revisione e l'unione finale nel CFT.

Ora conosci i passaggi importanti per iniziare a utilizzare Cloud Foundation Toolkit.