Se usó la API de Cloud Translation para traducir esta página.

Introducción a Cloud Foundation Toolkit

1. Introducción a CFT 101

Última actualización: 11 de febrero de 2022

¿Qué es Cloud Foundation Toolkit?

En términos simples, CFT proporciona plantillas de prácticas recomendadas para dar los primeros pasos en Google Cloud Platform. En este instructivo, aprenderás a contribuir a Cloud Foundation Toolkit.

Requisitos

Una cuenta de GitHub
Tener instalado Docker en tu máquina o usar Cloud Shell ( Instalación en Mac, Instalación de Windows)
Editor de código para editar código (ejemplo: Visual Studio Code)
Conocimientos básicos sobre Git y GitHub
Algo de experiencia con Terraform y la infraestructura como código
Permiso para otorgar el rol de Creador del proyecto a una cuenta de servicio
Una organización de Google Cloud, una carpeta de prueba y una cuenta de facturación

Qué compilarás

En este codelab, aprenderás a contribuir a Cloud Foundation Toolkit (CFT).

Harás lo siguiente:

Configura un entorno de desarrollo para contribuir a CFT
Agrega una función a un módulo de CFT
Cómo agregar pruebas para la función agregada
Ejecuta pruebas de integración en CFT
Cómo ejecutar pruebas de lint
Confirma el código en GitHub y envía una solicitud de extracción (PR)

Para ejecutar todos los pasos anteriores, agregará una nueva función al módulo CFT de Google Cloud Storage. Agregarás una etiqueta llamada "silly_label", que se agregará automáticamente a todos los buckets creados a través del módulo de CFT de GCS. También podrás escribir pruebas para validar tu función y garantizar la integración de extremo a extremo.

2. Configura el entorno de desarrollo

Si lo deseas, puedes usar Cloud Shell para tus tareas de desarrollo. Si no quieres usar Cloud Shell para contribuir a CFT, puedes configurar el entorno de desarrollo en tu máquina.

Configura Git

GitHub se basa en un sistema de control de versión (VCS) de código abierto llamado Git. Git es responsable de todo lo que ocurre en relación con GitHub de manera local en tu máquina o en Cloud Shell.

Cuando usas Cloud Shell, no necesitas instalar Git, ya que está preinstalado.

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

Si quieres configurar el entorno de desarrollo en tu máquina, debes instalar Git.

Cómo configurar tu nombre de usuario y correo electrónico en Git

Git usa un nombre de usuario para asociar confirmaciones con una identidad. El nombre de usuario de Git no es el mismo que tu nombre de usuario de GitHub.

Puedes cambiar el nombre asociado con tus confirmaciones de Git con el comando git config. Cambiar el nombre asociado a tus confirmaciones de Git con git config solo afectará las confirmaciones futuras y no cambiará el nombre que se usa para las confirmaciones anteriores.

Configuraste Git correctamente. Deberías poder bifurcar, crear y clonar ramas. Usaremos Git de forma exhaustiva en este codelab.

3. Repositorio de GCS de Fork CFT

Bifurca un repositorio de CFT

Configuraste Git en tu máquina local o en Cloud Shell en el paso anterior. Ahora, debes bifurcar el repo de CFT de Google Cloud Storage para comenzar a contribuir.

Una bifurcación es una copia de un repositorio. La bifurcación de un repositorio te permite experimentar libremente con los cambios sin afectar el proyecto original.

Por lo general, los tenedores se utilizan para proponer cambios en el proyecto de otra persona o para usar el proyecto de otra persona como punto de partida para tu propia idea.

Por ejemplo, puedes usar bifurcaciones para proponer cambios relacionados con la corrección de un error. Para corregir un error, puedes hacer lo siguiente:

Bifurca el repositorio.
Corrige los errores.
Envía una solicitud de extracción al propietario del proyecto.

Pasos para bifurcar un repositorio de CFT:

Abre tu navegador web y navega al repositorio terraform-google-modules/terraform-google-cloud-storage. Usaremos este repositorio para todo el codelab.
En la esquina superior derecha de la página, haz clic en Bifurcar (Fork).

Verás una opción para saber dónde quieres colocar la bifurcación, elegir tu perfil y se bifurcará el repo.

Clona la bifurcación de forma local

La bifurcación que creaste es una copia del repositorio del módulo de GCS. Ahora clonarás este repositorio en tu entorno local para agregar el atributo nuevo.

Sigue estos pasos para clonar la bifurcación:

Abre tu navegador web y navega a la bifurcación en terraform-google-modules/terraform-google-cloud-storage.
En la esquina superior derecha, encontrará el "Código" haz clic en él.

Después de hacer clic en el "Código" haz clic en el botón "Copiar" para copiar la URL de la bifurcación. Usarás esta URL para clonar la bifurcación en tu entorno local.

Ve a una terminal en VSCode o a tu máquina y clona la bifurcación.

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

Ahora que clonaste la bifurcación de forma local, debes ir a tu repositorio, crear una rama nueva a partir de la bifurcación y realizar cambios en el código a la rama temporal.

Por convención, puedes nombrar tu rama de la siguiente manera:

Para solicitudes de funciones: feature/feature-name
Para realizar actualizaciones internas, internal/change-name
Para correcciones de errores: bugfix/issue-name

Dado que estás agregando una función nueva, puedes llamar a tu rama temporal 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"

Ya está todo listo para comenzar a trabajar en Cloud Foundation Toolkit.

4. Cómo crear un entorno de pruebas

El proceso de desarrollo estándar de CFT se basa en el uso de un proyecto de prueba aislado para pruebas. Este paso te guiará en la creación del proyecto de prueba (basado en una configuración estándar) a través de una cuenta de servicio.

0. Instala Docker Engine

Si utilizas tu máquina con fines de desarrollo, debes instalar Docker Engine.

1. Instala el SDK de Google Cloud

No es necesario que instales el SDK de Google Cloud si usas Cloud Shell en GCP.

Ve al SDK de Google Cloud y descarga el instalador interactivo para tu plataforma.

2. Establece la configuración

Para crear un entorno de prueba, necesitarás una organización de Google Cloud, una carpeta de prueba y una cuenta de facturación. Estos valores deben establecerse a través de variables de entorno:

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

3. Configura tu cuenta de servicio

Antes de crear un entorno de pruebas, debes descargar una clave de cuenta de servicio a tu entorno de pruebas. Esta cuenta de servicio necesitará los roles de Creador de proyecto, Usuario de cuenta de facturación y Visualizador de la organización. Estos pasos te ayudarán a crear una cuenta de servicio nueva, pero también puedes reutilizar una existente.

3.1 Crea o selecciona un proyecto de GCP de origen

Antes de crear tu cuenta de servicio, debes seleccionar un proyecto para alojarla. También puedes crear un proyecto nuevo.

gcloud config set core/project YOUR_PROJECT_ID

3.2 Habilitar las APIs de Google Cloud

Habilita las siguientes APIs de Google Cloud en tu proyecto de origen:

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

3.3 Crea una cuenta de servicio

Crea una cuenta de servicio nueva para administrar el entorno de pruebas:

# 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 que se haya creado la cuenta de servicio:

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

3.4 Otorga los roles Creador de proyectos, Usuario de la cuenta de facturación y Visualizador de la organización a la cuenta de servicio:

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"

Ahora tienes una cuenta de servicio que puede usarse para administrar el entorno de pruebas.

4. Prepara la credencial de Terraform

Para crear el entorno de pruebas, debes descargar la clave de la cuenta de servicio en tu shell.

4.1 Clave de cuenta de servicio

Crea y descarga una clave de cuenta de servicio para Terraform

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

4.2 Configurar la credencial de Terraform

Proporciona la clave a Terraform con la variable de entorno SERVICE_ACCOUNT_JSON y configura el valor según el contenido de la clave de tu cuenta de servicio.

export SERVICE_ACCOUNT_JSON=$(< cft.json)

Después de almacenar la información de las credenciales en la variable de entorno, quita el archivo de claves. Si es necesario, puedes volver a crear una clave más adelante con el mismo comando anterior.

rm -rf cft.json

5. Crea un proyecto de prueba para las implementaciones de Terraform

Ahora que todo está preparado, puedes crear el proyecto de prueba con un solo comando. Ejecuta este comando desde la raíz del directorio terraform-google-cloud-storage:

make docker_test_prepare

Verás el siguiente resultado cuando ejecutes make docker_test_prepare. Al final, recibirás el project_id de prueba que se creó, en el que implementarás y probarás tu módulo de Cloud Storage con la función nueva. Si tienes problemas para vincular una cuenta de facturación, consulta los pasos para solucionar 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.

Ya creaste un proyecto de prueba al que hace referencia project_id, como se puede ver en el resultado de la consola. Se configuró tu entorno de desarrollo y pruebas.

5. Agrega una función nueva al módulo de CFT

Ahora que tu entorno de desarrollo y prueba está configurado, comencemos a agregar tu "silly_label" en el módulo de CFT google-cloud-storage.

Asegúrate de estar en terraform-google-cloud-storage y abre el archivo main.tf como se muestra a continuación en la estructura de carpetas.

Desde "silly_label" es una etiqueta, agregarás el atributo en la línea 27 en la variable "labels" en main.tf, como se muestra a continuación:

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

Ahora, agregarás la variable silly_label en variables.tf que ves en la estructura de carpetas anterior.

Copia y pega el siguiente código, agrégalo a la línea 31 en variables.tf y asegúrate de tener un nuevo carácter de línea arriba y abajo del bloque de variables que agregaste.

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. Agregar un atributo nuevo al ejemplo del bucket de almacenamiento

Agregaste la función al archivo main.tf del módulo y, ahora, la probarás con un ejemplo.

La "silly_label" debe agregarse a la claseexamples/multiple-buckets/main.tf.

Este ejemplo se utilizará en el siguiente paso para realizar pruebas de integración.

Copia y pega la siguiente línea de variable silly_label en la línea 27 de main.tf en terraform-google-cloud-storage/examples/multiple-buckets/, como se ve en la estructura de carpetas:

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. Actualiza la prueba de esquema para verificar la función

Agregaste el atributo al archivo main.tf del módulo y, luego, lo agregaste al ejemplo de multiple_buckets. Ahora, debes probar la función mediante una prueba de integración de plano escrita en Golang.

Agregarás tus nuevas pruebas en el archivo multiple_buckets_test.go que se encuentra en la siguiente estructura de carpetas:

Agregaste “silly_label” en todos los buckets que se crearon con el módulo multiple_buckets y, ahora, debes escribir pruebas para probar la nueva función.

En el siguiente código, obtienes la etiqueta de cada bucket a través del comando gcloud alpha storage y, luego, verificas el resultado que devuelve el 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. Ejecuta pruebas de integración en CFT

Pruebas de integración

Las pruebas de integración se usan para verificar el comportamiento del módulo raíz, los submódulos y los ejemplos. Las incorporaciones, los cambios y las correcciones deben ir acompañadas de pruebas.

Las pruebas de integración se escriben con el framework de prueba de plano y se ejecutan con la CLI de CFT. Estas herramientas están empaquetadas dentro de una imagen de Docker para mayor comodidad.

La estrategia general para estas pruebas es verificar el comportamiento de los módulos de ejemplo y, así, asegurarse de que el módulo raíz, los submódulos y los módulos de ejemplo sean correctos en cuanto a funcionalidad.

En la ejecución interactiva, cada paso se realiza mediante varios comandos.

Ejecuta make docker_run para iniciar el contenedor de Docker de prueba en modo interactivo.

Make es una herramienta de automatización de compilación que compila automáticamente programas ejecutables y bibliotecas a partir del código fuente mediante la lectura de archivos llamados Makefiles que especifican cómo derivar el programa de destino. Cuando realizas cambios en los archivos, el contenedor de Docker se debe actualizar automáticamente.

Cuando ejecutes make docker_run, crearás un lugar de trabajo en tu contenedor de Docker y activarás las credenciales para tu cuenta de servicio. El lugar de trabajo se usará en los siguientes pasos para ejecutar pruebas.

Verás el siguiente resultado en tu terminal:

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

Ejecuta cft test list para enumerar todas las pruebas de planos en tu lugar de trabajo.

Verás el siguiente resultado en tu 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

Ejecuta cft test run <EXAMPLE_NAME> --stage init para inicializar el ejemplo. En este caso, para inicializar la ejecución de prueba TestMultipleBuckets, es cft test run TestMultipleBuckets --stage init. Además, puedes usar la marca --verbose para obtener información adicional cuando ejecutes pruebas.

En esta etapa, se inicializa el ejemplo de Terraform.

Verás el siguiente resultado en tu 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)

Ejecuta cft test run <EXAMPLE_NAME> --stage apply para aplicar el módulo de ejemplo.

En este paso, se aplica el ejemplo inicializado en la etapa anterior al proyecto de GCP que se creó anteriormente en el codelab.

Verás el siguiente resultado en tu 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

Ejecuta cft test run <EXAMPLE_NAME> --stage verify para verificar que el ejemplo creó la infraestructura esperada.

En este paso, se ejecutará la función de verificación en TestMultipleBuckets. Por lo general, la verificación se realiza ejecutando un comando de gcloud para recuperar el resultado de JSON para el estado actual de un recurso y afirmar que el estado actual es el declarado en el ejemplo.

Si recibes algún error, verás lo que se esperaba y lo que recibió el comando para la prueba.

Verás el siguiente resultado en tu 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

Ejecuta cft test run <EXAMPLE_NAME> --stage teardown para eliminar el ejemplo.

En este paso, se destruye la infraestructura que creaste en los pasos anteriores. En este paso, también se destruirán los buckets de GCS que se crearon en el proyecto, junto con la etiqueta que agregaste al módulo de GCS.

Puedes ver el siguiente resultado en tu 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

Ejecuta exit para salir del contenedor de prueba.

9. Generar documentación para entradas y salidas

Las tablas de entrada y salida de los archivos README del módulo raíz, los submódulos y los módulos de ejemplo se generan automáticamente en función de variables y outputs de los módulos respectivos. Estas tablas se deben actualizar si se cambian las interfaces del módulo.

Ejecuta:

make generate_docs
# This will generate new Inputs and Outputs tables

10. Cómo ejecutar pruebas de lint en CFT

Un linter es una herramienta que analiza el código fuente para marcar errores de programación y estilo, y construcciones sospechosas.

Se puede analizar con lint o formatear muchos de los archivos del repositorio para mantener un estándar de calidad. Para garantizar la calidad en CFT, usarás una prueba de lint.

Ejecuta:

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

11. Cómo enviar una solicitud de extracción en GitHub

Ahora que cambiaste el código de forma local y lo probaste a través de las pruebas de integración, deberías publicar este código en el repositorio principal.

Para que tu código esté disponible en el repositorio principal, deberás confirmar los cambios de código realizados en tu rama y enviarlo al repositorio principal. Para que tu código se agregue al repositorio principal que bifurcaste al comienzo del codelab, generarás una solicitud de extracción (PR) en el repositorio principal después de confirmar el código en tu repositorio.

Si envías una solicitud de extracción, el administrador del repositorio recibirá una notificación para que revise los cambios propuestos al código. Además, puedes agregar a otros usuarios como revisores para recibir comentarios sobre los cambios realizados en el código. El PR activará una Cloud Build que ejecutará pruebas en el repositorio.

En función de los cambios que realices en el código, los revisores proporcionarán comentarios sobre el código y solicitarán modificaciones si es necesario cambiar algo en función de las prácticas recomendadas y la documentación. El administrador revisará los cambios en el código, se asegurará de que cumpla con el repositorio y podría volver a solicitarte que realices algunos cambios antes de combinarlo con el repositorio principal.

Ejecuta los siguientes pasos para confirmar el código en la rama bifurcada y enviarlo a la rama bifurcada:

El primer paso es agregar los archivos modificados al repositorio 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

Tus archivos ya están en etapa de pruebas. A continuación, confirmarás los cambios.

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

Envía los cambios confirmados en tu repositorio local a GitHub para crear una solicitud de extracción (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

Los cambios en tu código ya están listos para una solicitud de extracción.

Ejecuta los siguientes pasos para crear un PR al repositorio terraform-google-modules/terraform-google-cloud-storage :

En el navegador web, ve a la página principal del repositorio.
Verás una sugerencia en un banner para abrir una solicitud de relaciones públicas desde tu bifurcación. Haz clic en “Compare and pull request”.

Ingresa un título y una descripción para tu solicitud de extracción para describir los cambios en tu código. Sé lo más específico posible y conciso.

Si deseas crear una solicitud de extracción lista para su revisión, haz clic en “Crear solicitud de extracción”.
Verás los activadores de Cloud Build en ejecución que se activan debido a la solicitud de extracción.
Consulta los documentos oficiales de GitHub sobre cómo abrir solicitudes de extracción desde bifurcaciones si tienes algún problema.

Enviaste correctamente tu primer cambio de código a la rama bifurcada y elevaste tu primer PR de CFT a la rama principal.

12. Felicitaciones

¡Felicitaciones! Agregaste correctamente una función a un módulo de CFT y enviaste un formulario de RR.PP. para su revisión.

Agregaste una función a un módulo de CFT, la probaste de forma local con un ejemplo y realizaste pruebas antes de confirmar el código en GitHub. Por último, presentaste un formulario de Relaciones Públicas para su revisión y la fusión final con CFT.

Ahora conoces los pasos importantes para comenzar a usar Cloud Foundation Toolkit.