Gestionar la infraestructura como código con Terraform, Cloud Build y GitOps

En este tutorial se explica cómo gestionar la infraestructura como código con Terraform y Cloud Build mediante la conocida metodología GitOps. El término GitOps fue acuñado por Weaveworks y su concepto clave es usar un repositorio de Git para almacenar el estado del entorno que quieras. Terraform es una herramienta de HashiCorp que te permite crear, cambiar y mejorar tu infraestructura de nube de forma predecible mediante código. En este tutorial, usarás Cloud Build (un servicio de integración continua) para aplicar automáticamente manifiestos de Terraform a tu entorno. Google Cloud

Este tutorial está dirigido a desarrolladores y operadores que buscan una estrategia elegante para hacer cambios en la infraestructura de forma predecible. En este artículo se presupone que estás familiarizado con Google Cloud, Linux y GitHub.

En los informes State of DevOps se identificaron las funciones que mejoran el rendimiento del envío de software. Este tutorial te ayudará a usar las siguientes funciones:

Arquitectura

Para mostrar cómo se aplican las prácticas de GitOps en este tutorial para gestionar las ejecuciones de Terraform, consulta el siguiente diagrama de arquitectura. Ten en cuenta que usa ramas de GitHub (dev y prod) para representar entornos reales. Estos entornos se definen mediante redes de nube privada virtual (VPC): dev y prod, respectivamente, en un Google Cloud proyecto.

Infraestructura con entornos de desarrollo y producción.

El proceso comienza cuando insertas código de Terraform en la rama dev o prod. En este caso, Cloud Build activa y, a continuación, aplica manifiestos de Terraform para conseguir el estado que quieras en el entorno correspondiente. Por otro lado, cuando insertas código de Terraform en cualquier otra rama (por ejemplo, en una rama de función), Cloud Build se ejecuta para ejecutar terraform plan, pero no se aplica nada a ningún entorno.

Lo ideal es que los desarrolladores o los operadores hagan propuestas de infraestructura a las ramas no protegidas y, a continuación, las envíen mediante solicitudes de extracción. La aplicación de GitHub para Cloud Build, que se explica más adelante en este tutorial, activa automáticamente las tareas de compilación y vincula los informes de terraform plan a estas solicitudes de extracción. De esta forma, puedes hablar y revisar los posibles cambios con los colaboradores y añadir confirmaciones de seguimiento antes de que los cambios se combinen en la rama base.

Si no hay ningún problema, primero debes combinar los cambios en la rama dev. Esta combinación activa un despliegue de infraestructura en el entorno dev, lo que te permite probarlo. Una vez que hayas probado lo que se ha implementado y estés seguro de que funciona correctamente, 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 repositorio de GitHub.
  • Configura Terraform para almacenar el estado en un segmento de Cloud Storage.
  • Concede permisos a tu cuenta de servicio de Cloud Build.
  • Conecta Cloud Build a tu repositorio de GitHub.
  • Cambia la configuración del entorno en una rama de función.
  • Promocionar los cambios al entorno de desarrollo.
  • Promociona los cambios al entorno de producción.

Costes

En este documento, se utilizan los siguientes componentes facturables de Google Cloud:

Para generar una estimación de costes basada en el uso previsto, utiliza la calculadora de precios.

Los usuarios nuevos Google Cloud pueden disfrutar de una prueba gratuita.

Cuando termines las tareas que se describen en este documento, puedes evitar que se te siga facturando eliminando los recursos que has creado. Para obtener más información, consulta la sección Limpiar.

Requisitos previos

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

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

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

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

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  5. Verify that billing is enabled for your Google Cloud project.

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

  7. En Cloud Shell, obtén el ID del proyecto que acabas de seleccionar: 
    gcloud config get-value project
     Si este comando no devuelve el ID del proyecto, configura Cloud Shell para que use tu proyecto. Sustituye PROJECT_ID por el ID de tu proyecto. 
    gcloud config set project PROJECT_ID
  8. Habilita las APIs necesarias: 
    gcloud services enable cloudbuild.googleapis.com compute.googleapis.com
     Este paso puede tardar unos minutos en completarse.
  9. Si nunca has usado Git en Cloud Shell, configúralo con tu nombre y tu 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.

    10. Configurar un repositorio de GitHub

    En este tutorial, usarás un único repositorio de Git para definir tu infraestructura en la nube. Para organizar esta infraestructura, puedes tener diferentes ramas que correspondan a diferentes entornos:

    • La rama dev contiene los últimos cambios que se aplican al entorno de desarrollo.
    • La rama prod contiene los últimos cambios que se aplican al entorno de producción.

    Con esta infraestructura, siempre puedes consultar el repositorio para saber qué configuración se espera en cada entorno y proponer nuevos cambios fusionándolos primero en el entorno dev. A continuación, puedes promover los cambios combinando la rama dev con la rama prod.

    Para empezar, crea una bifurcación del repositorio solutions-terraform-cloudbuild-gitops.

    1. En GitHub, ve a https://github.com/GoogleCloudPlatform/solutions-terraform-cloudbuild-gitops.git.

    2. En la esquina superior derecha de la página, haz clic en Bifurcar.

      Bifurcar un repositorio.

      Ahora tienes una copia del repositorio solutions-terraform-cloudbuild-gitops con los archivos de origen.

    1. En Cloud Shell, clona este repositorio bifurcado y sustituye YOUR_GITHUB_USERNAME por tu nombre de usuario de GitHub:

      cd ~
git clone https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops.git
cd ~/solutions-terraform-cloudbuild-gitops

    El código de este repositorio se estructura 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 fases de madurez, desarrollo y producción, respectivamente. Aunque es recomendable que estos entornos sean lo más parecidos posible, cada subcarpeta tiene su propia configuración de Terraform para asegurarse de que puedan tener ajustes únicos según sea necesario.

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

    • El archivo cloudbuild.yaml es un archivo de configuración de compilación que contiene instrucciones para Cloud Build, como la forma de realizar tareas basadas en un conjunto de pasos. Este archivo especifica una ejecución condicional en función de la rama de la que Cloud Build obtiene el código. Por ejemplo:

      • En las ramas dev y prod, se siguen estos pasos:

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

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

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

    Para asegurarnos de que los cambios propuestos son adecuados para todos los entornos, se ejecutan terraform init y terraform plan en todas las subcarpetas de environments. Antes de combinar la solicitud de extracción, puedes revisar los planes para asegurarte de que no se concede acceso a una entidad no autorizada, por ejemplo.

    Configurar Terraform para almacenar el estado en un segmento de Cloud Storage

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

    Para ayudarte a evitar estos problemas, en esta sección se configura un estado remoto que apunta a un segmento de Cloud Storage. El estado remoto es una función de los backends y, en este tutorial, 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á un segmento de Cloud Storage y cambiará algunos archivos para que apunten a su nuevo segmento y a su proyecto Google Cloud .

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

      PROJECT_ID=$(gcloud config get-value project)
gcloud storage buckets create gs://${PROJECT_ID}-tfstate
      1. Habilita la gestión de versiones de objetos para conservar el historial de tus implementaciones:

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

Enabling Object Versioning increases
[storage costs](/storage/pricing){: track-type="tutorial" track-name="internalLink" track-metadata-position="body" },
which you can mitigate by configuring
[Object Lifecycle Management](/storage/docs/lifecycle){: track-type="tutorial" track-name="internalLink" track-metadata-position="body" } 
to delete old state versions.

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

        cd ~/solutions-terraform-cloudbuild-gitops
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 tengas que añadir dos comillas ("") después de sed -i, como se indica a continuación:

        cd ~/solutions-terraform-cloudbuild-gitops
sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf

      2. Comprueba si se han actualizado todos los archivos:

        git status

        La salida tiene este aspecto:

        On branch dev
Your branch is up-to-date with 'origin/dev'.
Changes not staged for commit:
 (use "git add <file>..." to update what will be committed)
 (use "git checkout -- <file>..." 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")

      3. Confirma y envía los cambios:

        git add --all
git commit -m "Update project IDs and buckets"
git push origin dev

        En función de la configuración de GitHub, tendrás que autenticarte para enviar los cambios anteriores.

      Conceder permisos a la 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 gestionar recursos de Google Cloud , debes concederle el acceso adecuado a tu proyecto. Para simplificar las cosas, en este tutorial se concede acceso de editor de proyectos. Sin embargo, cuando el rol de editor de proyectos tiene un permiso amplio, en los entornos de producción debes seguir las prácticas recomendadas de seguridad de TI de tu empresa, que suelen proporcionar acceso con los privilegios mínimos. Para consultar las prácticas recomendadas de seguridad, consulta Verificar explícitamente cada intento de acceso.

      1. En Cloud Shell, recupera el correo de la cuenta de servicio de Cloud Build de tu proyecto:

        CLOUDBUILD_SA="$(gcloud projects describe $PROJECT_ID \
    --format 'value(projectNumber)')@cloudbuild.gserviceaccount.com"

      2. Concede el acceso necesario a tu cuenta de servicio de Cloud Build:

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

      Conectar Cloud Build directamente a tu repositorio de GitHub

      En esta sección se explica cómo instalar la aplicación de GitHub para Cloud Build. Esta instalación te permite conectar tu repositorio de GitHub con tuGoogle Cloud proyecto para que Cloud Build pueda aplicar automáticamente tus manifiestos de Terraform cada vez que crees una rama o insertes código en GitHub.

      En los pasos siguientes se explica cómo instalar la aplicación solo para el repositorio solutions-terraform-cloudbuild-gitops, pero puedes instalarla para más repositorios o para todos.

      1. Ve a la página de GitHub Marketplace de la aplicación Cloud Build:

        Abrir la página de la aplicación Cloud Build

        • Si es la primera vez que configuras una aplicación en GitHub, haz clic en Configurar con Google Cloud Build en la parte inferior de la página. A continuación, haz clic en Grant this app access to your GitHub account (Conceder acceso a esta aplicación a tu cuenta de GitHub).
        • Si no es la primera vez que configuras una aplicación en GitHub, haz clic en Configurar acceso. Se abrirá la página Aplicaciones de tu cuenta personal.

      2. En la fila de Cloud Build, haga clic en Configurar.

      3. Selecciona Solo repositorios seleccionados y, a continuación, solutions-terraform-cloudbuild-gitops para conectarte al repositorio.

      4. Haz clic en Guardar o en Instalar. La etiqueta del botón cambia en función de tu flujo de trabajo. Se te redirigirá a Google Cloud para continuar con la instalación.

      5. Inicia sesión con tu cuenta de Google Cloud . Si se te solicita, autoriza la integración de Cloud Build con GitHub.

      6. En la página Cloud Build, selecciona tu proyecto. Aparecerá un asistente.

      7. En la sección Select repository (Seleccionar repositorio), selecciona tu cuenta de GitHub y el repositorio solutions-terraform-cloudbuild-gitops.

      8. Si acepta los términos y condiciones, marque la casilla y haga clic en Conectar.

      9. En la sección Crear un activador, haz clic en Crear un activador:

        1. Añade un nombre de activador, como push-to-branch. Anota el nombre de este activador, ya que lo necesitarás más adelante.
        2. En la sección Evento, selecciona Enviar a una rama.
        3. En la sección Fuente, selecciona .* en el campo Rama.
        4. Haz clic en Crear.

      La aplicación de GitHub para Cloud Build ya está configurada y tu repositorio de GitHub está vinculado a tu proyecto Google Cloud . A partir de ahora, los cambios en el repositorio de GitHub activarán ejecuciones de Cloud Build, que informarán de los resultados a GitHub mediante comprobaciones de GitHub.

      Cambiar la configuración del entorno en una nueva rama de funciones

      A estas alturas, ya habrás configurado la mayor parte de tu entorno. Por lo tanto, es el momento de hacer algunos cambios en el código en tu entorno de desarrollo.

      1. En GitHub, ve a la página principal del repositorio bifurcado.

        https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops

      2. Asegúrate de que estás en la rama dev.

      3. Para abrir el archivo y editarlo, ve al archivo modules/firewall/main.tf y haz clic en el icono del lápiz.

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

        El valor debe ser "http-server".

      5. Añade un mensaje de confirmación en la parte inferior de la página, como "Fixing http firewall target", y selecciona Crea una rama para esta confirmación y empieza una solicitud de extracción.

      6. Haga clic en Proponer cambios.

      7. En la página siguiente, haz clic en Crear solicitud de extracción para abrir una nueva solicitud de extracción con tu cambio.

        Una vez que se abre la solicitud de extracción, se inicia automáticamente un trabajo de Cloud Build.

      8. Haz clic en Mostrar todas las comprobaciones y espera a que la comprobación se ponga en verde.

        Mostrar todas las comprobaciones de una solicitud de extracción.

      9. Haz clic en Detalles para ver más información, incluida la salida de terraform plan en el enlace Ver más detalles sobre Google Cloud Build.

      No combines aún tu solicitud de extracción.

      Ten en cuenta que el trabajo de Cloud Build ha ejecutado la canalización definida en el archivo cloudbuild.yaml. Como hemos comentado anteriormente, esta canalización tiene comportamientos diferentes en función de la rama que se esté obteniendo. La compilación comprueba si la variable $BRANCH_NAME 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 en todos los entornos para asegurarse de que el cambio propuesto sea adecuado para todos ellos. Si no se puede ejecutar alguno de estos planes, la compilación fallará.

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

      Del mismo modo, el comando terraform apply se ejecuta en las ramas del entorno, pero se ignora por completo en cualquier otro caso. En esta sección, has enviado un cambio de código a una rama nueva, por lo que no se han aplicado despliegues de infraestructura a tu proyecto Google Cloud .

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

      Forzar que las compilaciones de Cloud Build se completen correctamente antes de combinar ramas

      Para asegurarse de que las combinaciones solo se puedan aplicar cuando las ejecuciones de Cloud Build correspondientes se hayan completado correctamente, siga estos pasos:

      1. En GitHub, ve a la página principal del repositorio bifurcado.

        https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops

      2. Debajo del nombre del repositorio, haz clic en Settings (Configuración).

      3. En el menú de la izquierda, haga clic en Sucursales.

      4. En Reglas de protección de ramas, haz clic en Añadir regla.

      5. En Patrón de nombre de rama, escribe dev.

      6. En la sección Proteger ramas coincidentes, selecciona Requerir que se superen las comprobaciones de estado antes de combinar.

      7. Busca el nombre del activador de Cloud Build que hayas creado anteriormente.

      8. Haz clic en Crear.

      9. Repite los pasos del 3 al 7 y asigna el valor prod a Patrón de nombre de rama.

      Esta configuración es importante para proteger las ramas dev y prod. Es decir, los commits deben enviarse primero a otra rama y, solo entonces, se pueden combinar con la rama protegida. En este tutorial, la protección requiere que la ejecución de Cloud Build se realice correctamente para que se permita la combinación.

      Promocionar cambios en el entorno de desarrollo

      Tienes una solicitud de extracción pendiente de combinación. Es el momento de aplicar el estado que quieras a tu entorno dev.

      1. En GitHub, ve a la página principal del repositorio bifurcado.

        https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops

      2. Debajo del nombre del repositorio, haz clic en Pull requests (Solicitudes de extracción).

      3. Haz clic en la solicitud de extracción que acabas de crear.

      4. Haz clic en Combinar solicitud de extracción y, a continuación, en Confirmar combinación.

        Confirma la combinación.

      5. Comprueba que se haya activado una nueva compilación de Cloud Build:

        Ir a la página Cloud Build

      6. Abre la compilación y consulta los registros.

        Cuando finalice la compilación, verá algo parecido a 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

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

        http://EXTERNAL_IP_VALUE

        El aprovisionamiento puede tardar unos segundos en arrancar la VM y en propagar la regla de firewall. Al final, verás Environment: dev en el navegador web.

      8. Ve al archivo de estado de Terraform en tu segmento de Cloud Storage.

        https://storage.cloud.google.com/PROJECT_ID-tfstate/env/dev/default.tfstate

      Promocionar cambios en el entorno de producción

      Ahora que has probado completamente tu entorno de desarrollo, puedes promover tu código de infraestructura a producción.

      1. En GitHub, ve a la página principal del repositorio bifurcado.

        https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops

      2. Debajo del nombre del repositorio, haz clic en Pull requests (Solicitudes de extracción).

      3. Haz clic en Nueva solicitud de extracción.

      4. En repositorio base, selecciona el repositorio que acabas de bifurcar.

      5. En base, selecciona prod de tu repositorio base. Para comparar, selecciona dev.

        Compara los cambios.

      6. Haz clic en Crear solicitud de extracción.

      7. En título, escribe un título como Promoting networking changes y, a continuación, haz clic en Crear solicitud de extracción.

      8. Revisa los cambios propuestos, incluidos los terraform plan detalles de Cloud Build, y haz clic en Combinar solicitud de extracción.

      9. Haz clic en Confirmar combinación.

      10. En la Google Cloud consola, abre la página Historial de compilaciones para ver cómo se aplican los cambios al entorno de producción:

        Ir a la página Cloud Build

      11. Espera a que finalice la compilación y, a continuación, consulta los registros.

        Al final de los registros, verás algo parecido a 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

        El aprovisionamiento puede tardar unos segundos en arrancar la VM y en propagar la regla de firewall. Finalmente, verás Environment: prod en el navegador web.

      13. Ve al archivo de estado de Terraform en tu segmento de Cloud Storage.

        https://storage.cloud.google.com/PROJECT_ID-tfstate/env/prod/default.tfstate

      Has configurado correctamente una canalización de infraestructura como código sin servidor en Cloud Build. En el futuro, puedes probar lo siguiente:

      • Añade implementaciones para casos prácticos independientes.
      • Crea entornos adicionales para reflejar tus necesidades.
      • Usa un proyecto por entorno en lugar de una VPC por entorno.

      Limpieza

      Cuando hayas terminado el tutorial, elimina los recursos que has creado enGoogle Cloud para que no se te facturen en el futuro.

      Eliminar el proyecto

      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.

      Eliminar el repositorio de GitHub

      Para evitar que se bloqueen nuevas solicitudes de extracción en tu repositorio de GitHub, puedes eliminar tus reglas de protección de ramas:

      1. En GitHub, ve a la página principal del repositorio bifurcado.
      2. Debajo del nombre del repositorio, haz clic en Settings (Configuración).
      3. En el menú de la izquierda, haga clic en Sucursales.
      4. En la sección Reglas de protección de ramas, haz clic en el botón Eliminar de las filas dev y prod.

      Si quieres, puedes desinstalar por completo la aplicación Cloud Build de GitHub:

      1. Ve a la configuración de Aplicaciones de GitHub.

        Ve a la página de aplicaciones de GitHub.

      2. En la pestaña Aplicaciones de GitHub instaladas, haz clic en Configurar en la fila Cloud Build. A continuación, en la sección Zona de peligro, haga clic en el botón Desinstalar de la fila Desinstalar Google Cloud Builder.

        En la parte superior de la página, verás el mensaje "Todo listo. Se ha puesto en cola una tarea para desinstalar Google Cloud Build."

      3. En la pestaña Aplicaciones de GitHub autorizadas, haz clic en el botón Revocar de la fila Google Cloud Build y, a continuación, en Entiendo, revocar acceso en la ventana emergente.

      Si no quieres conservar tu repositorio de GitHub, sigue estos pasos:

      1. En GitHub, ve a la página principal del repositorio bifurcado.
      2. Debajo del nombre del repositorio, haz clic en Settings (Configuración).
      3. Desplázate hacia abajo hasta la sección Zona de peligro.
      4. Haz clic en Eliminar este repositorio y sigue los pasos de confirmación.

      Siguientes pasos