Questa pagina è stata tradotta dall'API Cloud Translation.

Guida introduttiva al toolkit di Cloud Foundation

1. Introduzione a CFT 101

Ultimo aggiornamento: 11/02/2022

Che 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 a 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 (esempio: Visual Studio Code)
Familiarità di base con Git e GitHub
Esperienza con Terraform e 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 a contribuire a Cloud Foundation Toolkit (CFT).

Imparerai a:

Configurare un ambiente di sviluppo per contribuire a CFT
Aggiungere una funzionalità a un modulo CFT
Aggiungi i test per la funzionalità aggiunta
Esegui i test di integrazione in CFT
Esegui test di 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. Aggiungerai un'etichetta denominata "silly_label" che verrà aggiunta automaticamente a tutti i bucket creati tramite il modulo CFT di GCS. Avrai anche la possibilità di scrivere test per convalidare la funzionalità e garantire l'integrazione end-to-end.

2. Configura l'ambiente di sviluppo

Se vuoi, puoi utilizzare Cloud Shell per le tue finalità di sviluppo. Se non vuoi utilizzare Cloud Shell per contribuire a CFT, puoi configurare il tuo ambiente di sviluppo sulla tua macchina.

Configurare Git

GitHub si basa su un sistema di controllo della versione (VCS) open source chiamato Git. Git è responsabile di tutto ciò che riguarda GitHub e che avviene localmente sulla tua macchina o in 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 l'ambiente di sviluppo sulla tua macchina, devi installare Git.

Impostare il nome utente e l'email in Git

Git utilizza un nome utente per associare i commit a un'identità. Il nome utente Git non corrisponde al tuo 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 passati.

Hai configurato Git correttamente e dovresti essere in grado di eseguire il fork, creare e clonare i branch. Useremo molto Git in questo Codelab.

3. Crea un fork del repository GCS di CFT

Eseguire il fork di un repository CFT

Hai configurato Git sulla tua macchina locale o su Cloud Shell nel passaggio precedente. Ora devi creare un 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.

Molto spesso, i fork vengono utilizzati per proporre modifiche al progetto di qualcun altro o per utilizzare il progetto di qualcun altro 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 pull al proprietario del progetto.

Passaggi per eseguire 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.

Ti verrà presentata un'opzione per scegliere dove vuoi eseguire il fork, scegli il tuo profilo e il repository verrà sottoposto a fork.

Clonare la fork in locale

Il fork che hai creato è una copia del repository del modulo GCS. Ora dovrai clonare questo repository nel tuo ambiente locale per aggiungere la nuova funzionalità.

Passaggi per clonare il fork:

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

Dopo aver fatto clic sul pulsante "Codice", fai clic sull'icona "Copia" per copiare l'URL del fork. Utilizzerai questo URL per clonare il 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 localmente, devi accedere al tuo repository, creare un nuovo ramo dal fork e apportare modifiche al codice al ramo temporaneo.

Per convenzione, puoi assegnare al ramo il nome seguente:

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

Poiché stai aggiungendo una nuova funzionalità, puoi chiamare il ramo temporaneo 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 (in base a una configurazione standard) tramite un account di servizio.

0. Installa Docker Engine

Se utilizzi la tua macchina per scopi 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 disporre di 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. Configurare 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 Creatore 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 l'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 progetto seed:

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 all'account di servizio i ruoli Autore progetto, Utente account di fatturazione e Visualizzatore organizzazione:

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 puoi utilizzare 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 account di servizio

Creare e scaricare 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 memorizzato le informazioni sulle credenziali nella variabile di ambiente, rimuovi il file key. Se necessario, puoi ricreare una chiave in un secondo momento utilizzando lo stesso comando riportato sopra.

rm -rf cft.json

5. Creare un progetto di test per i deployment di Terraform

Ora che è tutto pronto, puoi creare il progetto di test con un singolo comando. Esegui questo comando dalla directory principale 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.

Ora hai creato un progetto di test a cui viene fatto riferimento tramite project_id, come puoi vedere nell'output della console. L'ambiente di sviluppo e test è configurato.

5. Aggiungere una nuova funzionalità al modulo CFT

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

Assicurati di trovarti in terraform-google-cloud-storage e apri il file main.tf come mostrato di seguito nella struttura della cartella.

Poiché "silly_label" è un'etichetta, dovrai aggiungere la funzionalità nella riga 27 della variabile "labels" in main.tf, come mostrato di seguito:

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 aggiungi la variabile silly_label in variables.tf, che vedi nella struttura della cartella sopra.

Copia e incolla il codice seguente e aggiungilo alla riga 31 in variables.tf e assicurati di avere un carattere di nuova 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. Aggiungere una nuova funzionalità all'esempio di bucket di archiviazione

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

L'etichetta "silly_label" dovrà essere aggiunta a examples/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 funzionalità al file main.tf del modulo e poi all'esempio multiple_buckets. Ora devi testare la funzionalità tramite un test di integrazione del blueprint 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" a tutti i bucket creati tramite il modulo multiple_buckets e ora devi scrivere i test per testare la nuova funzionalità.

Nel codice seguente, ottieni l'etichetta di ogni bucket tramite il comando gcloud alpha storage e poi 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. Le aggiunte, le modifiche e le 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. Per praticità, questi strumenti sono pacchettizzati in un'immagine Docker.

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, esegui ogni passaggio tramite più comandi.

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

Make è uno strumento di automazione della compilazione che compila automaticamente programmi ed eseguibili e librerie dal codice sorgente leggendo file chiamati makefile che specificano come ricavare il programma di destinazione. Quando apporti modifiche ai file, il contenitore Docker deve essere aggiornato automaticamente.

Quando esegui make docker_run, crei uno spazio di lavoro nel contenitore Docker e attivi le credenziali per il tuo account di servizio. Lo spazio di lavoro verrà utilizzato 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 blueprint nella tua area di lavoro.

Nel terminale vedrai 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 ulteriori informazioni durante l'esecuzione dei test.

Questa fase di inizializzazione inizializza l'esempio Terraform.

Nel terminale vedrai l'output riportato di seguito.

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

In questo passaggio verrà eseguita la funzione di verifica in TestMultipleBuckets. In genere, la verifica viene eseguita tramite l'esecuzione di un comando gcloud per recuperare l'output JSON relativo allo stato corrente di una risorsa e verificare che lo stato corrente sia quello dichiarato nell'esempio.

Se ricevi errori, vedrai ciò che era previsto e ciò che è stato ricevuto dal comando per il test.

Nel terminale vedrai l'output riportato di seguito.

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 eseguire il teardown dell'esempio.

Questo passaggio elimina l'infrastruttura creata nei passaggi precedenti. Questo passaggio distruggerà anche i bucket GCS creati nel progetto, insieme all'etichetta aggiunta al modulo GCS.

Puoi visualizzare l'output riportato di seguito nel 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 contenitore di test.

9. Generazione della documentazione per input e 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 linting 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 una richiesta di pull 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. Affinché il codice venga aggiunto al repository principale che hai creato all'inizio del Codelab, dovrai inviare una richiesta pull (PR) al repository principale dopo aver eseguito il commit del codice nel tuo repository.

Quando invii una PR, l'amministratore del repository riceve una notifica per 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 forniranno commenti sul codice e chiederanno modifiche se è necessario apportare modifiche in base alle best practice e alla documentazione. L'amministratore esaminerà le tue modifiche al codice, si assicura che il codice sia conforme al repository e potrebbe chiederti nuovamente di apportare alcune modifiche prima di unire il codice al repository principale.

Esegui i seguenti passaggi per eseguire il commit del codice nel ramo derivato ed eseguirlo nel ramo derivato:

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 ora pronte per una richiesta 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 repo.
Vedrai un suggerimento tramite banner per aprire una PR dal tuo 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 su come aprire 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.