Configura la CI/CD para almacenar la configuración como código de Terraform

En este instructivo, se explica cómo administrar la infraestructura como código con Terraform y Cloud Build mediante la popular metodología GitOps. Weaveworks acuñó el término GitOps y su concepto clave es usar un repositorio de Git para almacenar el estado del entorno que deseas. Terraform es una herramienta de código abierto de HashiCorp que te permite crear, cambiar y mejorar de forma predecible tu infraestructura de nube mediante código. En este instructivo, usarás Cloud Build, un Google Cloud servicio de integración continua, para aplicar de forma automática los manifiestos de Terraform a tu entorno.

Este instructivo es para desarrolladores y operadores que buscan una estrategia precisa a fin de realizar cambios de forma predecible en la infraestructura. En el artículo, se supone que estás familiarizado con Google Cloudy Linux.

Los informes State of DevOps identificaron las capacidades que impulsan el rendimiento de la entrega de software. Este instructivo te ayudará con las siguientes funciones:

• Control de versiones
• Integración continua
• Entrega continua
• Pruebas continuas

Arquitectura

En este instructivo, se aplican prácticas de GitOps para administrar ejecuciones de Terraform. Ten en cuenta que se usan ramas de Secure Source Manager dev y prod para representar entornos reales. Estos entornos se definen mediante redes de nube privada virtual (VPC) dev y prod, respectivamente, dentro de un proyectoGoogle Cloud .

El proceso se inicia cuando envías código de Terraform a la rama dev o prod. En esta situación, Cloud Build se activa y aplica los manifiestos de Terraform para lograr el estado que deseas en el entorno respectivo. Por otro lado, cuando envías código de Terraform a cualquier otra rama (por ejemplo, a una rama de características), Cloud Build se activa para ejecutar terraform plan, pero no se aplica nada a ningún entorno.

Lo ideal es que los operadores o desarrolladores deban hacer propuestas de infraestructura a ramas de desarrollo o de funciones y, luego, enviarlas a través de solicitudes de extracción. De esta manera, puedes analizar y revisar los posibles cambios con los colaboradores y agregar confirmaciones de seguimiento antes de que los cambios se combinen en la rama base.

Si no surgen problemas, primero se deben combinar los cambios en la rama dev. Esta combinación activa una implementación de infraestructura para el entorno dev, lo que te permite probar este entorno. Después de realizar las pruebas y asegurarte de que la implementación es correcta, debes combinar la rama dev con la rama prod para activar la instalación de la infraestructura en el entorno de producción.

Objetivos

• Configura tu instancia y repositorio de Secure Source Manager.
• Configurar Terraform para almacenar el estado en un bucket de Cloud Storage.
• Otorgar permisos a tu cuenta de servicio de Cloud Build.
• Conecta Cloud Build a tu repositorio de Secure Source Manager.
• Cambiar la configuración de tu entorno en una rama de características.
• Promover los cambios en el entorno de desarrollo.
• Promover los cambios en el entorno de producción.

Costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

• Cloud Build
• Cloud Storage
• Compute Engine

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.

Es posible que los usuarios de Google Cloud nuevos cumplan con los requisitos para acceder a una prueba gratuita.

Cuando completes las tareas que se describen en este documento, podrás borrar los recursos que creaste para evitar que se te siga facturando. Para obtener más información, consulta Realiza una limpieza.

Antes de comenzar

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. En Cloud Shell, obtén el ID del proyecto que acabas de seleccionar:

   gcloud config get-value project

   Si este comando no muestra el ID del proyecto, configura Cloud Shell para que use tu proyecto. Reemplaza PROJECT_ID por el ID del proyecto.

   gcloud config set project PROJECT_ID

3. Habilita las API necesarias:

   gcloud services enable cloudbuild.googleapis.com compute.googleapis.com securesourcemanager.googleapis.com

   Este paso puede tardar unos minutos en finalizar.
4. Si nunca usaste Git en Cloud Shell, configúralo con tu nombre y dirección de correo electrónico:

   git config --global user.email "YOUR_EMAIL_ADDRESS"
   git config --global user.name "YOUR_NAME"
   

   Git usa esta información para identificarte como el autor de las confirmaciones que creas en Cloud Shell:

Configura tu repositorio de Secure Source Manager

En este instructivo, usarás un único repositorio de Secure Source Manager para definir tu infraestructura de nube. Debes tener diferentes ramas que correspondan a diferentes entornos para organizar esta infraestructura:

• La rama dev contiene los cambios más recientes que se aplican al entorno de desarrollo.
• La rama prod contiene los cambios más recientes que se aplican al entorno de producción.
• Las ramas de funciones similares a feature_x se usan para realizar cambios antes de enviar a las ramas dev o prod.

Con esta infraestructura, siempre se puede hacer referencia al repositorio a fin de saber qué configuración se espera en cada entorno y combinar cambios nuevos con el entorno dev para proponerlos. Luego, debes combinar la rama dev con la rama posterior prod para promover los cambios.

1. Crea un repositorio vacío de Secure Source Manager sin inicializarlo.

2. Ejecuta el siguiente comando para agregar el asistente de autenticación de Secure Source Manager a tu git config global:

   git config --global credential.'https://*.*.sourcemanager.dev'.helper gcloud.sh
   

   El auxiliar de autenticación usa gcloud CLI para recuperar tus credenciales deGoogle Cloud cuando usas comandos de Git con Secure Source Manager.

3. Para volver a autenticarte después de la configuración inicial de las credenciales, ejecuta el siguiente comando de gcloud CLI:

   gcloud auth login
   

4. Clona el repositorio solutions-terraform-cloudbuild-gitops en tu shell local o entorno de trabajo:

   git clone https://github.com/GoogleCloudPlatform/solutions-terraform-cloudbuild-gitops.git
   

5. Agrega tu repositorio de Secure Source Manager como upstream.

   git remote add google HTTPS_REPO_URL
   

   Aquí HTTPS_REP_URL es la URL HTTPS de tu repositorio de Secure Source Manager. Puedes encontrar la URL en la parte superior de la página del repositorio en la interfaz web de Secure Source Manager.

6. Crea tu rama dev y cambia a ella.

   git checkout dev
   

7. Envía el repositorio clonado a tu repositorio con el siguiente comando:

   git push -u google --all
   

8. Repite los dos pasos anteriores para tu rama prod.

El código de este repositorio está estructurado de la siguiente manera:

• La carpeta environments/ contiene subcarpetas que representan entornos, como dev y prod, que proporcionan una separación lógica entre las cargas de trabajo en diferentes etapas de madurez, desarrollo y producción, respectivamente. Aunque se recomienda que estos entornos sean lo más similares posible, cada subcarpeta tiene su propia configuración de Terraform para garantizar que puedan tener una configuración única según sea necesario.

• La carpeta modules/ contiene módulos de Terraform intercalados. Estos módulos representan agrupaciones lógicas de recursos relacionados y se usan para compartir código entre diferentes entornos.

• El archivo cloudbuild.yaml es un archivo de configuración de compilación que contiene instrucciones para Cloud Build, por ejemplo, cómo realizar tareas en función de un conjunto de pasos. Este archivo especifica una ejecución condicional según la rama de la cual Cloud Build recupera el código, por ejemplo:

  • En las ramas dev y prod, se ejecutan los siguientes pasos:

    1. terraform init
    2. terraform plan
    3. terraform apply

  • Para cualquier otra rama, se ejecutan los siguientes pasos:

    1. terraform init para todas las subcarpetas environments
    2. terraform plan para todas las subcarpetas environments

A fin de garantizar que los cambios propuestos sean adecuados para cada entorno, terraform init y terraform plan se ejecutan en todas las subcarpetas environments. Antes de combinar la solicitud de extracción, por ejemplo, puedes revisar los planes para asegurarte de que no se otorgue acceso a una entidad no autorizada.

Modifica el archivo de configuración de compilación

Para que el archivo de configuración de compilación de muestra funcione con Secure Source Manager, debes realizar las siguientes modificaciones:

• Agrega un paso para clonar tu repositorio.
• Agrega un paso para obtener el nombre de la rama y asignarlo a una variable.

Edita el archivo de configuración de compilación en la rama dev:

1. Cambia a la rama dev:

   git checkout dev
   

2. Abre el archivo cloudbuild.yaml y reemplaza el contenido por lo siguiente:

   # Copyright 2019 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #     https://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   
   steps:
   - id: 'clone repository'
     name: 'gcr.io/cloud-builders/git'
     args:
     - clone
     - '${_REPO_URL}'
     - .
   - id: 'branch name'
     name: gcr.io/cloud-builders/git
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         git checkout ${branch}
         echo "***********************"
         git branch --show-current
         echo "***********************"
   
   - id: 'tf init'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
      branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform init
         else
           for dir in environments/*/
           do
             cd ${dir}
             env=${dir%*/}
             env=${env#*/}
             echo ""
             echo "*************** TERRAFORM INIT ******************"
             echo "******* At environment: ${env} ********"
             echo "*************************************************"
             terraform init || exit 1
             cd ../../
           done
         fi
   
   - id: 'tf plan'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform plan
         else
           for dir in environments/*/
           do
             cd ${dir}
             env=${dir%*/}
             env=${env#*/}
             echo ""
             echo "*************** TERRAFOM PLAN ******************"
             echo "******* At environment: ${env} ********"
             echo "*************************************************"
             terraform plan || exit 1
             cd ../../
           done
         fi
   
   - id: 'tf apply'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform apply -auto-approve
         else
           echo "***************************** SKIPPING APPLYING *******************************"
           echo "Branch '${branch}' does not represent an official environment."
           echo "*******************************************************************************"
         fi

3. Verifica que el archivo se haya modificado.

   git status
   

4. Confirma y envía los cambios:

   git add --all
   git commit -m "Modify build config file."
   git push google dev
   

5. Abre una solicitud de extracción para promover rápidamente tus cambios a la rama prod.

   1. En la interfaz web de Secure Source Manager, navega a tu repositorio.
   2. Haz clic en la pestaña Pull requests.
   3. Haz clic en New pull request.
   4. En el campo merge into:, selecciona la rama prod.
   5. En el campo pull from:, selecciona la rama dev.
   6. Revisa los cambios y, luego, haz clic en Nueva solicitud de extracción.
   7. Haz clic en Create pull request.
   8. Haz clic en Merge pull request.

   9. Vuelve a hacer clic en Merge pull request.

      Los cambios se combinan en tu rama prod.

Configura Terraform para almacenar el estado en un bucket de Cloud Storage

De forma predeterminada, Terraform almacena el estado de manera local en un archivo llamado terraform.tfstate. Esta configuración predeterminada puede dificultar el uso de Terraform para equipos, en especial cuando muchos usuarios ejecutan Terraform al mismo tiempo y cada máquina tiene su propia comprensión de la infraestructura actual.

Para ayudarte a evitar tales problemas, esta sección configura un estado remoto que apunta a un bucket de Cloud Storage. El estado remoto es una característica de los backends y, en este instructivo, se configura en los archivos backend.tf, por ejemplo:

# Copyright 2019 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.


terraform {
  backend "gcs" {
    bucket = "PROJECT_ID-tfstate"
    prefix = "env/dev"
  }
}

En los siguientes pasos, crearás un bucket de Cloud Storage y cambiarás algunos archivos para que apunten a tu bucket nuevo y a tu proyecto Google Cloud .

1. En Cloud Shell, crea el bucket de Cloud Storage:

   PROJECT_ID=$(gcloud config get-value project)
   gcloud storage buckets create gs://${PROJECT_ID}-tfstate
   

2. Habilita el control de versiones de objetos para mantener el historial de tus implementaciones:

   gcloud storage buckets update gs://${PROJECT_ID}-tfstate --versioning
   

   Habilitar el control de versiones de objetos aumenta los costos de almacenamiento, lo cual se puede mitigar si configuras la Administración del ciclo de vida de los objetos para que borre versiones de estado anteriores.

3. Crea una nueva rama cloud-storage-bucket para realizar los cambios:

   cd ~/solutions-terraform-cloudbuild-gitops
   git checkout -b cloud-storage-bucket
   

4. Reemplaza el marcador de posición PROJECT_ID por el ID del proyecto en los archivos terraform.tfvars y backend.tf:

   sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
   sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf
   

   En OS X o macOS, es posible que debas agregar dos comillas ("") después de sed -i de la siguiente manera:

   sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
   sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf
   

5. Verifica si todos los archivos se actualizaron:

   git status
   

   El resultado obtenido se verá así:

   On branch cloud-storage-bucket
   Changes not staged for commit:
   (use "git add ..." to update what will be committed)
   (use "git restore ..." to discard changes in working directory)
          modified:   environments/dev/backend.tf
          modified:   environments/dev/terraform.tfvars
          modified:   environments/prod/backend.tf
          modified:   environments/prod/terraform.tfvars
   no changes added to commit (use "git add" and/or "git commit -a")
   

6. Confirma y envía los cambios:

   git add --all
   git commit -m "Update project IDs and buckets"
   git push google -u cloud-storage-bucket
   

   La nueva rama cloud-storage-bucket se envió a tu repositorio.

7. Combina los cambios de cloud-storage-bucket en tus ramas dev y prod. Para ello, abre y envía solicitudes de combinación para cada rama.

Otorga permisos a tu cuenta de servicio de Cloud Build

Para permitir que la cuenta de servicio de Cloud Build ejecute secuencias de comandos de Terraform con el objetivo de administrar recursos de Google Cloud , debes otorgarle el acceso adecuado a tu proyecto. Para hacerlo más simple, en este instructivo, se otorga acceso de editor de proyectos. En los entornos de producción, sigue las prácticas recomendadas de seguridad de TI de tu empresa, lo que suele implicar proporcionar un acceso de mínimo privilegio.

Nota: Se cambiará la cuenta de servicio predeterminada de Cloud Build que se usa para ejecutar compilaciones. Como práctica recomendada, te sugerimos que especifiques tu propia cuenta de servicio para ejecutar tus compilaciones. Para obtener más información, consulta Cambio de la cuenta de servicio de Cloud Build.

1. Para encontrar el correo electrónico de la cuenta de servicio de Cloud Build, en la página de Cloud Build, navega a Configuración.

   Ir a la configuración de Cloud Build

2. Copia el valor del correo electrónico de la cuenta de servicio.

3. Otorga el acceso requerido a tu cuenta de servicio de Cloud Build:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member serviceAccount:CLOUDBUILD_SA --role roles/editor
   

   Reemplaza lo siguiente:

   • PROJECT_ID por el ID del proyecto
   • CLOUDBUILD_SA con el correo electrónico de la cuenta de servicio de Cloud Build

Conéctate a Cloud Build

Para activar Cloud Build cuando se envíe un cambio a cualquier rama, configura un webhook de Secure Source Manager. El archivo de configuración de compilación verificará el nombre de la rama para determinar si se deben realizar cambios en los entornos dev o prod.

1. Habilita y configura Cloud Build en tu proyecto.

2. Abre la página Activadores en la consola de Google Cloud .

   Abrir la página Activadores

3. Selecciona tu proyecto en el menú desplegable del selector de proyectos en la parte superior de la página.

4. Haz clic en Abrir.

5. Haz clic en Crear activador.

6. Ingresa las siguientes opciones de configuración del activador:

   • Nombre: trigger-on-push

   • Región: Selecciona la región para tu activador. Si el archivo de configuración de compilación asociado a tu activador especifica un grupo privado, la región que selecciones para tu activador debe coincidir con la región del grupo privado.

     Nota: Si usas un grupo privado, debes asignar IPs externas para permitir que tu grupo privado acceda a Internet pública. Para obtener más información, consulta Crea un grupo privado nuevo.

     Si seleccionas global como tu región, Cloud Build usará la región especificada en tu archivo de configuración de compilación para ejecutar la compilación. Puede ser la región del grupo privado, si especificas uno en el archivo de configuración de la compilación, o el grupo predeterminado global si no especificas un grupo privado.

   • Descripción (opcional): Ingresa una descripción para el activador.

   • Evento: Selecciona Evento de webhook como el evento del repositorio para invocar el activador.

     Si Secret Manager no está instalado, se te solicitará que lo habilites.

   • URL de webhook: Selecciona una de las siguientes opciones:

     • Usar un secreto nuevo si deseas generar un secreto nuevo con Cloud Build Haz clic en Crear secreto para crear tu secreto.
     • Usar un secreto existente o crear uno propio si quieres usar un secreto existente Ingresa el secreto y la versión en los cuadros de selección desplegables.

     Si usas un secreto existente, es posible que debas otorgar de forma manual el rol de Secret Manager Secret Accessor al agente de servicio de Cloud Build [e-mail].

     Para obtener más información, consulta Otorga una función al agente de servicio de Cloud Build.

7. Haz clic en Mostrar vista previa de la URL y registra la URL. Necesitas esta URL para configurar el webhook en Secure Source Manager.

   • Configuración: En Tipo, selecciona Archivo de configuración de Cloud Build (YAML o JSON) y, en Ubicación, selecciona En línea.

8. Haz clic en el botón Abrir editor para editar el archivo de configuración de compilación.

9. Copia el contenido de tu archivo cloudbuild.yaml en el editor.

   Como se detalló antes, esta canalización tiene comportamientos diferentes según la rama que se recupera. La compilación verifica si la variable ${branch} coincide con alguna carpeta de entorno. Si es así, Cloud Build ejecuta terraform plan para ese entorno. De lo contrario, Cloud Build ejecuta terraform plan para todos los entornos a fin de garantizar que el cambio propuesto sea apropiado en todos ellos. Si alguno de estos planes no se ejecuta, falla la compilación.

   - id: 'tf plan'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform plan
         else
           for dir in environments/*/
           do
             cd ${dir}
             env=${dir%*/}
             env=${env#*/}
             echo ""
             echo "*************** TERRAFOM PLAN ******************"
             echo "******* At environment: ${env} ********"
             echo "*************************************************"
             terraform plan || exit 1
             cd ../../
           done
         fi

   El comando terraform apply se ejecuta para las ramas de entorno, pero se ignora por completo en cualquier otro caso.

10. Haz clic en + Agregar variable y agrega las siguientes dos variables de sustitución:

    • Variable: _REPO_URL, Valor:$(body.repository.clone_url)
    • Variable: _REF, Valor:$(body.ref)

11. Haz clic en Crear.

Configura un webhook en Secure Source Manager

Crea un webhook para activar compilaciones cuando se envíen confirmaciones a tus ramas dev o prod.

1. En la interfaz web de Secure Source Manager, navega al repositorio para el que deseas crear un webhook.
2. Haz clic en Configuración.
3. Haz clic en Webhooks y, luego, en Add webhook.

4. En el campo ID de webhook, ingresa un ID para el webhook.

   Nota: Los IDs de los hooks deben seguir la convención de nomenclatura de recursos. Solo deben incluir letras en minúscula, números o guiones, deben comenzar con una letra y no se pueden cambiar después de crear el webhook.

5. En el campo URL de destino, ingresa la URL de webhook que copiaste cuando configuraste un activador de webhook en Cloud Build.

   Para encontrar la URL del webhook, sigue estos pasos:

   1. Abre la página Activadores en la consola de Google Cloud .

      Abrir la página Activadores

   2. Haz clic en el activador.

   3. En la sección URL de webhook, haz clic en Mostrar vista previa de la URL y copia la URL.

6. La URL del webhook contiene los valores de clave y secreto que ingresaste cuando creaste el activador de Cloud Build. Para evitar que se filtren estos valores, quítalos del final de la URL de destino y cópialos en el campo Cadena de consulta sensible.

   Para ubicar la clave y el secreto en la URL del webhook, busca el texto que comienza con key=.

   Por ejemplo, dada la siguiente URL: https://cloudbuild.googleapis.com/v1/projects/my-project/triggers/test-trigger:webhook?key=eitIfKhYnv0LrkdsyHqIros8fbsheKRIslfsdngf&secret=Hello%20Secret%20Manager

   Copia y quita la parte que comienza con el signo de interrogación ?key=... del campo URL de destino. Luego, quita el signo de interrogación inicial y mueve la parte restante key=... al campo Cadena de consulta sensible.

7. Haz clic en Add webhook (Agregar webhook).

8. El webhook se muestra en la página Webhooks.

   Nota: Cuando agregas o editas un webhook, la longitud de Sensitive Query String puede no coincidir con la que ingresaste, lo que es normal, ya que se usan cadenas de marcadores de posición para garantizar la seguridad.

Cambia la configuración de tu entorno en una rama de características nueva

1. Asegúrate de estar en la rama dev:

   cd ~/solutions-terraform-cloudbuild-gitops
   git checkout dev
   

2. Extrae los cambios más recientes:

   git pull
   

3. Crea una rama bug-fix para cambiar la configuración del entorno.

   git checkout -b bug-fix
   

4. Abre modules/firewall/main.tf para editarla.

5. En la línea 30, corrige el error tipográfico "http-server2" en el campo target_tags.

   El valor debe ser "http-server".

6. Confirma y envía los cambios:

   git add --all
   git commit -m "Fix typo."
   git push google -u bug-fix
   

7. Abre la página Historial de Cloud Build en la Google Cloud consola:

   Abrir la página Historial

8. Haz clic en Compilación para ver más información, incluido el resultado de terraform plan.

Ten en cuenta que el trabajo de Cloud Build ejecutó la canalización definida en el archivo cloudbuild.yaml. Como se detalló antes, esta canalización tiene comportamientos diferentes según la rama que se recupera. La compilación verifica si la variable ${branch} coincide con alguna carpeta de entorno. Si es así, Cloud Build ejecuta terraform plan para ese entorno. De lo contrario, Cloud Build ejecuta terraform plan para todos los entornos a fin de garantizar que el cambio propuesto sea apropiado en todos ellos. Si alguno de estos planes no se ejecuta, falla la compilación.

- id: 'tf plan'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      branch=$(basename "$_REF")
      if [ -d "environments/${branch}/" ]; then
        cd environments/${branch}
        terraform plan
      else
        for dir in environments/*/
        do
          cd ${dir}
          env=${dir%*/}
          env=${env#*/}
          echo ""
          echo "*************** TERRAFOM PLAN ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform plan || exit 1
          cd ../../
        done
      fi

De manera similar, el comando terraform apply se ejecuta para las ramas de entorno, pero se ignora por completo en cualquier otro caso. En esta sección, enviaste un cambio de código a una rama nueva, por lo que no se aplicaron implementaciones de infraestructura en tu proyecto de Google Cloud .

- id: 'tf apply' name: 'hashicorp/terraform:1.0.0' entrypoint: 'sh' args: - '-c' - | branch=$(basename "$_REF") if [ -d "environments/${branch}/" ]; then cd environments/${branch} terraform apply -auto-approve else echo "***************************** SKIPPING APPLYING *******************************" echo "Branch '${branch}' does not represent an official environment." echo "*******************************************************************************" fi

Promueve los cambios en el entorno de desarrollo

Es momento de aplicar el estado que deseas en el entorno dev.

1. En la interfaz web de Secure Source Manager, navega a tu repositorio.
2. Haz clic en New pull request.
3. En el campo merge into:, selecciona tu rama dev.
4. En el campo pull from:, selecciona tu rama bug-fix.
5. Haz clic en New pull request.
6. Haz clic en Create pull request.
7. Haz clic en Merge pull request y, luego, vuelve a hacer clic en Merge pull request.

8. Verifica que se haya activado una Cloud Build nueva:

   Ir a la página Cloud Build

9. Abre la compilación y verifica los registros.

   Cuando finalice la compilación, verás algo como lo siguiente:

   Step #3 - "tf apply": external_ip = EXTERNAL_IP_VALUE
   Step #3 - "tf apply": firewall_rule = dev-allow-http
   Step #3 - "tf apply": instance_name = dev-apache2-instance
   Step #3 - "tf apply": network = dev
   Step #3 - "tf apply": subnet = dev-subnet-01
   

10. Copia EXTERNAL_IP_VALUE y abre la dirección en un navegador web.

    http://EXTERNAL_IP_VALUE
    

    Este aprovisionamiento puede tardar unos segundos en iniciar la VM y propagar la regla de firewall. Con el tiempo, verás Entorno: dev en el navegador web.

11. Navega a Cloud Storage:

    Ir a la página de Cloud Storage

12. Elige tu proyecto.

13. Haz clic en tu bucket de almacenamiento de estado de Terraform. El nombre del bucket se ve de la siguiente manera:

    PROJECT_ID-tfstate
    

14. Haz clic en env y, luego, en dev para ver tu archivo de estado de Terraform.

Promueve los cambios en el entorno de producción

Ahora que probaste por completo tu entorno de desarrollo, puedes promover tu código de infraestructura en la producción.

1. En la interfaz web de Secure Source Manager, navega a tu repositorio.
2. Haz clic en la pestaña Pull requests.
3. Haz clic en New pull request.
4. En merge into:, selecciona la rama prod de tu repositorio.
5. En pull from:, selecciona la rama dev de tu repositorio.
6. Haz clic en New pull request.
7. En título, ingresa un título como "Promoting networking changes" y, luego, haz clic en Crear solicitud de extracción.

8. Revisa los cambios propuestos y, luego, haz clic en Combinar solicitud de extracción.

   La fecha y la URL del repositorio se agregan en el campo de comentarios.

9. Vuelve a hacer clic en Merge pull request para confirmar.

10. En la Google Cloud consola, abre la página Historial de compilación para ver cómo se aplican tus cambios en el entorno de producción:

    Ir a la página Cloud Build

11. Espera a que termine la compilación y, luego, verifica los registros.

    Al final de los registros, verás algo como esto:

    Step #3 - "tf apply": external_ip = EXTERNAL_IP_VALUE
    Step #3 - "tf apply": firewall_rule = prod-allow-http
    Step #3 - "tf apply": instance_name = prod-apache2-instance
    Step #3 - "tf apply": network = prod
    Step #3 - "tf apply": subnet = prod-subnet-01
    

12. Copia EXTERNAL_IP_VALUE y abre la dirección en un navegador web.

    http://EXTERNAL_IP_VALUE
    

    Este aprovisionamiento puede tardar unos segundos en iniciar la VM y propagar la regla de firewall. Con el tiempo, verás Entorno: prod en el navegador web.

13. Navega a Cloud Storage:

    Ir a la página de Cloud Storage

14. Elige tu proyecto.

15. Haz clic en tu bucket de almacenamiento de estado de Terraform. El nombre del bucket se ve de la siguiente manera:

    PROJECT_ID-tfstate
    

16. Haz clic en env y, luego, en prod para ver tu archivo de estado de Terraform.

Configuraste con éxito una canalización de infraestructura como código sin servidores en Cloud Build. En el futuro, podrías probar lo siguiente:

• Agregar implementaciones para casos prácticos independientes
• Crear entornos adicionales para reflejar tus necesidades
• Usar un proyecto por entorno en lugar de una VPC por entorno

Limpia

Una vez que terminaste el instructivo, limpia los recursos que creaste enGoogle Cloud para que no se facturen en el futuro.

Borra el proyecto

Precaución: Borrar un proyecto tiene las siguientes consecuencias:

• Se borra todo en el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
• Se pierden los IDs personalizados de los proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URLs que usan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto, en lugar de todo el proyecto.

Si planeas explorar varios instructivos, arquitecturas o guías de inicio rápido, reutilizar proyectos puede ser útil para no exceder los límites de cuota de los proyectos.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

¿Qué sigue?

• Considera usar plantillas de Cloud Foundation Toolkit para compilar con rapidez una base lista para empresas repetible enGoogle Cloud.
• Mira el video sobre entornos Google Cloud repetibles a gran escala con canalizaciones de infraestructura como código de Cloud Build de Next'19 acerca del flujo de trabajo de GitOps descrito en este instructivo.
• Consulta el instructivo de entrega continua de estilo GitOps con Cloud Build.
• Consulta las características más avanzadas de Cloud Build: Configura el orden de los pasos de la compilación, Compila, prueba e implementa artefactos, y Crea pasos de compilación personalizados.
• Consulta el blog Garantiza el escalamiento y el cumplimiento de tus implementaciones de Terraform con Cloud Build.
• Lee nuestros recursos sobre DevOps.
• Obtén más información sobre las capacidades de DevOps relacionadas con este instructivo:
  • Control de versiones
  • Integración continua
  • Entrega continua
  • Pruebas continuas
• Realiza la verificación rápida de DevOps para comprender cuál es tu posición en comparación con el resto de la industria.