Verificar su implementación

En este documento, se describe cómo verificar una implementación de Cloud Deploy.

Puedes configurar Cloud Deploy y Skaffold para verificar que una aplicación que implementaste en cualquier destino funcione correctamente. La verificación se realiza con tu propia imagen de prueba, y debes configurar Cloud Deploy y Skaffold para ejecutar esas pruebas una vez que finalice la implementación.

De forma predeterminada, la verificación de la implementación se ejecuta en el entorno de ejecución de Cloud Deploy, pero también puedes configurarla para que se ejecute en el mismo clúster en el que se ejecuta la aplicación.

¿Cómo funciona la verificación de la implementación?

  1. configure Skaffold para la verificación.

    Esta configuración identifica las imágenes del contenedor que se usarán para ejecutar pruebas y los comandos específicos (por ejemplo, la secuencia de comandos) que se ejecutarán desde esa imagen de contenedor.

  2. configure uno o más destinos en tu canalización de entrega para la verificación de la implementación.

    Esta configuración habilita la verificación de las cargas de trabajo implementadas en ese destino.

  3. Después de que se implementa un lanzamiento (skaffold apply), Cloud Deploy ejecuta el comando skaffold verify en el entorno de ejecución de Cloud Deploy.

    Para implementaciones en Google Kubernetes Engine y GKE Enterprise, de manera opcional, puedes ejecutar el contenedor de verificación en el mismo clúster en el que se ejecuta el contenedor de la aplicación.

  4. Skaffold invoca las pruebas especificadas en la estrofa verify de tu skaffold.yaml para ejecutarlas en la aplicación implementada.

  5. El éxito o fracaso de las pruebas ejecutadas indica el éxito o fracaso de la verificación.

    • El código de salida del contenedor ejecutado determina el éxito de la verificación.

      0 indica que la prueba se realizó con éxito. Un código de salida distinto de cero indica un error. Para generar el resultado de verificación deseado, asegúrate de que el contenedor tenga el código de salida correcto. Si se ejecuta más de un contenedor como parte de la verificación, todos deben completarse correctamente para que la verificación tenga éxito.

    • Si la verificación falla, el lanzamiento también fallará.

    • Si una implementación falla durante la verificación, puedes verla inspeccionando el lanzamiento:

      Detalles del lanzamiento en la consola de Google Cloud, incluido el estado de verificación

  6. Puedes ignore o reintentar una verificación con errores.

    También puedes finalizar un trabajo de verificación en curso.

Componentes utilizados para la verificación

El recurso rollout incluye los siguientes objetos, que admiten la verificación de implementación:

  • Fase

    La colección de operaciones (trabajos) en un lanzamiento que se agrupan de forma lógica, por ejemplo, una implementación o una implementación y verificación.

  • Trabajo

    La operación específica que se realizará en un lanzamiento, como implementar o verificar.

  • Ejecución del trabajo

    Un elemento secundario del recurso de lanzamiento; la ejecución del trabajo es una instancia de un trabajo (por ejemplo, un intento de implementación).

Para obtener más información sobre los recursos de Cloud Deploy, consulta Arquitectura de servicios de Cloud Deploy

Notificaciones generadas por la verificación de la implementación

Cloud Deploy genera mensajes de Pub/Sub y los publica para los siguientes eventos:

  • Creación, actualización y eliminación de la ejecución del trabajo

    Estas notificaciones se publican en el tema clouddeploy-resources y contienen los siguientes atributos:

    • Resource
    • ResourceType (JobRun)
    • Action (Create, Update, Delete)
    • ProjectNumber
    • Location
    • TargetId
    • DeliveryPipelineId
    • ReleaseId
    • RolloutId
    • JobRunId

El siguiente es un ejemplo de mensaje de Pub/Sub para una creación de ejecución de trabajo, publicado en el tema clouddeploy-resources:

{
    "ackId": "UAYWLF1GSFE3GQhoUQ5PXiM_NSAoRRAGAE8CKF15MFcrQVh9Dz4NGXJ9YXRiWRIJBkUHeF9cEQ1iXE5EB0nq0KDVV1dKXxYGAExQeVhbHQVoWVh0Bnn7h5nK-8HjYwk9OqKarPdtO4PY2fNHZiI9XhJLLD5-My5FQV5AEkw4G0RJUytDCypYEU4EISE-MD5FU0Q",
    "message": {
      "attributes": {
        "Action": "Create",
        "DeliveryPipelineId": "dv-pipeline",
        "JobRunId": "634f8c6f-30c3-49ca-af80-68dc24d4cc5d",
        "Location": "us-central1",
        "ProjectNumber": "253401481285",
        "ReleaseId": "test-release-100",
        "Resource": "projects/253401481285/locations/us-central1/deliveryPipelines/dv-pipeline/releases/test-release-100/rollouts/test-release-100-to-dev-0001/jobRuns/634f8c6f-30c3-49ca-af80-68dc24d4cc5d",
        "ResourceType": "JobRun",
        "RolloutId": "test-release-100-to-dev-0001"
      },
      "messageId": "5572937706805411",
      "publishTime": "2022-09-07T14:00:46.040Z"
    }
  },
  • La ejecución del trabajo se inicia, se ejecuta de forma correcta y falla

    Estas notificaciones se publican en el tema clouddeploy-operations y contienen los siguientes atributos:

    • Resource
    • ResourceType (JobRun)
    • Action (Start, Succeed, Failure)
    • ProjectNumber
    • Location
    • TargetId
    • DeliveryPipelineId
    • ReleaseId
    • RolloutId
    • JobRunId
    • PhaseId
    • JobId
    • JobType (DeployVerify)

El siguiente es un ejemplo de mensaje de Pub/Sub para la ejecución de un trabajo con errores, publicado en el tema clouddeploy-operations:

{
    "ackId": "RFAGFixdRkhRNxkIaFEOT14jPzUgKEUUBAgUBXx9cEFPdVhec2hRDRlyfWB9aVsbCAUXU3cJURsHaE5tdR-6xcvaS0NVb18UAgRFWndfXhMEblhfcy-fkK3HwvT9U0AvOemNgdZpe6jHiulvZiM9XxJLLD5-My5FQV5AEkw4G0RJUytDCypYEU4EISE-MD5FUw",
    "message": {
      "attributes": {
        "Action": "Failure",
        "DeliveryPipelineId": "dv-pipeline",
        "JobId": "verify",
        "JobRunId": "b389224a-c259-4a00-ab75-c22e48bc3136",
        "JobType": "Verify",
        "Location": "us-central1",
        "PhaseId": "stable",
        "ProjectNumber": "253401481285",
        "ReleaseId": "test-release-101",
        "Resource": "projects/253401481285/locations/us-central1/deliveryPipelines/dv-pipeline/releases/test-release-101/rollouts/test-release-101-to-dev-0001/jobRuns/b389224a-c259-4a00-ab75-c22e48bc3136",
        "ResourceType": "JobRun",
        "RolloutId": "test-release-101-to-dev-0001",
        "TargetId": "dev"
      },
      "messageId": "5573609905896436",
      "publishTime": "2022-09-07T15:35:37.906Z"
    }
  },

Configura Cloud Deploy para la verificación de la implementación

Habilitar la verificación de implementación para un destino de Cloud Deploy consiste en agregar una propiedad verify: true a un destino determinado en una progresión de canalización de entrega, como se muestra en este ejemplo:

apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
 name: my-demo-app
description: main application pipeline
serialPipeline:
 stages:
 - targetId: dev
   profiles: []
   strategy:
     standard:
       verify: true
 - targetId: prod
   profiles: []
   strategy:
     standard:
       verify: false

En esta configuración, la verificación de la implementación está habilitada en el destino dev, pero no en el destino prod. verify: false equivale a omitir la propiedad verify o toda la estrofa strategy.

La operación de verificación se ejecuta dentro de su propio entorno de ejecución. Este entorno de ejecución se puede configurar para VERIFY de la misma manera que para RENDER y DEPLOY.

Configura Skaffold para la verificación de la implementación

Habilitar la verificación de la implementación para un destino requiere una estrofa verify en el archivo de configuración skaffold.yaml para la implementación. Si usas perfiles separados por destino, esta configuración puede aplicarse a un perfil específico de Skaffold.

Esta estrofa verify identifica un contenedor que se ejecutará para realizar la verificación, por ejemplo, una prueba de integración.

A continuación, se muestra un skaffold.yaml de ejemplo que incluye una estrofa verify:

apiVersion: skaffold/v4beta7
kind: Config
build:
  artifacts:
    - image: integration-test
      context: integration-test
manifests:
  rawYaml:
  - kubernetes.yaml
deploy:
  kubectl: {}
verify:
- name: verify-integration-test
  container:
    name: integration-test
    image: integration-test
    command: ["./test-systems.sh"]
- name: verify-endpoint-test
  container:
    name: alpine
    image: alpine
    command: ["/bin/sh"]
    args: ["-c", "wget #ENDPOINT_URL"]

En este ejemplo simple, se muestra una estrofa verify en la que se identifica un contenedor para usar y una secuencia de comandos de prueba que se ejecutará en ese contenedor. En este ejemplo, #ENDPOINT_URL es solo un marcador de posición para la URL de tus aplicaciones y no es una variable de entorno de Cloud Deploy disponible.

Ejecuta el contenedor de verificación en el clúster de la aplicación

De forma predeterminada, la verificación de la implementación se ejecuta en el entorno de ejecución de Cloud Deploy. También puedes configurar Skaffold para que ejecute el contenedor de verificación en el mismo clúster en el que se ejecuta tu aplicación. Cuando configuras la verificación en el clúster en skaffold.yaml y habilitas la verificación en un destino, la verificación se ejecuta de forma automática en el clúster de ese destino.

Esta capacidad está disponible solo para implementaciones en GKE y GKE Enterprise, no para Cloud Run. Las implementaciones en Cloud Run solo pueden ejecutar la verificación en el entorno de ejecución de Cloud Deploy.

La verificación en el clúster requiere la versión 2.3 de Skaffold o posterior.

Para ejecutar el contenedor de verificación en el clúster, incluye una estrofa executionMode.kubernetesCluster en el archivo de configuración skaffold.yaml, dentro de la estrofa verify del contenedor de verificación específico:

verify:
- name:
  container:
    name:
    image:
    command:
    args:
  executionMode:
    kubernetesCluster:

A continuación, se muestra un ejemplo de una estrofa de verificación que incluye executionMode para invocar el contenedor de verificación en el clúster de la aplicación:

verify:
- name: integration-test-container
  container:
    name: integration-test-container
    image: integration-test-container
  executionMode:
    kubernetesCluster: {}

La estrofa executionMode es opcional y, si la omites, Skaffold ejecuta el contenedor de verificación en el entorno de ejecución de Cloud Deploy.

Reintentar la verificación

Cuando un trabajo de verificación falla, puedes volver a intentar la verificación y crear una ejecución de trabajo nueva:

gcloud deploy rollouts retry-job ROLLOUT_NAME \
             --job-id=JOB_ID \
             --phase-id=PHASE_ID \
             --delivery-pipeline=PIPELINE_NAME \
             --release=RELEASE_NAME \
             --region=REGION

Si vuelves a intentar la verificación, se cambia el estado del lanzamiento de FAILED a IN_PROGRESS.

Solo puedes reintentar la verificación de un lanzamiento cuyo trabajo de verificación falló.

Variables de entorno disponibles

Cloud Deploy proporciona y propaga las siguientes variables de entorno en el entorno de ejecución VERIFY, que puedes usar para tus pruebas:

  • ANTHOS_MEMBERSHIP

    Para los objetivos de tipo ANTHOS, el nombre del recurso especificado por completo de la membresía de Anthos.

  • CLOUD_RUN_LOCATION

    Para los destinos de tipo RUN, es la región en la que se implementa el servicio de Cloud Run.

  • CLOUD_RUN_PROJECT

    Para destinos de tipo RUN, es el proyecto en el que se creó el servicio de Cloud Run.

  • CLOUD_RUN_SERVICE

    Para los destinos de tipo RUN, es el nombre del servicio de Cloud Run implementado.

  • CLOUD_RUN_SERVICE_URLS

    Para destinos de tipo RUN, la URL o las URLs (lista separada por comas) que los usuarios finales usarán para acceder a tu servicio. Puedes encontrarlos en los detalles del servicio de Cloud Run, en la consola de Google Cloud.

  • CLOUD_RUN_REVISION

    Para los objetivos de tipo RUN, es la revisión específica del servicio de Cloud Run.

  • GKE_CLUSTER

    Para los destinos de tipo GKE, el nombre del recurso especificado por completo del clúster de Google Kubernetes Engine, por ejemplo, projects/p/locations/us-central1/clusters/dev.

  • TARGET_TYPE

    El tipo específico de entorno de ejecución del destino. GKE, ANTHOS o RUN.

  • CLOUD_DEPLOY_LOCATION

    La región en la que se ejecuta el entorno de ejecución.

  • CLOUD_DEPLOY_DELIVERY_PIPELINE

    La canalización de entrega de ID que ejecuta el entorno de ejecución.

  • CLOUD_DEPLOY_TARGET

    El ID del destino en el que se ejecuta el entorno de ejecución.

  • CLOUD_DEPLOY_PROJECT

    El número del proyecto de Google Cloud en el que se ejecuta el entorno de ejecución.

  • CLOUD_DEPLOY_RELEASE

    El ID de la versión en la que se ejecutará la verificación.

  • CLOUD_DEPLOY_ROLLOUT

    El ID del lanzamiento que contiene los trabajos que se deben verificar.

  • CLOUD_DEPLOY_JOB_RUN

    El ID de la ejecución del trabajo que representa la ejecución actual del trabajo.

  • CLOUD_DEPLOY_PHASE

    La fase en el lanzamiento que contiene el trabajo que se debe verificar.