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 o Google Cloud Platform rapidamente. Neste tutorial, você vai aprender a contribuir com o Cloud Foundation Toolkit.

O que é necessário

Uma conta do GitHub.
O Docker deve estar instalado na sua máquina ou use o Cloud Shell ( Instalação do Mac, Instalação do 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 Terraform e infraestrutura como código
Permissão para conceder o papel de criador do 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:

Configure um ambiente de desenvolvimento para contribuir com o CFT
Adicionar um atributo a um módulo do CFT
Adicionar testes para o recurso adicionado
Executar testes de integração no CFT
Executar testes de lint
Confirme o código para o GitHub e envie uma solicitação de envio (PR)

Para executar todas as etapas acima, adicione 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 no módulo do GCS CFT. Você também vai poder criar testes para validar seu recurso e garantir uma integração completa.

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 o ambiente de desenvolvimento na sua máquina.

Configurar o Git

O GitHub é baseado em um sistema de controle de versões (VCS) de código aberto chamado Git. O Git é responsável por tudo que está relacionado ao GitHub 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 commits a uma identidade. O nome de usuário do Git não é igual ao do GitHub.

Você pode alterar o nome associado aos 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. Usaremos bastante o Git neste codelab.

3. Fork CFT do repositório do GCS

Bifurcar 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. A bifurcação de um repositório permite testar as alterações livremente 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:

Bifurcar o repositório.
Corrija.
Enviar uma solicitação de envio ao proprietário do projeto.

Etapas para bifurcar um repositório do CFT:

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

Será exibida a opção onde você quer ter a bifurcação, escolher seu perfil, e o repositório será bifurcado.

Clonar sua bifurcação localmente

A bifurcação que você criou é uma cópia do repositório do módulo do GCS. Agora você clonará esse repositório no ambiente local para adicionar o novo atributo.

Etapas para clonar a bifurcação:

Abra o navegador da Web e navegue até a bifurcação em terraform-google-modules/terraform-google-cloud-storage.
No canto superior direito, você vai encontrar o "Código" clique nele.

Depois de clicar no botão "Código", clique no botão "Copiar" para copiar o URL da bifurcação. Você vai usar esse URL para clonar a bifurcação no 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, é possível nomear a ramificação da seguinte forma:

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, você 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"

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

4. Criar um ambiente de teste

O processo padrão de desenvolvimento do CFT usa um projeto de teste isolado para testes. Nesta etapa, vamos ajudar você a criar o 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 sua máquina para fins de desenvolvimento, instale o Docker Engine.

1. Instalar o SDK Google Cloud

Não será 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 a 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. Esses valores precisam ser definidos por meio de 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 a conta de serviço

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

3.1 Criar ou selecionar um projeto de origem do GCP

Antes de criar sua conta de serviço, você precisa selecionar 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 origem:

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 Conceda à conta de serviço os papéis de Criador de projetos, Usuário da conta de faturamento e Leitor da organizaçã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 para gerenciar o ambiente de teste.

4. Prepare a 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 a credencial do Terraform

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

export SERVICE_ACCOUNT_JSON=$(< cft.json)

Depois de armazenar as informações da credencial 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 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

A saída abaixo vai aparecer ao executar make docker_test_prepare. No final, você vai receber o projeto de teste que foi criado. Nele, você vai implantar e testar o módulo do Cloud Storage com o novo recurso. Se você tiver problemas ao 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. Seu ambiente de desenvolvimento e teste está configurado.

5. Adicionar um novo atributo ao módulo do CFT

Agora que o ambiente de desenvolvimento e teste foi configurado, vamos começar a adicionar o "silly_label" no módulo do 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.

Desde "silly_label" for um rótulo, você adicionará o recurso na linha 27 na variável "labels" em main.tf, como você pode ver 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 você vai adicionar a variável silly_label ao arquivo 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 atributo ao exemplo de bucket de armazenamento

Você adicionou o atributo ao main.tf do módulo e agora vai testar o recurso adicionado com um exemplo.

"silly_label" precisam ser adicionados ao arquivo example/multiple-buckets/main.tf

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

Copie e cole a variável silly_label line abaixo na linha 27 em main.tf em terraform-google-cloud-storage/examples/multiple-buckets/ como 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. Atualize o teste de blueprint para verificar o recurso

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

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

Você adicionou "silly_label" em todos os buckets criados com o módulo multiple_buckets e agora você precisa criar testes para conhecer o novo recurso.

No código abaixo, você está recebendo o rótulo de cada bucket por meio do comando "gcloud alpha storage" e depois verifica a saída retornada do 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. Adições, mudanças e correções precisam ser acompanhadas com testes.

Os testes de integração são escritos usando o framework de teste de blueprint e executados usando a CLI do CFT. Por 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, cada etapa é executada por meio de 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 builds que cria automaticamente programas e bibliotecas executáveis com base no 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.

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 seu terminal:

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

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

A saída abaixo vai aparecer no seu 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. Também é possível usar a flag --verbose para receber mais informações ao executar testes.

Esse estágio init 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.

Nesta etapa, a função de verificação será executada 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 ocorrer algum erro, você verá o que era esperado e o que foi recebido pelo comando para o 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 eliminar o exemplo.

Esta etapa destrói a infraestrutura que você criou 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 README do módulo raiz, dos submódulos e dos módulos de exemplo são geradas automaticamente com base no variables e 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

O 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 examinados 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 um RP no GitHub

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

Para disponibilizar o código no repositório mestre, você precisará confirmar as alterações no código na ramificação e enviá-las por push para o repositório mestre. Para que seu código seja adicionado ao repositório principal que você bifurcou no início do codelab, gere uma solicitação de envio (PR, na sigla em inglês) no repositório mestre depois de confirmar o código no seu repositório.

Quando você enviar um PR, o administrador do repositório vai ser notificado para analisar as mudanças propostas no código. Além disso, também é possível adicionar outros usuários como revisores para receber feedback sobre as alterações no código. O PR acionará um Cloud Build que executará testes no repositório.

Com base nas alterações feitas no código, os revisores fornecerão comentários e pedem modificações caso algo precise ser alterado de acordo com as práticas recomendadas e a documentação. O administrador analisará as alterações no código, verificará se ele está em conformidade com o repositório e pode solicitar novamente que você faça algumas alterações antes de mesclar seu código no repositório mestre.

Execute as etapas a seguir para confirmar o código na ramificação bifurcada e enviá-lo por push:

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 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 alterações confirmadas no repositório local para o GitHub para criar 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 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 um RP da sua bifurcação. Clique em "Comparar e enviar solicitação".

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

Para criar uma solicitação de envio pronta para análise, clique em "Criar solicitação de envio".
Você verá gatilhos do Cloud Build em execução que são acionados devido ao PR.
Se você encontrar problemas, consulte os documentos oficiais do GitHub sobre como abrir solicitações de envio de bifurcações (link em inglês).

Você enviou a primeira alteração de código para a ramificação bifurcada e criou o primeiro CFT PR 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 do CFT, testou localmente com um exemplo e realizou testes antes de confirmar seu código no GitHub. Por fim, você enviou um PR para revisão e mesclagem final no CFT.

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