CI/CD moderna con GKE: compila un sistema de CI/CD

En esta arquitectura de referencia te proporciona un método y una infraestructura inicial para compilar un sistema moderno de integración continua/entrega continua (CI/CD) al usar herramientas comoGoogle Kubernetes Engine,Cloud Build,Skaffold,kustomize,Sincronizador de configuración,Policy Controller,Artifact Registry yCloud Deploy.

Este documento forma parte de una serie:

Este documento está dirigido a arquitectos empresariales y desarrolladores de aplicaciones, así como a los equipos de ingeniería de confiabilidad de sitios, DevOps y seguridad de TI. Es útil tener experiencia en herramientas y procesos de implementación automatizados para comprender los conceptos de este documento.

Flujo de trabajo de CI/CD

Para crear un sistema moderno de CI/CD, primero debes elegir las herramientas y los servicios que realizan las funciones principales del sistema. Esta arquitectura de referencia se centra en la implementación de las funciones principales de un sistema de CI/CD que se muestran en el siguiente diagrama:

Varios equipos administran o comparten la responsabilidad del sistema de CI/CD.

En esta implementación de referencia, se usan las siguientes herramientas para cada componente:

  • Para la administración del código fuente: GitHub
    • Almacena la aplicación y el código de configuración.
    • Te permite revisar los cambios.
  • Para la administración de configuración de la aplicación: kustomize
    • Define la configuración deseada de una aplicación.
    • Te permite reutilizar y extender planes básicos de configuración o planos.
  • Para la integración continua: Cloud Build
    • Prueba y valida el código fuente.
    • Compila artefactos que consume el entorno de implementación.
  • Para la entrega continua: Cloud Deploy
    • Define el proceso de lanzamiento del código en los entornos.
    • Proporciona una reversión para cambios con errores.
  • Para la configuración de la infraestructura: Sincronizador de configuración
    • Aplica la configuración del clúster y de las política de forma coherente.
  • Para la aplicación de políticas: Policy controller
    • Proporciona un mecanismo que puedes usar para definir lo que puede ejecutarse en un entorno determinado según las políticas de la organización.
  • Para la organización de contenedores: Google Kubernetes Engine
    • Ejecuta los artefactos que se compilan durante la CI.
    • Proporciona metodologías de escalamiento, verificación de estado y lanzamiento para cargas de trabajo.
  • Para artefactos de contenedores: Artifact Registry
    • Almacena los artefactos (imágenes de contenedor) que se compilan durante la CI.

Arquitectura

En esta sección, se describen los componentes de CI/CD que implementas mediante esta arquitectura de referencia: infraestructura, canalizaciones, repositorios de código y zonas de destino.

Para ver un análisis general de estos aspectos del sistema de CI/CD, consulta CI/CD modernas con GKE: un framework de entrega de software.

Variantes de arquitectura de referencia

La arquitectura de referencia tiene dos modelos de implementación:

  • Una variante de varios proyectos que se parece más a una implementación de producción con límites de aislamiento mejorados
  • Una variante de un solo proyecto, que es útil para demostraciones

Arquitectura de referencia de varios proyectos

La versión multi-project de la arquitectura de referencia simula situaciones similares a la de producción. En estas situaciones, diferentes arquetipos crean infraestructura, canalizaciones de CI/CD y aplicaciones con límites de aislamiento adecuados. Estos arquetivos o equipos solo pueden acceder a los recursos requeridos.

Para obtener más información, consulta CI/CD modernas con GKE: un framework de entrega de software.

Para obtener detalles sobre cómo instalar y aplicar esta versión de la arquitectura de referencia, consulta el plano de entrega de software.

Arquitectura de referencia de un solo proyecto

La versión single-project de la arquitectura de referencia muestra cómo configurar toda la plataforma de entrega de software en un solo proyecto de Google Cloud. Esta versión puede ayudar a cualquier usuario que no tenga roles de IAM elevados a instalar y probar la arquitectura de referencia solo con el rol de propietario en un proyecto. En este documento, se muestra la versión de un solo proyecto de la arquitectura de referencia.

Infraestructura de la plataforma

La infraestructura para esta arquitectura de referencia consta de clústeres de Kubernetes que admiten entornos de aplicaciones de desarrollo, etapa de pruebas y producción. En el siguiente diagrama, se muestra el diseño lógico de los clústeres:

El diseño del clúster admite diferentes cargas de trabajo de la plataforma.

Repositorios de código

Con esta arquitectura de referencia, configurarás repositorios para operadores, ingenieros de seguridad y desarrolladores.

En el siguiente diagrama, se muestra la implementación de la arquitectura de referencia de los distintos repositorios de código y cómo los equipos de operaciones, desarrollo y seguridad interactúan con los repositorios:

Los repositorios incluyen aquellos para prácticas recomendadas y configuración de aplicaciones y plataformas.

En este flujo de trabajo, tus operadores pueden administrar las prácticas recomendadas para CI/CD y la configuración de aplicaciones en el repositorio de operador. Cuando los desarrolladores incorporan aplicaciones en el repositorio de desarrollo, obtendrán automáticamente las prácticas recomendadas, la lógica empresarial de la aplicación y cualquier configuración especializada necesaria para que la aplicación funcione correctamente. Mientras tanto, tus operaciones y equipos de seguridad pueden administrar la coherencia y la seguridad de la plataforma en los repositorios de configuración y políticas.

Zonas de destino de las aplicaciones

En esta arquitectura de referencia, la zona de destino de una aplicación se crea cuando se aprovisiona la aplicación. En el siguiente documento de esta serie, CI/CD moderna con GKE: aplica el flujo de trabajo de los desarrolladores, aprovisionarás una aplicación nueva que crea su propia zona de destino. En el siguiente diagrama, se ilustran los componentes importantes de las zonas de destino usadas en esta arquitectura de referencia:

El clúster de GKE incluye tres espacios de nombres para diferentes aplicaciones.

Cada espacio de nombres incluye una cuenta de servicio que se usa para la federación de identidades para cargas de trabajo para GKE para acceder a los servicios fuera del contenedor de Kubernetes, como Cloud Storage o Spanner. El espacio de nombres también incluye otros recursos, como políticas de red, para aislar o compartir límites con otros espacios de nombres o aplicaciones.

El espacio de nombres se crea mediante la cuenta de servicio de ejecución de CD. Recomendamos que los equipos sigan el principio de privilegio mínimo para garantizar que una cuenta de servicio de ejecución de CD solo pueda acceder a los espacios de nombres requeridos.

Puedes definir el acceso a la cuenta de servicio en Sincronizador de configuración e implementarlo con las funciones de control de acceso basadas en roles (RBAC) y vinculaciones de roles de Kubernetes. Con este modelo en su lugar, los equipos pueden implementar cualquier recurso directamente en los espacios de nombres que administran, pero se les impide reemplazar o borrar recursos de otros espacios de nombres.

Objetivos

  • Implementar la arquitectura de referencia de un solo proyecto
  • Explorar los repositorios de código.
  • Explorar la canalización y la infraestructura.

Costos

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

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios. Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

Cuando finalices las tareas que se describen en este documento, puedes borrar los recursos que creaste para evitar que continúe la facturación. Para obtener más información, consulta Cómo realizar una limpieza.

Antes de comenzar

  1. En la página del selector de proyectos de la consola de Google Cloud, selecciona o crea un proyecto de Google Cloud.

    Ir al selector de proyectos

  2. Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

  3. En la consola de Google Cloud, activa Cloud Shell.

    Activar Cloud Shell

Implementa la arquitectura de referencia

  1. En Cloud Shell, configura el proyecto:

    gcloud config set core/project PROJECT_ID

    Reemplaza PROJECT_ID por el ID del proyecto de Google Cloud.

  2. En Cloud Shell, clona el repositorio de GitHub.

    git clone https://github.com/GoogleCloudPlatform/software-delivery-blueprint.git
cd software-delivery-blueprint/launch-scripts
git checkout single-project-blueprint

  3. Crea un token de acceso personal en GitHub con los siguientes alcances:

    • repo
    • delete_repo
    • admin:org
    • admin:repo_hook

  4. Hay un archivo vacío llamado vars.sh en la carpeta software-delivery-bluprint/launch-scripts. Agrega el siguiente contenido al archivo: 

    cat << EOF >vars.sh
export INFRA_SETUP_REPO="gke-infrastructure-repo"
export APP_SETUP_REPO="application-factory-repo"
export GITHUB_USER=GITHUB_USER
export TOKEN=TOKEN
export GITHUB_ORG=GITHUB_ORG
export REGION="us-central1"
export SEC_REGION="us-west1"
export TRIGGER_TYPE="webhook"
EOF

    Reemplaza GITHUB_USER por el nombre de usuario de GitHub.

    Reemplaza TOKEN por el token de acceso personal de GitHub.

    Reemplaza GITHUB_ORG por el nombre de la organización de GitHub.

  5. Ejecuta la secuencia de comandos bootstrap.sh: Si Cloud Shell te solicita autorización, haz clic en Autorizar:

    ./bootstrap.sh

    La secuencia de comandos inicia la plataforma de entrega de software.

Explora los repositorios de código

En esta sección, explorarás los repositorios de código.

Accede a GitHub

  1. En un navegador web, ve a github.com y accede a tu cuenta.
  2. Haz clic en el ícono de imagen en la parte superior de la interfaz.
  3. Haz clic en Tus organizaciones.
  4. Elige la organización que proporcionaste como entrada en el archivo vars.sh.
  5. Haz clic en la pestaña Repositorios.

Explora los repositorios de inicio, operador, infraestructura y configuración

Los repositorios de inicio, de operador, de configuración y de infraestructura son el lugar en el que los operadores y los administradores de plataformas definen las prácticas recomendadas comunes para compilar y operar la plataforma. Estos repositorios se crean en tu organización de GitHub cuando se inicia la arquitectura de referencia.

Cada repositorio de la lista incluye una descripción breve.

Repositorios iniciales

Los repositorios de inicio ayudan a adoptar la CI/CD, la infraestructura y las prácticas recomendadas de desarrollo en toda la plataforma. Para obtener más información, consulta CI/CD moderna con GKE: un framework de entrega de software.

Repositorios iniciales de aplicaciones

En los repositorios iniciales de la aplicación, tus operadores pueden codificar y documentar las prácticas recomendadas, como CI/CD, recopilación de métricas, registro, pasos de contenedor y seguridad para las aplicaciones. En la arquitectura de referencia, se incluyen ejemplos de repositorios de inicio para aplicaciones de Go, Python y Java.

Los repositorios iniciales de aplicación app-template-python, app-template-java y app-template-golang contienen el código estándar que puedes usar para crear aplicaciones nuevas. Además de crear aplicaciones nuevas, puede crear plantillas nuevas en función de los requisitos de las aplicaciones. Los repositorios de inicio de la aplicación que proporciona la arquitectura de referencia contienen lo siguiente:

  • Base y parches de kustomize en la carpeta k8s

  • Código fuente de la aplicación.

  • Un Dockerfile que describe cómo compilar y ejecutar la aplicación

  • Un archivo cloudbuild.yaml que describe las prácticas recomendadas para los pasos de CI.

  • Un archivo skaffold.yaml que describe los pasos de implementación.

En el siguiente documento de esta serie, CI/CD moderna con GKE: aplica el flujo de trabajo de los desarrolladores, debes usar el repositorio app-template-python para crear una aplicación nueva.

Repositorios iniciales de la infraestructura

En los repositorios iniciales de la infraestructura, tus operadores y administradores de infraestructura pueden codificar y documentar las prácticas recomendadas, como las canalizaciones de CI/CD, IaC, la recopilación de métricas, el registro y la seguridad para la infraestructura. En la arquitectura de referencia, se incluyen ejemplos de repositorios de inicio de infraestructura con Terraform. El repositorio de inicio de la infraestructura infra-template contiene código estándar para Terraform que puedes usar para crear los recursos de infraestructura que requiere una aplicación, como el bucket de Cloud Storage o la base de datos de Spanner, entre otros.

Repositorios de plantillas compartidas

En los repositorios de plantillas compartidas, los administradores y operadores de infraestructura proporcionan plantillas estándar para realizar tareas. Hay un repositorio llamado terraform-modules que se proporciona con la arquitectura de referencia. El repositorio incluye código de Terraform con plantilla para crear varios recursos de infraestructura.

Repositorios de operadores

En la arquitectura de referencia, los repositorios de operador son los mismos que los repositorios de inicio de la aplicación. Los operadores administran los archivos necesarios para la CI y la CD en los repositorios de inicio de la aplicación. La arquitectura de referencia incluye los repositorios app-template-python, app-template-java y app-template-golang.

  • Estas son plantillas de inicio y contienen los manifiestos básicos de Kubernetes para las aplicaciones que se ejecutan en Kubernetes en la plataforma. Los operadores pueden actualizar los manifiestos en las plantillas de inicio según sea necesario. Las actualizaciones se detectan cuando se crea una aplicación.
  • Los archivos cloudbuild.yaml y skaffold.yaml de estos repositorios almacenan las prácticas recomendadas para ejecutar CI y CD, respectivamente, en la plataforma. Al igual que las configuraciones de la aplicación, los operadores pueden actualizar y agregar pasos a las prácticas recomendadas. Las canalizaciones de aplicaciones individuales se crean con los pasos más recientes.

En esta implementación de referencia, los operadores usan kustomize para administrar las configuraciones base en la carpeta k8s de los repositorios de inicio. Los desarrolladores tienen la libertad de extender los manifiestos con cambios específicos de la aplicación, como los nombres de los recursos y los archivos de configuración. La herramienta kustomize admite la configuración como datos. Con esta metodología, las entradas y salidas de kustomize son recursos de Kubernetes. Puedes usar los resultados de una modificación de los manifiestos para otra modificación.

En el siguiente diagrama, se ilustra una configuración base para una aplicación de Spring Boot:

La configuración de la aplicación se realiza en varios repositorios administrados por equipos separados.

La configuración como modelo de datos en kustomize tiene un beneficio importante: cuando los operadores actualizan la configuración base, las canalizaciones la implementan de forma automática en la próxima ejecución sin ningún cambio en la del desarrollador.

Si quieres obtener más información sobre el uso de kustomize para administrar los manifiestos de Kubernetes, consulta la documentación de kustomize.

Repositorios de configuración y políticas

En la arquitectura de referencia, se incluye una implementación de un repositorio de configuraciones y políticas que usa el Sincronizador de configuración y Policy Controller. El repositorio acm-gke-infrastructure-repo contiene la configuración y las políticas que implementas en los clústeres del entorno de aplicaciones. La configuración definida y almacenada por los administradores de plataformas en estos repositorios es importante a fin de garantizar que la plataforma tenga una apariencia coherente para los equipos de operaciones y desarrollo.

En las siguientes secciones, se analiza la forma en que la arquitectura de referencia implementa la configuración y los repositorios de políticas con más detalle.

Configuración

En esta implementación de referencia, debes usar el Sincronizador de configuración para administrar de forma centralizada la configuración de clústeres en la plataforma y aplicar políticas. La administración centralizada te permite propagar cambios de configuración en todo el sistema.

Con el Sincronizador de configuración, tu organización puede registrar sus clústeres para sincronizar su configuración desde un repositorio de Git, un proceso conocido como GitOps. Cuando agregas clústeres nuevos, estos se sincronizan automáticamente con la configuración más reciente y concilian de forma continua el estado del clúster con la configuración en caso de que alguien ingrese cambios fuera de banda.

Para obtener más información sobre el Sincronizador de configuración, consulta su documentación.

Política

En esta implementación de referencia, debes usar el Policy Controller, el cual se basa en Open Policy Agent para interceptar y validar cada solicitud a los clústeres de Kubernetes en la plataforma. Puedes crear políticas con el lenguaje de política de Rego, que te permite controlar los tipos de recursos enviados al clúster y su configuración.

La arquitectura en el siguiente diagrama muestra un flujo de solicitudes para usar Policy Controller a fin de crear un recurso:

Primero, se define una regla de política y, luego, se aplica mediante varias herramientas, como kubectl y clientes de API.

Para que estos cambios se apliquen al clúster, debes crear y definir reglas en el repositorio del Sincronizador de configuración. Después de esto, las solicitudes de recursos nuevos de la CLI o de los clientes de API se validan según las restricciones de Policy Controller.

Para obtener más información sobre la administración de políticas, consulta la Descripción general de Policy Controller.

Repositorios de infraestructura

En la referencia, se incluye una implementación del repositorio de infraestructura realizada con Terraform. El repositorio gke-infrastructure-repo contiene infraestructura como código para crear clústeres de GKE para entornos de desarrollo, etapas de pruebas y entornos de producción con el fin de configurar el Sincronizador de configuración en ellos al usar el repositorio acm-gke-infrastructure-repo. gke-infrastructure-repo contiene tres ramas, una para cada entorno de desarrollo y de producción así como la etapa de pruebas. También contiene carpetas de desarrollo, etapa de pruebas y producción en cada rama.

Explora la canalización y la infraestructura

La arquitectura de referencia crea una canalización en el proyecto de Google Cloud. Esta canalización es responsable de crear la infraestructura compartida.

Canalización

En esta sección, explorarás la canalización de infraestructura como código y la ejecutarás para crear la infraestructura compartida, incluidos los clústeres de GKE. La canalización es un activador de Cloud Build llamado create-infra en el proyecto de Google Cloud que está vinculado al repositorio de infraestructura gke-infrastructure-repo. Debes seguir la metodología de GitOps para crear infraestructura como se explica en el video de canalizaciones de infraestructura como código de GCP repetibles a gran escala.

gke-infrastructure-repo tiene ramas de desarrollo, etapa de pruebas y producción. En el repositorio, también hay carpetas de desarrollo, etapa de pruebas y producción que corresponden a estas ramas. Hay reglas de protección de ramas en el repositorio que garantizan que el código solo se pueda enviar a la rama de desarrollo. Para enviar el código a las ramas de etapa de pruebas y producción, debes crear una solicitud de extracción.

Por lo general, alguien que tiene acceso al repositorio revisa los cambios y, luego, combina la solicitud de extracción para asegurarse de que solo los cambios previstos se promuevan a la rama superior. Para permitir que las personas prueben el plano, se disminuyen la rigurosidad de las reglas de protección de ramas en la arquitectura de referencia para que el administrador del repositorio pueda omitir la revisión y combinar la solicitud de extracción.

Cuando se realiza un envío a gke-infrastructure-repo, se invoca el activador create-infra. Ese activador identifica la rama en la que se produjo el envío y va a la carpeta correspondiente en el repositorio de esa rama. Una vez que encuentra la carpeta correspondiente, ejecuta Terraform con los archivos que contiene. Por ejemplo, si el código se envía a la rama dev, el activador ejecuta Terraform en la carpeta de desarrollo de la rama dev para crear un clúster de GKE de desarrollo. Del mismo modo, cuando se realiza un envío a la rama staging, el activador ejecuta Terraform en la carpeta de etapa de pruebas de la rama de etapa de pruebas para crear un clúster de GKE de etapa de pruebas.

Ejecuta la canalización para crear clústeres de GKE:

  1. En la consola de Google Cloud, ve a la página Cloud Build.

    Ir a la página Cloud Build

    • Hay cinco activadores de webhook de Cloud Build. Busca el activador con el nombre create-infra. Este activador crea la infraestructura compartida, incluidos los clústeres de GKE.

  2. Haz clic en el nombre del activador. Se abrirá la definición del activador.

  3. Haz clic en ABRIR EDITOR para ver los pasos que ejecuta el activador.

    Los otros activadores se usan cuando incorporas una aplicación en CI/CD modernas con GKE: Aplica el flujo de trabajo de los desarrolladores.

    Activadores de Cloud Build.

  4. En la consola de Google Cloud, ve a la página Cloud Build.

    Ir a la página del historial de Cloud Build

    Revisa la canalización presente en la página del historial. Cuando implementó la plataforma de entrega de software con bootstrap.sh, la secuencia de comandos envió el código a la rama dev del repositorio gke-infrastructure-repo que inició esta canalización y creó el clúster de desarrollo de GKE.

  5. Para crear un clúster de GKE de etapa de pruebas, envía una solicitud de extracción de la rama de desarrollo a la rama de etapa de pruebas:

    1. Ve a GitHub y navega hasta el repositorio gke-infrastructure-repo.

    2. Haz clic en Solicitudes de extracción y, luego, en Nueva solicitud de extracción.

    3. En el menú Base, selecciona etapa de pruebas y, en el menú Comparar, elige dev.

    4. Haz clic en Create pull request.

  6. Si eres administrador del repositorio, combina la solicitud de extracción. De lo contrario, pídele al administrador que combine la solicitud de extracción.

  7. En la consola de Google Cloud, ve a la página de historial de Cloud Build.

    Ir a la página del historial de Cloud Build

    Se iniciará una segunda canalización de Cloud Build en el proyecto. Esta canalización crea el clúster de GKE de etapa de pruebas.

  8. Para crear clústeres de producción de GKE, envía un pull request desde la etapa de pruebas a la rama de producción:

    1. Ve a GitHub y navega hasta el repositorio gke-infrastructure-repo.

    2. Haz clic en Solicitudes de extracción y, luego, en Nueva solicitud de extracción.

    3. En el menú Base, selecciona prod y, en el menú Comparar, elige etapa de pruebas.

    4. Haz clic en Create pull request.

  9. Si eres administrador del repositorio, combina la solicitud de extracción. De lo contrario, pídele al administrador que combine la solicitud de extracción.

  10. En la consola de Google Cloud, ve a la página de historial de Cloud Build.

    Ir a la página del historial de Cloud Build

    Una tercera canalización de Cloud Build comienza en el proyecto. Esta canalización crea el clúster de GKE de producción.

Infraestructura

En esta sección, explorarás la infraestructura que crearon las canalizaciones.

  • En la consola de Google Cloud, ve a la página Clústeres de Kubernetes.

    Ir a la página Clústeres de Kubernetes

    En esta página, se enumeran los clústeres que se usan para desarrollo (gke-dev-us-central1), etapa de pruebas (gke-staging-us-central1) y producción ( gke-prod-us-central1, gke-prod-us-west1):

    Los detalles de los clústeres incluyen la ubicación, el tamaño del clúster y los núcleos totales.

Clúster de desarrollo

El clúster de desarrollo (gke-dev-us-central1) les brinda a tus desarrolladores acceso a un espacio de nombres que pueden usar para iterar en sus aplicaciones. Recomendamos que los equipos usen herramientas como Skaffold que proporcionan un flujo de trabajo iterativo mediante la supervisión activa del código en desarrollo y lo vuelven a aplicar a los entornos de desarrollo a medida que se realizan cambios. Este bucle de iteración es similar a la carga en caliente. Sin embargo, en lugar de ser específico de un lenguaje de programación, el bucle funciona con cualquier aplicación que puedas compilar con una imagen de Docker. Puedes ejecutar el bucle dentro de un clúster de Kubernetes.

Como alternativa, los desarrolladores pueden seguir el bucle de CI/CD para un entorno de desarrollo. Con ese bucle, los cambios de código estarán listos para ascender a entornos más altos.

En el siguiente documento de esta serie, CI/CD moderna con GKE: aplica el flujo de trabajo de los desarrolladores, debes usar Skaffold y CI/CD para crear el bucle de desarrollo.

Clúster de etapas de pruebas

Este clúster ejecuta el entorno de etapa de pruebas de tus aplicaciones. En esta arquitectura de referencia, crearás un clúster de GKE para la etapa de pruebas. Por lo general, un entorno de etapa de pruebas es una réplica exacta del entorno de producción.

Clúster de producción

En la arquitectura de referencia, tienes dos clústeres de GKE para los entornos de producción. Te recomendamos que agregues varios clústeres a cada entorno en los sistemas de redundancia geográfica o alta disponibilidad (HA). Es ideal usar clústeres regionales en todos los clústeres en los que se implementan las aplicaciones. En este enfoque, se aíslan tus aplicaciones de las fallas a nivel de zona y cualquier interrupción causada por las actualizaciones de clúster o grupo de nodos.

Para sincronizar la configuración de los recursos del clúster, como los espacios de nombres, las cuotas y el RBAC, te recomendamos que uses el Sincronizador de configuración. Para obtener más información para aprender a administrar esos recursos, consulta Repositorios de configuración y políticas.

Aplica la arquitectura de referencia

Ahora que exploraste la arquitectura de referencia, puedes explorar un flujo de trabajo de desarrollador basado en esta implementación. En el siguiente documento de esta serie, CI/CD moderna con GKE: aplica el flujo de trabajo de los desarrolladores, crearás una aplicación nueva, agregarás una función y, luego, implementarás la de la aplicación a los entornos de etapa de pruebas y producción.

Limpia

Si deseas probar el siguiente documento de esta serie, CI/CD moderna con GKE: aplica el flujo de trabajo de los desarrolladores, no borres el proyecto ni los recursos asociados con esta arquitectura de referencia. De lo contrario, para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos que usaste en la arquitectura de referencia, puedes borrar el proyecto o quitar los recursos de forma manual.

Borra el proyecto

  1. En la consola de Google Cloud, ve a la página Administrar recursos.

    Ir a Administrar recursos

  2. En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
  3. En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

Quita los recursos de forma manual

  • En Cloud Shell, quita la infraestructura:

      gcloud container clusters delete gke-dev-us-central1
  gcloud container clusters delete gke-staging-us-central1
  gcloud container clusters delete gke-prod-us-central1
  gcloud container clusters delete gke-prod-us-west1
  gcloud beta builds triggers delete create-infra
  gcloud beta builds triggers delete add-team-files
  gcloud beta builds triggers delete create-app
  gcloud beta builds triggers delete tf-plan
  gcloud beta builds triggers delete tf-apply

¿Qué sigue?