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:
- CI/CD moderna con GKE: un marco de trabajo de entrega de software
- CI/CD moderna con GKE: compila un sistema de CI/CD (este documento)
- CI/CD moderna con GKE: aplica el flujo de trabajo de los desarrolladores
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:
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 contenedor: 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 la 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 las demostraciones
Arquitectura de referencia de varios proyectos
La versión multi-project
de la arquitectura de referencia simula situaciones similares a la 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 moderna 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
En la versión single-project
de la arquitectura de referencia, se 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:
Repositorios de código
Con esta arquitectura de referencia, configurarás repositorios para ingenieros de seguridad, operadores, desarrolladores y plataformas.
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:
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:
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.
La cuenta de servicio de ejecución de CD crea el espacio de nombres. 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:
- Google Kubernetes Engine (GKE)
- Google Kubernetes Engine (GKE) Enterprise edition for Config Sync and Policy Controller
- Cloud Build
- Artifact Registry
- Cloud Deploy
Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.
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
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.
-
In the Google Cloud console, activate Cloud Shell.
Implementa la arquitectura de referencia
En Cloud Shell, configura el proyecto:
gcloud config set core/project PROJECT_ID
Reemplaza
PROJECT_ID
por el ID del proyecto de Google Cloud.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
Crea un token de acceso personal en GitHub con los siguientes permisos:
repo
delete_repo
admin:org
admin:repo_hook
Hay un archivo vacío llamado
vars.sh
en la carpetasoftware-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.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
- En un navegador web, ve a github.com y accede a tu cuenta.
- Haz clic en el ícono de foto en la parte superior de la interfaz.
- Haz clic en Tus organizaciones.
- Elige la organización que proporcionaste como entrada en el archivo
vars.sh
. - Haz clic en la pestaña Repositorios.
Explora los repositorios de inicio, operador, configuración e infraestructura
Los repositorios de inicio, operador, configuración e 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.
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 las aplicaciones
En los repositorios iniciales de la aplicación, tus operadores pueden codificar y documentar las prácticas recomendadas, como la CI/CD, la recopilación de métricas, el registro, los pasos del contenedor y la 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, puedes crear plantillas nuevas según 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 carpetak8s
Código fuente de la aplicación.
Un
Dockerfile
que describe cómo compilar y ejecutar la aplicaciónUn archivo
cloudbuild.yaml
que describe las prácticas recomendadas para los pasos de la CI.Un archivo
skaffold.yaml
que describa 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 de inicio de la infraestructura
En los repositorios iniciales de infraestructura, tus operadores y administradores de infraestructura pueden codificar y documentar las prácticas recomendadas, como las canalizaciones de CI/CD, la 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
proporcionado 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 del 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
yskaffold.yaml
de estos repositorios almacenan las prácticas recomendadas para ejecutar la 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 iniciales.
Los desarrolladores tienen la libertad de extender los manifiestos con cambios específicos de la aplicación, como nombres de recursos y 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 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:
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 se encarga 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 Entornos de GCP repetibles a gran escala con canalizaciones de infraestructura como código de Cloud Build.
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 ocurrió 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 de desarrollo, el activador ejecuta Terraform en la carpeta de desarrollo de la rama de desarrollo para crear un clúster de GKE de desarrollo. De manera similar, cuando un envío ocurre 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:
En la consola de Google Cloud, ve 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.
- Hay cinco activadores de webhook de Cloud Build. Busca el activador con el nombre
Haz clic en el nombre del activador. Se abrirá la definición del activador.
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
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 implementaste la plataforma de entrega de software con
bootstrap.sh
, la secuencia de comandos envió el código a la rama de desarrollo del repositoriogke-infrastructure-repo
que inició esta canalización y creó el clúster de GKE de desarrollo.Para crear un clúster de GKE de etapa de pruebas, envía una solicitud de extracción desde la rama de desarrollo a la rama de etapa de pruebas:
Ve a GitHub y navega hasta el repositorio
gke-infrastructure-repo
.Haz clic en Solicitudes de extracción y, luego, en Nueva solicitud de extracción.
En el menú Base, selecciona etapa de pruebas y, en el menú Comparar, selecciona dev.
Haz clic en Create pull request.
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.
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.
Para crear clústeres de GKE de producción, envía un
pull request
de la etapa de pruebas a la rama de producción:Ve a GitHub y navega hasta el repositorio
gke-infrastructure-repo
.Haz clic en Solicitudes de extracción y, luego, en Nueva solicitud de extracción.
En el menú Base, selecciona prod y, en el menú Compare, selecciona etapa de pruebas.
Haz clic en Create pull request.
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.
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 el desarrollo (
gke-dev-us-central1
), la etapa de pruebas (gke-staging-us-central1
) y la producción (gke-prod-us-central1
,gke-prod-us-west1
):
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 del 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. Ese bucle hace que los cambios de código estén listos para el ascenso a entornos superiores.
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 etapa 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
- En la consola de Google Cloud, ve a la página Administrar recursos.
- En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
- 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?
- Para crear una nueva aplicación, sigue los pasos en CI/CD moderna con GKE: aplica el flujo de trabajo de los desarrolladores.
- Obtén más información sobre las prácticas recomendadas para configurar la federación de identidades.
Lee sobre Kubernetes y los desafíos de la implementación continua de software.
Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.