CI/CD moderna con GKE: aplica el flujo de trabajo de los desarrolladores

En este instructivo, se muestra cómo incorporar una aplicación nueva, desarrollar una característica para la aplicación y también implementar la aplicación en producción mediante técnicas modernas de integración continua/entrega continua (CI/CD) con Google Kubernetes Engine (GKE).

Este documento forma parte de una serie:

En este instructivo, usarás herramientas como Skaffold, kustomize, Artifact Registry, Sincronizador de configuración, Cloud Build y Cloud Deploy para desarrollar, compilar e implementar tu aplicación.

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.

Arquitectura

En este instructivo, integrarás una aplicación nueva. Luego, desarrollas una función nueva y, luego, implementas la aplicación en los entornos de desarrollo, etapa de pruebas y producción. La arquitectura de referencia contiene la infraestructura y las herramientas necesarias para incorporar y lanzar una aplicación nueva con el flujo de trabajo que se muestra en el siguiente diagrama:

El bucle de desarrollo abarca repositorios de código y canalizaciones de Cloud Build y Cloud Deploy.

A partir del repositorio de códigos para la CI, el flujo de trabajo incluye los siguientes pasos:

  1. Compartes el código fuente de la aplicación a través de los repositorios de tu aplicación.

  2. Cuando confirma y envía el código al repositorio de la aplicación, se activa automáticamente una canalización de CI en Cloud Build. El proceso de CI crea y envía una imagen de contenedor a Artifact Registry.

  3. El proceso de CI también crea una versión de CD para la aplicación en Cloud Deploy.

  4. La versión de CD genera manifiestos de Kubernetes completamente renderizados para el desarrollo con skaffold y los implementa en el clúster de GKE de desarrollo.

  5. La versión de la CD asciende desde el desarrollo a un destino de etapa de pruebas, que genera manifiestos de etapa de pruebas completamente renderizados y los implementa en el clúster de GKE de etapa de pruebas.

  6. Luego, la versión de CD asciende desde la etapa de pruebas a la de producción, que genera manifiestos de producción completamente renderizados y los implementa en clústeres de GKE de producción.

Para obtener más información sobre las herramientas y la infraestructura utilizadas en este flujo de trabajo, consulta CI/CD moderna con GKE: Compila un sistema de CI/CD.

Integra una aplicación nueva

La arquitectura de referencia contiene una fábrica de aplicaciones. Esta fábrica es una colección de un repositorio de Git llamado application-factory-repo y los siguientes activadores de Cloud Build:

  • create-app
  • tf-plan
  • tf-apply
  • create-team

Usas la fábrica de aplicaciones para incorporar una aplicación nueva desde repositorios de inicio. La integración de la aplicación consta de los siguientes pasos:

  1. Crea la definición de la aplicación: Creas la definición de la aplicación en un archivo de Terraform y la almacenas en application-factory-repo, que actúa como catálogo de aplicaciones.

  2. Crea la infraestructura de la aplicación: Ejecuta Terraform en el archivo de definición de la aplicación para crear la infraestructura de la aplicación. La infraestructura de la aplicación consta de lo siguiente:

    1. Una zona de destino para la aplicación nueva incluye la definición del espacio de nombres, la cuenta de servicio y las políticas base en el repositorio acm-gke-infrastructure-repo. La zona de destino solo se crea en un clúster de GKE de desarrollo durante la incorporación de una aplicación nueva. Esto se hace para desbloquear a los desarrolladores para que puedan usar el entorno de desarrollo y comenzar a iterar en él. La zona de destino en los clústeres de etapa de pruebas y producción se crea con el enfoque de GitOps. Este enfoque se demuestra más adelante en este documento, cuando estés listo para ascender la versión en esos clústeres.

    2. El repositorio de infraestructura del repositorio de inicio de infraestructura que aloja el código para crear la canalización de CI en Cloud Build, la canalización de CD en Cloud Deploy y el repositorio de Artifact Registry para almacenar artefactos.

    3. Un activador de infraestructura de Cloud Build que toma el código en el repositorio de infraestructura y crea los recursos según su definición.

    4. Un repositorio de la aplicación del repositorio de inicio de la aplicación que aloja el código fuente de la aplicación

  3. Crea recursos de CI/CD de la aplicación: Usa la infraestructura de la aplicación para crear recursos de CI/CD para la aplicación.

Crea la definición de la aplicación:

Ejecuta el activador create-app para generar un archivo de definición de la aplicación en application-factory-repo. El archivo de definición contiene la definición declarativa de los recursos necesarios para crear una aplicación.

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

    Ir a la página Cloud Build

  2. Haz clic en e Activador create-app.

  3. Haz clic en MOSTRAR VISTA PREVIA DE LA URL para mostrar la URL necesaria para invocar el webhook.

  4. En Cloud Shell, invoca el activador mediante una solicitud curl en la URL que se obtuvo del paso anterior y pásale los parámetros como una carga útil.

    curl "WEBHOOK_URL" -d '{"message": {"app": "sample","runtime": "python","trigger_type": "webhook","github_team": ""}}'

    En la muestra de código anterior, ocurre lo siguiente:

    • Reemplaza WEBHOOK_URL por la URL obtenida del activador.

    • "app": "sample" especifica el nombre de la aplicación.

    • "runtime": "python" le indica a la fábrica de aplicaciones que use la plantilla de Python para crear repositorios de aplicaciones.

    • "trigger_type": "webhook" especifica el tipo de canalizaciones de CI/CD para la aplicación.

    • "github_team": "" es un equipo en GitHub que se asociará con los repositorios que se creen para la aplicación. Como aún no creaste un equipo de GitHub, pásalo como una cadena vacía.

  5. Verifica si la canalización tiene el activador create-app:

    Ir a la página Historial de Cloud Build

    Hay una nueva canalización para el activador create-app. Cuando se complete, se creará la definición de la aplicación en application-factory-repo.

  6. Revisa el archivo de definición de la aplicación:

    1. En un navegador web, ve a GitHub y accede a tu cuenta.

    2. Haz clic en el ícono de foto y, luego, en Your organizations. Elige tu organización.

    3. Haz clic en el repositorio application-factory-repo, ve a la carpeta apps/python y abre el archivo nuevo llamado sample.tf que creó el activador create-app. Inspecciona el archivo. Este contiene código de Terraform para crear una aplicación nueva.

Crea la infraestructura de la aplicación:

Ahora que creaste la definición de la aplicación, ejecuta el activador tf-apply para crear la infraestructura de la aplicación.

  1. En la consola de Google Cloud , haz lo siguiente:

    Ir a la página Cloud Build.

    Haz clic en el activador tf-apply.

  2. Haz clic en “MOSTRAR VISTA PREVIA DE LA URL” para mostrar la URL necesaria para invocar el webhook.

  3. Invoca el activador:

    curl "WEBHOOK_URL" -d '{}'

    En la muestra de código anterior, ocurre lo siguiente:

    • Reemplaza WEBHOOK_URL por la URL obtenida del activador.

  4. Verifica si la canalización tiene el activador tf-apply:

    Ir a la página Historial de Cloud Build

    Hay una nueva canalización para el activador tf-apply. Espera a que se complete.

Este activador crea la infraestructura de la aplicación.

Revisa la infraestructura de la aplicación:

Revisa los diversos componentes de la infraestructura de la aplicación.

Zona de destino

  1. Ve a Cloud Shell y configura el proyecto. 

    gcloud config set core/project PROJECT_ID

    Reemplaza PROJECT_ID por el Google Cloud ID del proyecto.

  2. Obtén credenciales para el clúster de GKE de desarrollo.

    gcloud container clusters get-credentials gke-dev-us-central1 --location us-central1-a

  3. Verifica el espacio de nombres de la aplicación. El espacio de nombres se llama igual que la aplicación, sample.

    kubectl get namespaces sample

    El resultado se ve de la manera siguiente: 

    NAME     STATUS   AGE
sample   Active   15m

  4. Verifica la cuenta de servicio en el espacio de nombres.

    kubectl get serviceaccounts -n sample

    Hay una cuenta de servicio además de la predeterminada. El resultado se ve de la manera siguiente: 

    NAME         SECRETS   AGE
default      0         15m
sample-ksa   0         15m

Repositorio de infraestructura

En un navegador web, ve a GitHub y accede a tu cuenta. Haz clic en el ícono de foto. Luego, haz clic en Your organizations. Elige tu organización y haz clic en el repositorio sample-infra.

Este repositorio tiene cuatro ramas: cicd-trigger, dev, staging y prod. También contiene cuatro carpetas: cicd-trigger, dev, staging y prod. La rama predeterminada es cicd-trigger, y puedes enviar el código a ella, mientras que otras ramas tienen reglas de protección, por lo que no puedes enviar código directamente a esas ramas. Para enviar el código a esas ramas, debes crear una solicitud de extracción. La carpeta cicd-trigger tiene código para crear recursos de CI/CD para la aplicación, mientras que las carpetas dev, staging y prod tienen código para crear infraestructura para diferentes entornos de la aplicación.

Activador de infraestructura

  • En la consola de Google Cloud , haz lo siguiente:

    Ir a la página Cloud Build

    Hay un nuevo activador llamado deploy-infra-sample.

  • Este activador está conectado al repositorio sample-infra, de modo que, cuando se realiza un envío de código a este repositorio, se invoca el activador, se identifica la rama en la que se realizó el envío, se va a la carpeta correspondiente de esa rama y se ejecuta Terraform allí. Por ejemplo, si el código se envía a la rama cicd-trigger, el activador ejecuta Terraform en la carpeta cicd-trigger de la rama cicd-trigger. Del mismo modo, cuando se realiza una confirmación en la rama dev, el activador ejecuta Terraform en la carpeta dev de la rama dev, y así sucesivamente.

Repositorio de aplicaciones

  • Ve a GitHub y abre los repositorios de tu organización. Hay un nuevo repositorio con el nombre sample. Este repositorio aloja el código fuente y los pasos para compilar contenedores en archivos de configuración Dockerfile, kustomize que describen la configuración necesaria de la aplicación, y skaffold.yaml, que define los pasos de implementación que Cloud Deploy usará para la CD.

Crea recursos de CI/CD de la aplicación

Ahora que creaste el esqueleto de la aplicación, ejecuta el activador deploy-infra-sample para crear sus recursos de CI/CD. Puedes invocar el activador de forma manual con su URL de webhook o realizando una confirmación en el repositorio de Git sample-infra.

  1. Para invocar el activador de Cloud Build, agrega una línea nueva en un archivo en el repositorio. Luego, envía los cambios:

    1. Si nunca usaste Git en Cloud Shell, configúralo con tu nombre y dirección de correo electrónico: Git usa esta información para identificarte como el autor de las confirmaciones que creas en Cloud Shell:

      git config --global user.email "GITHUB_EMAIL_ADDRESS"
git config --global user.name "GITHUB_USERNAME"

      Reemplaza lo siguiente:

      • GITHUB_EMAIL_ADDRESS: La dirección de correo electrónico asociada a tu cuenta de GitHub
      • GITHUB_USERNAME: El nombre de usuario asociado con tu cuenta de GitHub

    2. Clona el repositorio de Git sample-infra:

      git clone https://github.com/GITHUB_ORG/sample-infra

cd sample-infra

      Reemplaza lo siguiente:

      • GITHUB_ORG por tu organización de GitHub.

      Se extrae la rama predeterminada cicd-trigger.

    3. Agrega una línea nueva al archivo env/cicd-trigger/main.tf, confirma el cambio y envíalo.

        echo "" >> env/cicd-trigger/main.tf

    4. Confirma y envía los cambios:

      git add .
git commit -m "A dummy commit to invoke the infrastrucutre trigger"
git push
cd ..

      En cuanto se envían los cambios, se inicia el activador de Cloud Deploy deploy-infra-sample.

  2. Supervisa el estado del activador:

    Ir a la página Historial de Cloud Build para ver la canalización y esperar a que se complete.

Revisa los recursos de CICD de la aplicación

Revisa los diversos recursos de CI/CD creados para la aplicación.

  1. En la consola de Google Cloud , haz lo siguiente:

    Ir a la página de Cloud Build y ve el activador deploy-app-sample.

    Este es el activador de la canalización de CI. Está conectado al repositorio de código de la aplicación sample. El activador se invoca cuando se realiza una inserción en el repositorio de la aplicación y ejecuta los pasos de compilación según se definen en la configuración del activador. Para ver los pasos que realiza el activador cuando se invoca, haz clic en el nombre del activador y, luego, en el botón ABRIR EDITOR.

  2. Ve a la página de Artifact Registry y consulta el nuevo repositorio con el nombre sample.

    Este repositorio de artefactos almacena los artefactos de la aplicación.

  3. Ve a la página de la canalización de Cloud Deploy y consulta la canalización con el nombre sample. Esta es la canalización de implementación continua que implementa la aplicación en los clústeres de GKE.

Implementa la aplicación en el entorno de desarrollo

El activador deploy-app-sample está conectado al repositorio de la aplicación llamado sample. Puedes invocar el activador de forma manual, con la URL del webhook, o mediante una inserción en el repositorio de la aplicación.

  1. Agrega una línea nueva en un archivo en el repositorio sample y envía los cambios para invocar el activador de Cloud Build:

    1. Clona el repositorio de Git sample:

      En Cloud Shell:

      git clone https://github.com/GITHUB_ORG/sample

cd sample

      Reemplaza GITHUB_ORG por tu organización de GitHub.

    2. Agrega una línea nueva al archivo skaffold.yaml.

        echo "" >> skaffold.yaml

    3. Confirma y envía los cambios:

      git add .
git commit -m "A dummy commit to invoke CI/CD trigger"
git push

    4. En cuanto se envían los cambios, se inicia el activador de Cloud Deploy deploy-app-sample.

  2. Supervisa el estado del activador:

    Ir a la página Historial de Cloud Build para ver la canalización y esperar a que se complete.

    El activador ejecuta los pasos definidos en su configuración. El primer paso es compilar una imagen de Docker a partir del código de la aplicación en el repositorio sample. El último paso es iniciar la canalización de Cloud Deploy que implementa la aplicación en el clúster de GKE de desarrollo.

  3. Verifica la implementación en el clúster de desarrollo:

    Ve a la página de la canalización de Cloud Deploy.

    Haz clic en la canalización sample. Se inició la implementación en el clúster de GKE de desarrollo. Espera a que se complete.

Verifica que la aplicación se haya implementado correctamente:

  1. Obtén credenciales para el clúster de desarrollo.

    gcloud container clusters get-credentials gke-dev-us-central1 --location us-central1-a

  2. Crea un túnel para el clúster de GKE.

    gcloud container clusters get-credentials gke-dev-us-central1 --location us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080

  3. En la barra de herramientas de Cloud Shell, haz clic en

    Vista previa en la Web y, luego, haz clic en Vista previa en el puerto 8080: Comandos de la barra de herramientas de Cloud Shell

    Esta es la salida:

    Hello World!

  4. En Cloud Shell, presiona CTRL+C para finalizar la redirección de puertos.

Agrega una nueva función a la aplicación

Cuando desarrollas una función nueva, debes implementar rápidamente los cambios en una zona de pruebas de desarrollo para probar e iterar en ellos. En este instructivo, realizarás cambios en el repositorio de código de la aplicación y los implementarás en el entorno de desarrollo.

  1. En Cloud Shell, cambia el directorio a un repositorio sample ya clonado:

  2. Actualiza la aplicación para que genere un mensaje diferente:

      sed -i "s/Hello World/My new feature/g" main.py

  3. Confirma y envía los cambios:

    git add .
git commit -m "Changed the message"
git push

    En cuanto se envía el código al repositorio de GitHub, se activa el webhook deploy-app-sample.

  4. Supervisa el estado del activador en la página del historial de Cloud Build y espera a que se complete.

  5. Ir a la página de la canalización de Cloud Deploy

    Haz clic en la canalización sample. Se inició la implementación en el clúster de GKE de desarrollo. Espera a que se complete.

Verifica que la aplicación se haya implementado correctamente:

  1. Obtén credenciales en el clúster de desarrollo si abriste un nuevo Cloud Shell:

    gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a

  2. Crea un túnel para el clúster de GKE:

    gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080

  3. En la barra de herramientas de Cloud Shell, haz clic en

    Vista previa en la Web y, luego, haz clic en Vista previa en el puerto 8080:

    Comandos de la barra de herramientas de Cloud Shell

    Esta es la salida:

    My new feature!

  4. En Cloud Shell, presiona CTRL+C para finalizar la redirección de puertos.

Promueve el cambio en los clústeres de etapa de pruebas y de producción

Antes de ascender la aplicación a entornos de etapa de pruebas y producción, debes crear la zona de destino para la aplicación en los clústeres de GKE de esos entornos. Cuando incorporaste la aplicación, la zona de destino para desarrollo se creó de forma automática en el clúster de desarrollo de GKE mediante la adición de código a acm-gke-infrastructure-repo en la rama de desarrollo.

Crea una zona de destino en los clústeres de GKE de etapa de pruebas y producción

  1. Crea una zona de destino en el clúster de GKE de etapa de pruebas: Debes crear una solicitud de extracción de la rama de desarrollo a la de etapa de pruebas en acm-gke-infrastructure-repo y combinarla.

    1. Ve a GitHub y navega al repositorio acm-gke-infrastructure-repo. Haz clic en Pull requests y, luego, en el botón New pull request. En el menú Base, elige etapa de pruebas y, en el menú Comparar, elige dev. Haz clic en el botón Create pull request.

    2. Por lo general, alguien que tiene acceso al repositorio revisa los cambios y, luego, combina la PR para asegurarse de que solo los cambios previstos ascienden al entorno de etapa de pruebas. Para permitir que las personas prueben la arquitectura de referencia, se reduce la rigurosidad de las reglas de protección de ramas para que el administrador del repositorio pueda omitir la revisión y combinar la PR. Si eres administrador del repositorio, combina la solicitud de extracción. De lo contrario, pídele al administrador que lo combine.

    El Sincronizador de configuración sincroniza los cambios que llegan a la rama de etapa de pruebas del repositorio acm-gke-infrastructure-repo con el clúster de GKE de etapa de pruebas que da como resultado la creación de la zona de destino para la aplicación en el clúster de GKE de etapa de pruebas.

  2. Crea una zona de destino en los clústeres de GKE de producción: debes crear una solicitud de extracción de la etapa de pruebas a la rama de producción y combinarla.

    1. Haz clic en Pull requests y, luego, en el botón New pull request. En el menú Base, elige prod y, en el menú Comparar, elige etapa de pruebas. Haz clic en el botón Create pull request.

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

    El Sincronizador de configuración sincroniza los cambios que llegan a la rama de producción del repositorio acm-gke-infrastructure-repo con los clústeres de GKE de producción, lo que da como resultado la creación de la zona de destino para la aplicación en clústeres de GKE de producción.

Promueve los cambios de la etapa de desarrollo a la de etapa de pruebas

Ahora que creaste la zona de destino para la aplicación en los clústeres de etapa de pruebas y de producción de GKE, asciende la aplicación del entorno de desarrollo a la de etapa de pruebas.

  1. Busca el nombre de la versión más reciente y guárdalo como una variable de entorno:

      export RELEASE=$(gcloud deploy targets describe dev --region=us-central1 --format="json" | jq -r '."Active Pipeline"[0]."projects/PROJECT_ID/locations/us-central1/deliveryPipelines/sample"."Latest release"' | awk -F '/' '{print $NF}')

    Reemplaza PROJECT_ID por el Google Cloud ID del proyecto.

    Verifica que se haya configurado la variable de entorno:

      echo $RELEASE

  2. En Cloud Shell, ejecuta el siguiente comando para activar la promoción del lanzamiento del entorno de desarrollo a etapa de pruebas:

     gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample  --region=us-central1 --to-target=staging --quiet

  3. Verifica la implementación en la etapa de pruebas:

    Ir a la página de la canalización de Cloud Deploy

    Haz clic en la canalización sample. Se inició la implementación en el clúster de GKE de etapa de pruebas. Espera a que se complete.

  4. Verifica que la implementación de la etapa de pruebas se haya realizado correctamente:

    1. Obtén credenciales para el clúster de etapa de pruebas:

      gcloud container clusters get-credentials gke-staging-us-central1 --location us-central1-a

    2. Crea un túnel para el clúster de GKE:

      gcloud container clusters get-credentials gke-staging-us-central1 --location us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080

    3. En la barra de herramientas de Cloud Shell, haz clic en

      Vista previa en la Web y, luego, haz clic en Vista previa en el puerto 8080:

      Comandos de la barra de herramientas de Cloud Shell

      Esta es la salida:

      My new feature!

    4. En Cloud Shell, presiona CTRL+C para finalizar la redirección de puertos.

Asciende los cambios de la etapa de pruebas a la de producción

Ahora, asciende el lanzamiento de la etapa de pruebas a producción. Tienes dos clústeres de producción y Cloud Deploy tiene un destino para cada uno de ellos, llamados prod1 y prod2, respectivamente.

  1. En Cloud Shell, ejecuta el siguiente comando para activar la promoción de la versión de la etapa de pruebas al clúster prod1:

     gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample  --region=us-central1 --to-target=prod1 --quiet

  2. El lanzamiento a clústeres de producción requiere aprobación, por lo que el lanzamiento espera hasta que lo apruebes. Para verla, haz lo siguiente:

    Ir a la página de la canalización de Cloud Deploy

    Haz clic en la canalización sample. El lanzamiento a prod1 requiere la aprobación y se necesita el rol clouddeploy.approver para aprobarlo. Como eres el propietario del proyecto, tienes acceso para aprobar la versión.

  3. Aprueba la versión en prod1:

    Ejecuta el siguiente comando para recuperar el nombre del lanzamiento pendiente de aprobación y guárdalo en una variable de entorno:

     export ROLLOUT=$(gcloud deploy targets describe prod1 --region=us-central1 --format="json" | jq -r '."Pending Approvals"[]' | awk -F '/' '{print $NF}')

    Aprobar la versión:

     gcloud deploy rollouts approve $ROLLOUT --delivery-pipeline=sample --region=us-central1 --release=$RELEASE --quiet

  4. Después de que se otorga la aprobación, comienza el lanzamiento de prod1. Supervisa el progreso en la página de la canalización de Cloud Deploy.

  5. Una vez que se complete la implementación de prod1, inicia el lanzamiento de prod2.

     gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample  --region=us-central1 --to-target=prod2 --quiet

  6. El lanzamiento a prod2 también requiere aprobación. Aprueba la versión en el clúster prod2:

    Ejecuta el siguiente comando para recuperar el nombre del lanzamiento pendiente de aprobación y guárdalo en una variable de entorno:

     export ROLLOUT=$(gcloud deploy targets describe prod2 --region=us-central1 --format="json" | jq -r '."Pending Approvals"[]' | awk -F '/' '{print $NF}')

    Aprobar la versión:

     gcloud deploy rollouts approve $ROLLOUT --delivery-pipeline=sample --region=us-central1 --release=$RELEASE --quiet

  7. Una vez que se otorga la aprobación, comienza el lanzamiento de prod2. Supervisa el progreso en la página de la canalización de Cloud Deploy.

  8. Verifica que la implementación en el clúster de producción se haya realizado correctamente después de que se completen las canalizaciones de Cloud Deploy en prod1 y prod2.

    1. Se creó Ingress de varios clústeres en clústeres de producción, y usas un balanceador de cargas para acceder a la aplicación de producción. Estas configuraciones de Multi Cluster Ingress se crean con los archivos YAML k8s/prod/mci.yaml y k8s/prod/mcs.yaml en el repositorio sample. Cuando envías una solicitud a la dirección IP del balanceador de cargas, Ingress de varios clústeres reenvía la solicitud a una de las dos instancias de la aplicación que se ejecutan en dos clústeres de GKE diferentes.

    2. Enumera la regla de reenvío asociada al balanceador de cargas para encontrar la dirección IP.

      gcloud compute forwarding-rules list

    3. El resultado se ve de la manera siguiente: 

      NAME: mci-qqxs9x-fw-sample-sample-ingress
REGION:
IP_ADDRESS: 34.36.123.118
IP_PROTOCOL: TCP
TARGET: mci-qqxs9x-sample-sample-ingress

    4. Abre un navegador web y, en la URL, ingresa lo siguiente: 

      http://IP_ADDRESS:80

      Reemplaza IP_ADDRESS por la dirección IP del balanceador de cargas.

      Esta es la salida:

      My new feature!

      Esto confirma que la aplicación se implementó según lo previsto en los clústeres de producción.

Prueba la resiliencia de la aplicación

En esta sección, probarás la capacidad de recuperación de la aplicación que se ejecuta en producción reiniciando uno de los dos nodos de los clústeres de GKE de producción sin afectar la aplicación.

La aplicación en producción usa Ingress de varios clústeres y se puede acceder a ella a través de una IP del balanceador de cargas. Cuando se accede a la aplicación a través de esa IP, el Ingress de varios clústeres la enruta a una de las dos instancias de la aplicación que se ejecutan en dos clústeres de GKE diferentes. Cuando uno de los clústeres de GKE está en mal estado y no se puede acceder a la instancia de la aplicación que se ejecuta en él, el Ingress de varios clústeres sigue enviando el tráfico a la instancia en buen estado de la aplicación que se ejecuta en el otro clúster de GKE. Esto hace que la interrupción del clúster sea invisible para el usuario final y que la aplicación siga atendiendo las solicitudes de forma continua.

Para probar la resiliencia, haz lo siguiente:

  1. Busca el grupo de nodos de los clústeres de GKE de producción que se ejecutan en us-west1. 

     gcloud container clusters describe gke-prod-us-west1 --location=us-west1-a --format=json | jq ".nodePools[0].instanceGroupUrls[]" | tr '"' ' ' |  awk -F '/' '{for(i=NF-2; i<=NF; i=i+2) printf ("%s ",$i); print  ""}'

  2. El resultado se ve de la manera siguiente:

    us-west1-b gke-gke-prod-us-west1-node-pool-01-6ad4e1ed-grp
us-west1-c gke-gke-prod-us-west1-node-pool-01-98407373-grp

    El resultado tiene dos columnas: la primera es la zona y la segunda es el nombre del grupo de instancias asociado al grupo de nodos del clúster de GKE de producción en la región us-west1.

  3. Reinicia el grupo de instancias correspondiente a los grupos de nodos:

     gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_1  --zone=ZONE_1 --max-unavailable=100%

 gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_2  --zone=ZONE_2 --max-unavailable=100%

    Reemplaza INSTANCE_GROUP_1 por el nombre del primer grupo de instancias.

    Reemplaza ZONE_1 por la zona del primer grupo de instancias.

    Reemplaza INSTANCE_GROUP_2 por el nombre del segundo grupo de instancias.

    Reemplaza ZONE_2 por la zona del segundo grupo de instancias.

  4. Verifica el estado del grupo de instancias.

    Ir a la página Grupos de instancias

    Los dos grupos de instancias se están reiniciando, mientras que los otros grupos tienen una marca de verificación verde.

    Es el estado de los grupos de instancias.

  5. Abre un navegador web y, en la URL, ingresa lo siguiente: 

    http://IP_ADDRESS:80

    Reemplaza IP_ADDRESS por la dirección IP del balanceador de cargas.

    Incluso cuando uno de los dos clústeres de GKE está inactivo, la aplicación está disponible y el resultado es el siguiente:

     My new feature!

    Esto demuestra que tu aplicación es resiliente y tiene alta disponibilidad.

Administra la aplicación

Cuando creó esta aplicación a partir de la fábrica de aplicaciones, obtuvo repositorios de Git independientes, canalizaciones de CI/CD y de infraestructura para la aplicación. Usaste estos recursos para implementar la aplicación y agregar una función nueva. Para administrar aún más la aplicación, solo necesitas interactuar con estos repositorios de Git y la canalización sin necesidad de actualizar la fábrica de aplicaciones. Puedes personalizar las canalizaciones y los repositorios de Git de la aplicación según tus requisitos. Como propietario de la aplicación, puedes definir quién tiene acceso a las canalizaciones y los repositorios de Git de tu aplicación para administrarla.