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 fornece modelos de práticas recomendadas para começar a usar rapidamente o Google Cloud Platform. Neste tutorial, você vai aprender a contribuir com o Cloud Foundation Toolkit.

O que é necessário

Uma conta do GitHub.
Docker instalado na sua máquina ou use o Cloud Shell ( instalação no Mac, instalação no Windowsl).
Editor de código para edição de código (exemplo: Visual Studio Code)
Noções básicas de Git e GitHub
Alguma experiência com o Terraform e a infraestrutura como código
Permissão para conceder a função de criador de projeto 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 a CFT
Adicionar um recurso a um módulo de CFT
Adicionar testes para o recurso adicionado
Executar testes de integração no CFT
Executar testes de lint
Confirmar o 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 identificador chamado "silly_label", que será adicionado automaticamente a todos os buckets criados pelo módulo CFT do GCS. Você também vai criar testes para validar seu recurso e garantir a integração completa.

2. Configurar o ambiente de desenvolvimento

Se quiser, você pode usar o Cloud Shell para fins de desenvolvimento. Se você não quiser usar o Cloud Shell para contribuir com a CFT, configure seu ambiente de desenvolvimento na 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, você não precisa instalar o git, porque ele 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, será necessário instalar o Git.

Como definir seu nome de usuário e e-mail no Git

O Git usa um nome de usuário para associar confirmações 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 seus commits do Git usando o comando git config. A alteração do nome associado às confirmações do Git usando o git config só afetará as confirmações futuras e não o nome usado para as confirmações anteriores.

Você configurou o Git e poderá bifurcar, criar e clonar ramificações. Vamos usar o Git extensivamente neste codelab.

3. Fork CFT do repositório do GCS

Ramificar um repositório do CFT

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

Uma bifurcação é uma cópia de um repositório. Com a bifurcação de um repositório, você pode testar livremente as mudanças sem afetar o projeto original.

Geralmente, as bifurcações são usadas para propor mudanças no projeto de outra pessoa ou usar o projeto dela como ponto de partida para a própria ideia.

Por exemplo, você pode usar bifurcações para propor mudanças relacionadas à correção de um bug. Para corrigir um bug, você pode fazer o seguinte:

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

Etapas para bifurcar um repositório do CFT:

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

Você vai ter a opção de onde quer fazer a bifurcação. Escolha seu perfil e o repositório será bifurcado.

Clonar sua bifurcação localmente

A bifurcação criada é uma cópia do repositório do módulo do GCS. Agora você vai clonar esse repositório no seu ambiente local para adicionar o novo recurso.

Etapas para clonar sua ramificação:

Abra o navegador da Web e navegue até o fork em terraform-google-modules/terraform-google-cloud-storage.
No canto superior direito, clique no botão "Código".

Depois de clicar no botão "Code", clique no ícone "Copy" para copiar o URL do fork. Você vai usar esse URL para clonar a bifurcação no seu ambiente local.

Acesse um terminal no VSCode ou na sua máquina e clone a bifurcação.

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

Agora que você clonou sua bifurcação localmente, acesse seu repositório, crie uma nova ramificação e faça alterações de código nela.

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

Para solicitações 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 a 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"

Você já pode começar a trabalhar no Cloud Foundation Toolkit.

4. Criar um ambiente de teste

O processo de desenvolvimento padrão de CFT é baseado no uso de um projeto de teste isolado para testes. 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 o 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ê vai precisar de uma organização do Google Cloud, uma pasta de teste e uma conta de faturamento. Estes valores precisam ser definidos usando 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, você precisa fazer o download de uma chave da conta de serviço para ele. Essa conta de serviço precisa ter os papéis de Criador de projetos, usuário da conta de faturamento e Leitor da organização. Estas etapas ajudam a criar uma nova conta de serviço, mas você também pode reutilizar uma conta existente.

3.1 Criar ou selecionar um projeto inicial do GCP

Antes de criar a conta de serviço, você precisa selecionar um projeto para hospedá-la. Você também pode 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 seu projeto de semente:

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 nova 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 Conceder 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 a credencial do Terraform

Para criar o ambiente de teste, você precisa fazer 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 a credencial do Terraform

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

export SERVICE_ACCOUNT_JSON=$(< cft.json)

Depois de armazenar as informações de credencial na variável de ambiente, remova o arquivo-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 está tudo pronto, você pode criar o projeto de teste com um único comando. Execute este comando a partir da raiz do diretório terraform-google-cloud-storage:

make docker_test_prepare

Você vai ver a saída abaixo quando executar make docker_test_prepare. No final, vai receber o ID do projeto de teste criado, em que você vai implantar e testar o módulo do Cloud Storage com o 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 mostra a saída do console. O 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.

Você precisa estar no terraform-google-cloud-storage e abrir 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 variables.tf que aparece na estrutura de pastas acima.

Copie e cole o código abaixo na linha 31 em variables.tf e verifique se há um novo caractere de 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 testar o recurso adicionado usando um exemplo.

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

Esse 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 depois ao exemplo de multiple_buckets. Agora você precisa testar seu recurso com um teste de integração de blueprints escrito em Golang.

Você vai adicionar os novos testes no arquivo multiple_buckets_test.go encontrado na estrutura de pastas abaixo:

Você adicionou o "silly_label" a todos os buckets 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 pelo comando gcloud alpha storage e verifica a saída retornada pelo 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. Executar testes de integração no CFT

Teste 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 modelo e executados usando a CLI do CFT. Para sua conveniência, essas ferramentas são empacotadas em uma imagem do Docker.

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

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

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

O Make é uma ferramenta de automação de build que cria automaticamente programas e bibliotecas executáveis a partir do código-fonte lendo arquivos chamados Makefiles, que especificam como derivar o programa de destino. Quando você faz alterações em um arquivo, o contêiner do Docker precisa ser atualizado automaticamente.

Quando você executa make docker_run, cria um espaço de trabalho no contêiner do Docker e ativa as credenciais da 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 cft test list para listar todos os testes de modelos 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 de 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 resposta abaixo vai aparecer no seu 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 resposta abaixo vai aparecer no seu 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.

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

Se houver erros, você vai saber o que era esperado e o que foi recebido pelo comando do teste.

A resposta abaixo vai aparecer no seu terminal.

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 desmontar o exemplo.

Esta etapa destrói a infraestrutura criada nas etapas acima. Esta etapa também vai destruir os buckets do GCS criados no projeto com o rótulo que você adicionou ao módulo do GCS.

Você pode conferir a saída abaixo no seu 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 exit para sair do contêiner de teste.

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

As tabelas de entradas e saídas nos READMEs do módulo raiz, dos submódulos e dos módulos de exemplo são geradas automaticamente com base no variables e no outputs dos respectivos módulos. Essas tabelas precisarão 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 no CFT

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

Muitos dos arquivos no repositório podem ser linted 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 PR no GitHub

Agora que você mudou o código localmente e o testou nos testes de integração, é hora de publicar esse código no repositório mestre.

Para disponibilizar o código no repositório mestre, você precisa confirmar as alterações de código na ramificação e fazer o push para o repositório mestre. Para que seu código seja adicionado ao repositório principal que você criou no início do codelab, você vai enviar uma solicitação de pull (PR, na sigla em inglês) no repositório mestre depois de confirmar o código no repositório.

Quando você envia um PR, o administrador do repositório é notificado para analisar as mudanças propostas no código. Além disso, você também pode adicionar outros usuários como revisores para receber feedback sobre as mudanças no código. A PR vai acionar um Cloud Build, que vai executar testes no repositório.

Com base nas mudanças, os revisores vão comentar sobre o código e pedir modificações se algo precisar ser alterado com base nas práticas recomendadas e na documentação. O administrador vai analisar 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 mestre.

Siga as etapas abaixo para confirmar o código na sua ramificação e fazer o push do código para a ramificação:

A primeira etapa é adicionar 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 preparados. Em seguida, confirme as alterações.

$ 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 repositório local para o GitHub para criar uma solicitação de envio (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

Suas alterações de código agora estão prontas para uma solicitação de envio.

Execute as etapas a seguir para criar um PR no repositório terraform-google-modules/terraform-google-cloud-storage:

No navegador da Web, acesse a página principal do repositório.
Você vai receber uma sugestão por banner para abrir uma solicitação de alteração na sua bifurcação. Clique em "Solicitação de comparação e extração".

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

Para criar uma solicitação de envio pronta para análise, clique em "Criar solicitação de envio".
Você vai encontrar os gatilhos do Cloud Build em execução, que são acionados devido à PR.
Consulte as documentações oficiais do GitHub sobre como abrir solicitações de envio de bifurcações se tiver problemas.

Você enviou a primeira mudança de código para a ramificação bifurcada e criou sua primeira solicitação de pull de CFT na ramificação mestre.

12. Parabéns

Parabéns! Você adicionou um recurso a um módulo do CFT e enviou um PR para análise.

Você adicionou um recurso a um módulo de CFT, testou-o localmente com um exemplo e realizou testes antes de confirmar o código no GitHub. Por fim, você enviou uma PR para revisão e mesclagem final no CFT.

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