CI/CD modernas con GKE: crear un sistema de CI/CD

Estándar

---

Esta arquitectura de referencia te proporciona un método y una infraestructura inicial para crear un sistema de integración continua y entrega continua (CI/CD) moderno con herramientas como Google Kubernetes Engine, Cloud Build, Skaffold, kustomize, Config Sync, Policy Controller, Artifact Registry y Cloud Deploy.

Este documento forma parte de una serie:

• CI/CD modernas con GKE: un framework de distribución de software
• CI/CD modernas con GKE: crear un sistema de CI/CD (este documento)
• CI/CD modernas con GKE: aplicar el flujo de trabajo de desarrollo

Este documento está dirigido a arquitectos empresariales y desarrolladores de aplicaciones, así como a equipos de seguridad de TI, DevOps y Site Reliability Engineering. Es útil tener cierta experiencia con las herramientas y los procesos de implementación automatizada para entender los conceptos de este documento.

Flujo de trabajo de CI/CD

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

Esta implementación de referencia usa las siguientes herramientas para cada componente:

• Para la gestión del código fuente: GitHub
  • Almacena el código de la aplicación y de la configuración.
  • Te permite revisar los cambios.
• Para gestionar la configuración de las aplicaciones: kustomize
  • Define la configuración prevista de una aplicación.
  • Te permite reutilizar y ampliar primitivas o plantillas de configuración.
• Para la integración continua: Cloud Build
  • Prueba y valida el código fuente.
  • Crea artefactos que consume el entorno de implementación.
• Para la entrega continua: Cloud Deploy
  • Define el proceso de lanzamiento de código en los entornos.
  • Proporciona una reversión de los cambios fallidos.
• Para la configuración de la infraestructura: Config Sync
  • Aplica de forma coherente la configuración del clúster y de las políticas.
• Para aplicar las políticas: Policy Controller
  • Proporciona un mecanismo que puedes usar para definir lo que se puede ejecutar en un entorno determinado en función de las políticas de la organización.
• Para la orquestación de contenedores: Google Kubernetes Engine
  • Ejecuta los artefactos que se compilan durante la integración continua.
  • Proporciona metodologías de escalado, comprobación del estado y lanzamiento para cargas de trabajo.
• En el caso de los artefactos de contenedor, Artifact Registry
  • Almacena los artefactos (imágenes de contenedor) que se crean durante la integración continua.

Arquitectura

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

Para obtener información general sobre estos aspectos del sistema de CI/CD, consulta el artículo CI/CD modernas con GKE: un framework de distribución 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 demostraciones

Nota: Los diagramas de este documento se basan en la arquitectura de referencia de varios proyectos. Se aplican a arquitecturas de referencia de un solo proyecto. La excepción es que todos los Google Cloud recursos se crean en un solo Google Cloud proyecto en la arquitectura de un solo proyecto.

Arquitectura de referencia de varios proyectos

La versión multi-project de la arquitectura de referencia simula escenarios similares a los de producción. En estos casos, diferentes perfiles crean infraestructuras, flujos de procesamiento de CI/CD y aplicaciones con límites de aislamiento adecuados. Estas buyer personas o equipos solo pueden acceder a los recursos necesarios.

Para obtener más información, consulta el artículo CI/CD modernas con GKE: un framework de distribución de software.

Para obtener información sobre cómo instalar y aplicar esta versión de la arquitectura de referencia, consulta el plan 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 distribución de software en un solo Google Cloud proyecto. Esta versión puede ayudar a los usuarios que no tengan roles de gestión de identidades y accesos con privilegios elevados a instalar y probar la arquitectura de referencia con solo 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 de esta arquitectura de referencia consta de clústeres de Kubernetes para admitir entornos de desarrollo, de preproducción y de producción de aplicaciones. En el siguiente diagrama se muestra el diseño lógico de los clústeres:

Repositorios de código

Con esta arquitectura de referencia, puedes configurar repositorios para operadores, desarrolladores, ingenieros de plataformas y de seguridad.

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

En este flujo de trabajo, tus operadores pueden gestionar las prácticas recomendadas de CI/CD y la configuración de aplicaciones en el repositorio de operadores. Cuando tus desarrolladores incorporan aplicaciones al repositorio de desarrollo, obtienen 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, tu equipo de operaciones y seguridad puede gestionar la coherencia y la seguridad de la plataforma en los repositorios de configuración y de políticas.

Zonas de aterrizaje de aplicaciones

En esta arquitectura de referencia, la zona de aterrizaje de una aplicación se crea cuando se aprovisiona la aplicación. En el siguiente documento de esta serie, CI/CD modernas con GKE: aplicar el flujo de trabajo de desarrollo, se aprovisiona una nueva aplicación que crea su propia zona de aterrizaje. En el siguiente diagrama se muestran los componentes importantes de las zonas de aterrizaje que se usan en esta arquitectura de referencia:

Cada espacio de nombres incluye una cuenta de servicio que se usa para la federación de identidades de carga de trabajo de GKE para acceder a 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 lo crea la cuenta de servicio de ejecución de CD. Recomendamos que los equipos sigan el principio de mínimos accesos para asegurarse de que una cuenta de servicio de ejecución de CD solo pueda acceder a los espacios de nombres necesarios.

Puedes definir el acceso de las cuentas de servicio en Config Sync e implementarlo mediante roles y vinculaciones de roles de control de acceso basado en roles (RBAC) de Kubernetes. Con este modelo, los equipos pueden desplegar recursos directamente en los espacios de nombres que gestionan, pero no pueden sobrescribir ni eliminar recursos de otros espacios de nombres.

Objetivos

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

Costes

En este documento, se utilizan 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 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.

Antes de empezar

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

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

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

   Activate Cloud Shell

   Implementar la arquitectura de referencia

   1. En Cloud Shell, define el proyecto:

      gcloud config set core/project PROJECT_ID

      Sustituye PROJECT_ID por el ID de tu proyecto. Google Cloud

   2. En Cloud Shell, clona el repositorio de Git:

      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 permisos:

      • 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. Añade 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

      Sustituye GITHUB_USER por el nombre de usuario de GitHub.

      Sustituye TOKEN por el token de acceso personal de GitHub.

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

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

      ./bootstrap.sh
      

      La secuencia de comandos inicia la plataforma de distribución de software.

   Consultar los repositorios de código

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

   Iniciar sesión en GitHub

   1. En un navegador web, ve a github.com e inicia sesión en tu cuenta.
   2. Haz clic en el icono de imagen situado en la parte superior de la interfaz.
   3. Haz clic en Tus organizaciones.
   4. Elige la organización que has indicado en el archivo vars.sh.
   5. Haz clic en la pestaña Repositorios.

   Explorar los repositorios de inicio, operador, configuración e infraestructura

   En los repositorios de inicio, operador, configuración e infraestructura, los operadores y los administradores de la plataforma definen las prácticas recomendadas comunes para desarrollar y operar la plataforma. Estos repositorios se crean en tu organización de GitHub cuando se inicia la arquitectura de referencia.

   

   Repositorios de inicio

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

   Repositorios de inicio de aplicaciones

   En los repositorios de inicio de aplicaciones, tus operadores pueden codificar y documentar las prácticas recomendadas, como CI/CD, la recogida de métricas, el registro, los pasos de los contenedores y la seguridad de las aplicaciones. La arquitectura de referencia incluye ejemplos de repositorios de inicio para aplicaciones de Go, Python y Java.

   Los repositorios de inicio de aplicaciones app-template-python, app-template-java y app-template-golang contienen código boilerplate que puedes usar para crear nuevas aplicaciones. Además de crear aplicaciones, puedes crear plantillas basadas en los requisitos de las aplicaciones. Los repositorios de inicio de aplicaciones que proporciona la arquitectura de referencia contienen lo siguiente:

   • kustomize base y parches 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 la implementación.

   En el siguiente documento de esta serie, CI/CD modernas con GKE: aplicar el flujo de trabajo de desarrollo, usarás el repositorio app-template-python para crear una aplicación.

   Repositorios de inicio de infraestructura

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

   Repositorios de plantillas compartidas

   En los repositorios de plantillas compartidos, los administradores y operadores de la 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 basado en plantillas para crear varios recursos de infraestructura.

   Repositorios de operadores

   En la arquitectura de referencia, los repositorios de operadores son los mismos que los repositorios de inicio de aplicaciones. Los operadores gestionan los archivos necesarios para la integración continua y la entrega continua 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.

   • Se trata de plantillas de inicio que contienen los manifiestos de Kubernetes básicos de las aplicaciones que se ejecutan en Kubernetes en la plataforma. Los operadores pueden actualizar los manifiestos de las plantillas iniciales según sea necesario. Las actualizaciones se recogen 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 con las configuraciones de aplicaciones, los operadores pueden actualizar y añadir 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 gestionar las configuraciones base en la carpeta k8s de los repositorios iniciales. Los desarrolladores pueden ampliar 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 muestra una configuración básica de una aplicación Spring Boot:

   

   El modelo de configuración como datos de kustomize tiene una gran ventaja: cuando los operadores actualizan la configuración base, el flujo de implementación del desarrollador consume automáticamente las actualizaciones en su próxima ejecución sin que el desarrollador tenga que hacer ningún cambio.

   Para obtener más información sobre cómo usar kustomize para gestionar manifiestos de Kubernetes, consulta la documentación de kustomize.

   Repositorios de configuración y políticas

   La arquitectura de referencia incluye una implementación de un repositorio de configuración y políticas que usa Config Sync 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 la aplicación. La configuración definida y almacenada por los administradores de la plataforma en estos repositorios es importante para asegurar que la plataforma tenga un aspecto coherente para los equipos de operaciones y desarrollo.

   En las siguientes secciones se explica con más detalle cómo implementa la arquitectura de referencia los repositorios de configuración y de políticas.

   Configuración

   En esta implementación de referencia, se usa Config Sync para gestionar de forma centralizada la configuración de los clústeres de la plataforma y aplicar las políticas. La gestión centralizada te permite propagar los cambios de configuración por todo el sistema.

   Con Config Sync, tu organización puede registrar sus clústeres para sincronizar su configuración desde un repositorio de Git, un proceso conocido como GitOps. Cuando añades clústeres, estos se sincronizan automáticamente con la configuración más reciente y reconcilian continuamente el estado del clúster con la configuración por si alguien introduce cambios fuera de banda.

   Para obtener más información sobre Config Sync, consulta su documentación.

   Política

   En esta implementación de referencia, se usa Policy Controller, que se basa en Open Policy Agent, para interceptar y validar cada solicitud a los clústeres de Kubernetes de la plataforma. Puedes crear políticas con el lenguaje de políticas Rego, que te permite controlar por completo no solo los tipos de recursos que se envían al clúster, sino también su configuración.

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

   

   Crea y define reglas en el repositorio de Config Sync, y estos cambios se aplican al clúster. Después, Policy Controller valida las nuevas solicitudes de recursos de los clientes de la CLI o de la API con respecto a las restricciones.

   Para obtener más información sobre la gestió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 con Terraform. El repositorio gke-infrastructure-repo contiene infraestructura como código para crear clústeres de GKE para entornos de desarrollo, de preproducción y de producción, así como para configurar Config Sync en ellos mediante el repositorio acm-gke-infrastructure-repo. gke-infrastructure-repo contiene tres ramas, una para cada entorno de desarrollo, staging y producción. También contiene carpetas de desarrollo, staging y producción en cada rama.

   Consultar la canalización y la infraestructura

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

   Flujo de procesamiento

   En esta sección, explorará la canalización de infraestructura como código y la ejecutará 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 Google Cloud que está vinculado al repositorio de infraestructura gke-infrastructure-repo. Sigues la metodología GitOps para crear infraestructura, tal como se explica en el vídeo sobre cómo crear entornos de GCP repetibles a gran escala con las canalizaciones de infraestructura como código de Cloud Build.

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

   Normalmente, alguien que tiene acceso al repositorio revisa los cambios y, a continuación, combina la solicitud de extracción para asegurarse de que solo se promuevan a la rama superior los cambios previstos. Para que los usuarios puedan probar el blueprint, se han flexibilizado las reglas de protección de la rama en la arquitectura de referencia, de modo que el administrador del repositorio pueda saltarse la revisión y combinar la solicitud de extracción.

   Cuando se hace una inserción en gke-infrastructure-repo, se invoca el activador create-infra. Este activador identifica la rama en la que se ha producido el envío y va a la carpeta correspondiente del 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. Del mismo modo, cuando se inserta contenido en la rama staging, el activador ejecuta Terraform en la carpeta de staging de la rama de staging para crear un clúster de GKE de staging.

   Ejecuta el flujo de procesamiento para crear clústeres de GKE:

   1. En la Google Cloud consola, 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. Haga 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 demás activadores se usan cuando incorporas una aplicación en CI/CD modernas con GKE: aplicar el flujo de trabajo de desarrollo.

      

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

      Ir a la página del historial de Cloud Build

      Revisa la canalización que aparece en la página del historial. Cuando desplegaste la plataforma de entrega de software con bootstrap.sh, la secuencia de comandos envió el código a la rama de desarrollo del repositorio gke-infrastructure-repo, lo que activó este flujo de procesamiento y creó el clúster de desarrollo de GKE.

      Nota: Si no ves ninguna canalización en la página del historial de Cloud Build, significa que el webhook de gke-infrastructure-repo no ha invocado el activador de Cloud Build. Esto es poco habitual, pero puede ocurrir si hay algún problema con las APIs de GitHub. Cuando se hayan resuelto los problemas, haz un commit en la rama de desarrollo del repositorio gke-infrastructure-repo y el webhook debería invocar el activador de Cloud Build. Ahora, deberías ver una canalización en la página del historial de Cloud Build. Esta canalización crea un clúster de GKE de desarrollo.

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

      1. Ve a GitHub y accede al repositorio gke-infrastructure-repo.

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

      3. En el menú Base, elige staging y, en el menú Comparar, elige dev.

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

   6. Si eres administrador del repositorio, combina la solicitud de obtención. Si no es así, pide al administrador que combine la solicitud de extracción.

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

      Ir a la página del historial de Cloud Build

      Se inicia una segunda canalización de Cloud Build en el proyecto. Esta canalización crea el clúster de GKE de staging.

   8. Para crear clústeres de GKE de producción, envía una pull request de la rama de staging a la de producción:

      1. Ve a GitHub y accede al repositorio gke-infrastructure-repo.

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

      3. En el menú Base, elige prod y, en el menú Comparar, elige staging.

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

   9. Si eres administrador del repositorio, combina la solicitud de obtención. Si no es así, pide al administrador que combine la solicitud de extracción.

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

       Ir a la página del historial de Cloud Build

       Se inicia una tercera canalización de Cloud Build en el proyecto. Esta canalización crea el clúster de GKE de producción.

   Infraestructura

   En esta sección, explorará la infraestructura que han creado las canalizaciones.

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

     Ve a la página Clústeres de Kubernetes.

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

     

   Clúster de desarrollo

   El clúster de desarrollo (gke-dev-us-central1) proporciona a tus desarrolladores acceso a un espacio de nombres que pueden usar para iterar en sus aplicaciones. Recomendamos que los equipos utilicen herramientas como Skaffold, que proporciona un flujo de trabajo iterativo monitorizando activamente el código en desarrollo y volviéndolo a aplicar a los entornos de desarrollo a medida que se realizan cambios. Este bucle de iteración es similar a la recarga activa. Sin embargo, en lugar de ser específico de un lenguaje de programación, el bucle funciona con cualquier aplicación que puedas crear con una imagen de Docker. Puedes ejecutar el bucle dentro de un clúster de Kubernetes.

   También pueden seguir el bucle de CI/CD para un entorno de desarrollo. Este bucle hace que los cambios de código estén listos para pasar a entornos superiores.

   En el siguiente documento de esta serie, CI/CD modernas con GKE: aplicar el flujo de trabajo de desarrollo, usarás Skaffold y CI/CD para crear el bucle de desarrollo.

   Clúster de staging

   Este clúster ejecuta el entorno de preproducción de tus aplicaciones. En esta arquitectura de referencia, se crea un clúster de GKE para la fase de pruebas. Normalmente, un entorno de staging 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 tus entornos de producción. En el caso de los sistemas con redundancia geográfica o alta disponibilidad, te recomendamos que añadas varios clústeres a cada entorno. En todos los clústeres en los que se implementan aplicaciones, lo ideal es usar clústeres regionales. De esta forma, tus aplicaciones no se verán afectadas por los fallos a nivel de zona ni por las interrupciones causadas por las actualizaciones de clústeres o grupos de nodos.

   Para sincronizar la configuración de los recursos del clúster, como los espacios de nombres, las cuotas y el control de acceso basado en roles, te recomendamos que uses Config Sync. Para obtener más información sobre cómo gestionar esos recursos, consulta Repositorios de configuración y de políticas.

   Aplicar la arquitectura de referencia

   Ahora que has analizado la arquitectura de referencia, puedes consultar un flujo de trabajo para desarrolladores basado en esta implementación. En el siguiente documento de esta serie, CI/CD modernas con GKE: aplicar el flujo de trabajo de desarrollo, crearás una aplicación, añadirás una función y, a continuación, desplegarás la aplicación en los entornos de staging y producción.

   Limpieza

   Si quieres probar el siguiente documento de esta serie, CI/CD moderno con GKE: aplicar el flujo de trabajo del desarrollador, no elimines el proyecto ni los recursos asociados a esta arquitectura de referencia. De lo contrario, para evitar que se apliquen cargos en tu cuenta de Google Cloud por los recursos que has usado en la arquitectura de referencia, puedes eliminar el proyecto o quitar los recursos manualmente.

   Eliminar el proyecto

   Precaución: Eliminar un proyecto tiene los siguientes efectos:
   • Se elimina todo el contenido del proyecto. Si has usado un proyecto que ya existía para las tareas de este documento, cuando lo elimines, también se eliminará cualquier otro trabajo que hayas realizado en él.
   • Se pierden los IDs de proyecto personalizados. Cuando creaste este proyecto, es posible que hayas creado un ID de proyecto personalizado que quieras usar en el futuro. Para conservar las URLs que usan el ID del proyecto, como una URL appspot.com, elimina los recursos seleccionados dentro del proyecto en lugar de eliminar todo 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 los recursos manualmente

   • En Cloud Shell, elimina 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
     

   Siguientes pasos

   • Crea una aplicación siguiendo los pasos que se indican en el artículo CI/CD modernas con GKE: aplicar el flujo de trabajo de desarrollo.
   • Consulta las prácticas recomendadas para configurar la federación de identidades.

   • Consulta el artículo Kubernetes y los retos del despliegue continuo de software.

   • Consulta arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Centro de arquitectura de Cloud.