Esta página foi traduzida pela API Cloud Translation.

Introdução ao Cloud Foundation Toolkit

1. Introdução ao CFT 101

Última atualização:11/02/2022

O que é o Cloud Foundation Toolkit?

Em essência, o CFT oferece modelos de práticas recomendadas para começar a usar rapidamente o Google Cloud Platform. Neste tutorial, você vai aprender a contribuir para o Cloud Foundation Toolkit.

O que é necessário

Uma conta do GitHub.
O Docker instalado na sua máquina ou o Cloud Shell ( instalação no Mac, instalação no Windows)
Editor de código para edição de código (exemplo: Visual Studio Code)
Ter noções básicas sobre o Git e o GitHub
Alguma experiência com o Terraform e a infraestrutura como código
Permissão para conceder o papel de criador de projetos a uma conta de serviço
Uma organização do Google Cloud, uma pasta de teste e uma conta de faturamento

O que você vai criar

Neste codelab, você vai aprender a contribuir com o Cloud Foundation Toolkit (CFT).

Você vai:

Configurar um ambiente de desenvolvimento para contribuir com o CFT
Adicionar um recurso a um módulo CFT
Adicionar testes para o recurso incluído
Executar testes de integração no CFT
Executar testes de lint
Fazer commit do código no GitHub e enviar uma solicitação de envio (PR)

Você vai executar todas as etapas acima adicionando um novo recurso ao módulo CFT do Google Cloud Storage. Você vai adicionar um rótulo chamado "silly_label", que será adicionado automaticamente a todos os buckets criados pelo módulo CFT do GCS. Você também vai escrever testes para validar seu recurso e garantir a integração de ponta a ponta.

2. Configurar o ambiente de desenvolvimento

Se quiser, use o Cloud Shell para fins de desenvolvimento. Se você não quiser usar o Cloud Shell para contribuir com o CFT, configure seu ambiente de desenvolvimento na sua máquina.

Configurar o Git

O GitHub é baseado em um sistema de controle de versões (VCS, na sigla em inglês) de código aberto chamado Git. O Git é responsável por tudo relacionado ao GitHub que acontece localmente na sua máquina ou no Cloud Shell.

Ao usar o Cloud Shell, não é necessário instalar o git, porque ele já vem pré-instalado.

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

Se você estiver configurando o ambiente de desenvolvimento na sua máquina, instale o Git.

Definir seu nome de usuário e e-mail no Git

O Git usa um nome de usuário para associar commits a uma identidade. O nome de usuário do Git não é o mesmo que o nome de usuário do GitHub.

É possível mudar o nome associado aos commits do Git usando o comando git config. Mudar o nome associado aos commits do Git usando git config só afeta os commits futuros e não muda o nome usado nos commits anteriores.

Você configurou o Git e pode fazer fork, criar e clonar ramificações. Vamos usar o Git extensivamente neste codelab.

3. Bifurcar o repositório do GCS do CFT

Bifurcar um repositório da CFT

Você configurou o Git na sua máquina local ou no Cloud Shell na etapa anterior. Agora, bifurque o repositório do CFT do Google Cloud Storage para começar a contribuir.

Um fork é uma cópia de um repositório. Ao fazer um fork de um repositório, você pode testar mudanças livremente sem afetar o projeto original.

Normalmente, os forks são usados para propor mudanças no projeto de outra pessoa ou para usar o projeto de outra pessoa como ponto de partida para sua própria ideia.

Por exemplo, é possível usar forks para propor mudanças relacionadas à correção de um bug. Para corrigir um bug, você pode:

Bifurque o repositório.
Faça a correção.
Envie uma solicitação de extração ao proprietário do projeto.

Etapas para fazer um fork de um repositório do CFT:

Abra seu navegador da Web e acesse o repositório terraform-google-modules/terraform-google-cloud-storage. Vamos usar esse repositório em todo o codelab.
No canto superior direito da página, clique em Bifurcar.

Você vai receber uma opção de onde quer fazer o fork. Escolha seu perfil, e o repositório será bifurcado.

Clonar sua bifurcação localmente

O fork que você criou é uma cópia do repositório do módulo do GCS. Agora, clone esse repositório no seu ambiente local para adicionar o novo recurso.

Etapas para clonar sua ramificação:

Abra seu navegador da Web e acesse o fork em terraform-google-modules/terraform-google-cloud-storage.
No canto superior direito, clique no botão "Code".

Depois de clicar no botão "Código", clique no ícone "Copiar" para copiar o URL do fork. Você vai usar esse URL para clonar sua bifurcação no ambiente local.

Acesse um terminal no VSCode ou na sua máquina e clone o fork.

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

Agora que você clonou seu fork localmente, acesse o repositório, crie uma ramificação do fork e faça mudanças no código da ramificação temporária.

Por convenção, você pode nomear sua ramificação da seguinte maneira:

Para pedidos de recursos: feature/feature-name
Para atualizações internas, internal/change-name
Para correções de bugs: bugfix/issue-name

Como você está adicionando um novo recurso, pode chamar sua ramificação temporária de 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"

Agora está tudo pronto para começar a trabalhar com o Cloud Foundation Toolkit.

4. Criar um ambiente de teste

O processo padrão de desenvolvimento do CFT se baseia no uso de um projeto de teste isolado. Esta etapa vai orientar você na criação do projeto de teste (com base em uma configuração padrão) usando uma conta de serviço.

0. Instalar o Docker Engine

Se você estiver usando a máquina para fins de desenvolvimento, instale o Docker Engine.

1. Instalar o SDK do Google Cloud

Não é necessário instalar o SDK do Google Cloud se você estiver usando o Cloud Shell do GCP.

Acesse SDK do Google Cloud e faça o download do instalador interativo para sua plataforma.

2. Definir configuração

Para criar um ambiente de teste, você precisa de uma organização do Google Cloud, uma pasta de teste e uma conta de faturamento. Esses valores precisam ser definidos por variáveis de 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. Configurar sua conta de serviço

Antes de criar um ambiente de teste, faça o download de uma chave de conta de serviço para ele. Essa conta de serviço vai precisar dos papéis Criador de projetos, Usuário da conta de faturamento e Leitor da organização. Estas etapas ajudam a criar uma conta de serviço, mas também é possível reutilizar uma conta existente.

3.1 Criar ou selecionar um projeto do GCP de seed

Antes de criar sua conta de serviço, selecione um projeto para hospedá-la. Também é possível criar um novo projeto.

gcloud config set core/project YOUR_PROJECT_ID

3.2 Ativar as APIs do Google Cloud

Ative as seguintes APIs do Google Cloud no projeto de inicialização:

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

3.3 Criar uma conta de serviço

Crie uma conta de serviço para gerenciar o ambiente de teste:

# 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

Verifique se a conta de serviço foi criada:

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

3.4 Conceda os papéis de criador de projeto, usuário da conta de faturamento e leitor da organização à conta de serviço:

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"

Agora você tem uma conta de serviço que pode ser usada para gerenciar o ambiente de teste.

4. Preparar credencial do Terraform

Para criar o ambiente de teste, faça o download da chave da conta de serviço no shell.

4.1 Chave da conta de serviço

Criar e fazer o download de uma chave de conta de serviço para o Terraform

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

4.2 Configurar credencial do Terraform

Forneça a chave ao Terraform usando a variável de ambiente SERVICE_ACCOUNT_JSON, definindo o valor como o conteúdo da chave da conta de serviço.

export SERVICE_ACCOUNT_JSON=$(< cft.json)

Depois de armazenar as informações de credenciais na variável de ambiente, remova o arquivo de chave. É possível recriar uma chave mais tarde, se necessário, usando o mesmo comando acima.

rm -rf cft.json

5. Criar um projeto de teste para implantações do Terraform

Agora que tudo está preparado, é possível criar o projeto de teste com um único comando. Execute este comando na raiz do diretório terraform-google-cloud-storage:

make docker_test_prepare

Você vai ver a saída abaixo ao executar make docker_test_prepare. No final, você vai receber o project_id do projeto de teste criado, em que vai implantar e testar o módulo do Cloud Storage com seu novo recurso. Se você tiver problemas para vincular uma conta de faturamento, consulte as etapas de solução de problemas.

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.

Você criou um projeto de teste referenciado por project_id, como é possível ver na saída do console. Seu ambiente de desenvolvimento e teste está configurado.

5. Adicionar um novo recurso ao módulo CFT

Agora que seu ambiente de desenvolvimento e teste está configurado, vamos começar a adicionar o recurso "silly_label" ao módulo CFT google-cloud-storage.

Verifique se você está em terraform-google-cloud-storage e abra o arquivo main.tf, como mostrado abaixo na estrutura de pastas.

Como "silly_label" é um rótulo, adicione o recurso na linha 27 na variável "labels" em main.tf, conforme mostrado abaixo:

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(
 <...>
}

Agora, adicione a variável silly_label no arquivo variables.tf que aparece na estrutura de pastas acima.

Copie e cole o código abaixo e adicione-o à linha 31 em variables.tf. Verifique se há um caractere de nova linha acima e abaixo do bloco de variáveis adicionado.

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. Adicionar um novo recurso ao exemplo de bucket de armazenamento

Você adicionou o recurso ao main.tf do módulo e agora vai testá-lo com um exemplo.

O "silly_label" precisa ser adicionado a examples/multiple-buckets/main.tf

Este exemplo será usado na próxima etapa para realizar testes de integração.

Copie e cole a linha da variável silly_label abaixo na linha 27 em main.tf em terraform-google-cloud-storage/examples/multiple-buckets/, conforme mostrado na estrutura de pastas:

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. Atualizar o teste de blueprint para verificar o recurso

Você adicionou o recurso ao main.tf do módulo e, em seguida, ao exemplo multiple_buckets. Agora, você precisa testar o recurso com um teste de integração de blueprint escrito em Go.

Você vai adicionar seus novos testes no arquivo multiple_buckets_test.go, que está na estrutura de pastas abaixo:

Você adicionou o "silly_label" a todos os agrupamentos criados pelo módulo "multiple_buckets" e agora precisa escrever testes para testar o novo recurso.

No código abaixo, você recebe o rótulo de cada bucket usando o comando gcloud alpha storage e verifica a saída retornada.

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. Executar testes de integração no CFT

Testes de integração

Os testes de integração são usados para verificar o comportamento do módulo raiz, dos submódulos e dos exemplos. As adições, mudanças e correções precisam ser acompanhadas de testes.

Os testes de integração são escritos usando o framework de teste de blueprint e executados com a CLI do CFT. Essas ferramentas são empacotadas em uma imagem do Docker para facilitar o uso.

A estratégia geral para esses testes é verificar o comportamento dos módulos de exemplo, garantindo que o módulo raiz, os submódulos e os módulos de exemplo estejam todos funcionalmente corretos.

Na execução interativa, você executa cada etapa com vários comandos.

Execute make docker_run para iniciar o contêiner do Docker de teste no modo interativo.

O Make é uma ferramenta de automação de build que cria automaticamente programas executáveis e bibliotecas com base no código-fonte. Para isso, ele lê arquivos chamados Makefiles, que especificam como derivar o programa de destino. Quando você faz mudanças no arquivo, o contêiner do Docker precisa ser atualizado automaticamente.

Ao executar make docker_run, você cria um espaço de trabalho no contêiner do Docker e ativa as credenciais da sua conta de serviço. O espaço de trabalho será usado nas próximas etapas para executar testes.

A saída abaixo vai aparecer no terminal:

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

Execute module-swapper -registry-prefix=terraform-google-modules para ajustar os arquivos de exemplo main.tf e importar os módulos dos arquivos locais em vez dos publicados.

O resultado no terminal será semelhante a este:

[root@<CONTAINER_ID> workspace]# module-swapper -registry-prefix=terraform-google-modules
2025/08/04 19:26:29 Module name set from remote to cloud-storage
2025/08/04 19:26:29 Modifications made to file /workspace/examples/multiple_buckets/main.tf
2025/08/04 19:26:29 --- Original
+++ Modified
@@ -21,7 +21,7 @@
 }
 
 module "cloud_storage" {
-  source = "terraform-google-modules/cloud-storage/google"
+  source = "../.."
   # [restore-marker]   version = "~> 10.0"
 
   project_id = var.project_id

Execute cft test list para listar todos os testes de blueprints no seu espaço de trabalho.

A saída abaixo vai aparecer no terminal:

[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

Execute cft test run <EXAMPLE_NAME> --stage init para inicializar o exemplo. Nesse caso, para inicializar a execução do teste TestMultipleBuckets, cft test run TestMultipleBuckets --stage init. Você também pode usar a flag --verbose para receber mais informações ao executar testes.

Essa etapa inicializa o exemplo do Terraform.

A saída abaixo vai aparecer no terminal.

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

Execute cft test run <EXAMPLE_NAME> --stage apply para aplicar o módulo de exemplo.

Esta etapa aplica o exemplo inicializado na etapa anterior ao projeto do GCP criado anteriormente no codelab.

A saída abaixo vai aparecer no terminal.

[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

Execute cft test run <EXAMPLE_NAME> --stage verify para verificar se o exemplo criou a infraestrutura esperada.

Essa etapa vai executar a função de verificação em TestMultipleBuckets. Normalmente, a verificação é feita executando um comando gcloud para recuperar a saída JSON do estado atual de um recurso e confirmando que o estado atual é o declarado no exemplo.

Se você receber erros, vai ver o que era esperado e o que foi recebido pelo comando para o teste.

A saída abaixo vai aparecer no terminal.

[root@<CONTAINER_ID> workspace]# 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

Execute cft test run <EXAMPLE_NAME> --stage teardown para encerrar o exemplo.

Esta etapa destrói a infraestrutura criada nas etapas acima. Essa etapa também vai destruir os buckets do GCS criados no projeto, além do rótulo adicionado ao módulo do GCS.

Você pode conferir a saída abaixo no terminal.

[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

Execute module-swapper -registry-prefix=terraform-google-modules -restore para desfazer os ajustes nos arquivos de exemplo main.tf da última vez que você executou module-swapper.

[root@<CONTAINER_ID> workspace]# module-swapper -registry-prefix=terraform-google-modules -restore
2025/08/04 19:30:41 Module name set from remote to cloud-storage
2025/08/04 19:36:32 Modifications made to file /workspace/examples/multiple_buckets/main.tf
2025/08/04 19:36:32 --- Original
+++ Modified
@@ -21,8 +21,8 @@
 }
 
 module "cloud_storage" {
-  source = "../.."
-   version = "~> 10.0"
+  source  = "terraform-google-modules/cloud-storage/google"
+  version = "~> 10.0"
 
   project_id = var.project_id

Execute exit para sair do contêiner de teste.

9. Gerar documentação para entradas e saídas

As tabelas "Entradas" e "Saídas" nos arquivos README do módulo raiz, dos submódulos e dos módulos de exemplo são geradas automaticamente com base em variables e outputs dos respectivos módulos. Essas tabelas precisam ser atualizadas se as interfaces do módulo forem alteradas.

Execute:

make generate_docs
# This will generate new Inputs and Outputs tables

10. Executar testes de lint em CFT

Um linter é uma ferramenta que analisa o código-fonte para sinalizar erros de programação, bugs, erros de estilo e construções suspeitas.

Muitos dos arquivos no repositório podem ser verificados ou formatados para manter um padrão de qualidade. Para garantir a qualidade no CFT, você vai usar um teste de lint.

Execute:

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

11. Como enviar uma solicitação de envio no GitHub

Agora que você mudou o código localmente e o testou com os testes de integração, publique esse código no repositório principal.

Para disponibilizar seu código no repositório principal, confirme as mudanças de código na sua ramificação e envie para o repositório principal. Para que seu código seja adicionado ao repositório principal que você bifurcou no início do codelab, crie uma solicitação de pull (PR) no repositório principal depois de confirmar o código no seu repositório.

Quando você cria uma solicitação de pull, o administrador do repositório recebe uma notificação para revisar as mudanças de código propostas. Além disso, você pode adicionar outros usuários como revisores para receber feedback sobre as mudanças no código. O PR vai acionar um Cloud Build que vai executar testes no repositório.

Com base nas mudanças no código, os revisores vão fornecer comentários e pedir modificações se algo precisar ser alterado de acordo com as práticas recomendadas e a documentação. O administrador vai revisar as mudanças no código, garantir que ele esteja em conformidade com o repositório e talvez pedir que você faça algumas mudanças antes de mesclar o código ao repositório principal.

Siga estas etapas para confirmar e enviar o código para o branch bifurcado:

A primeira etapa é adicionar os arquivos alterados ao repositório local.

$ 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

Seus arquivos estão agora em estado de preparo. Em seguida, você vai confirmar as mudanças.

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

Envie as mudanças confirmadas no seu repositório local para o GitHub e crie uma solicitação de envio (PR, na sigla em inglês).

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

Suas mudanças de código estão prontas para uma solicitação de envio.

Execute as etapas a seguir para criar uma solicitação de envio (PR, na sigla em inglês) para o repositório terraform-google-modules/terraform-google-cloud-storage :

No navegador da Web, acesse a página principal do repo.
Você vai receber uma sugestão por banner para abrir uma solicitação de pull do seu fork. Clique em "Comparar e enviar solicitação".

Insira um título e uma descrição para a solicitação de envio e descreva as mudanças no código. Seja o mais específico possível, mas sem perder a concisão.

Para criar uma solicitação de envio pronta para análise, clique em "Criar solicitação de envio".
Você verá os gatilhos do Cloud Build em execução, que são acionados devido ao PR.
Consulte a documentação oficial do GitHub sobre como abrir solicitações de envio de forks (em inglês) se encontrar algum problema.

Você enviou sua primeira mudança de código para a ramificação bifurcada e criou seu primeiro PR do CFT na ramificação principal.

12. Parabéns

Parabéns! Você adicionou um recurso a um módulo do CFT e enviou uma solicitação de pull para revisão.

Você adicionou um recurso a um módulo do CFT, testou localmente usando um exemplo e realizou testes antes de fazer commit do código no GitHub. Por fim, você criou uma solicitação de pull para revisão e mesclagem final no CFT.

Agora você conhece as etapas importantes para começar a usar o Cloud Foundation Toolkit.

Introdução ao Cloud Foundation Toolkit Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

1. Introdução ao CFT 101

O que é o Cloud Foundation Toolkit?

O que é necessário

O que você vai criar

2. Configurar o ambiente de desenvolvimento

Configurar o Git

Definir seu nome de usuário e e-mail no Git

3. Bifurcar o repositório do GCS do CFT

Bifurcar um repositório da CFT

Clonar sua bifurcação localmente

Agora está tudo pronto para começar a trabalhar com o Cloud Foundation Toolkit.

4. Criar um ambiente de teste

0. Instalar o Docker Engine

1. Instalar o SDK do Google Cloud

2. Definir configuração

3. Configurar sua conta de serviço

4. Preparar credencial do Terraform

5. Criar um projeto de teste para implantações do Terraform

5. Adicionar um novo recurso ao módulo CFT

terraform-google-cloud-storage/main.tf

terraform-google-cloud-storage/variables.tf

6. Adicionar um novo recurso ao exemplo de bucket de armazenamento

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

7. Atualizar o teste de blueprint para verificar o recurso

test/integration/multiple_buckets/multiple_buckets_test.go

8. Executar testes de integração no CFT

Testes de integração

9. Gerar documentação para entradas e saídas

10. Executar testes de lint em CFT

11. Como enviar uma solicitação de envio no GitHub

12. Parabéns

Introdução ao Cloud Foundation Toolkit