Verificar la implementación

En este documento se describe cómo verificar un despliegue de Cloud Deploy.

Puede configurar Cloud Deploy y Skaffold para verificar que una aplicación que haya desplegado en cualquier destino funcione correctamente. La verificación se realiza con tu propia imagen de prueba y configuras Cloud Deploy y Skaffold para que ejecuten esas pruebas una vez que finalice el despliegue.

De forma predeterminada, la verificación del despliegue 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. Configura Skaffold para la verificación.

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

  2. Configura uno o varios destinos en tu canalización de entrega para verificar la implementación.

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

  3. Una vez que se ha desplegado un lanzamiento (skaffold apply), Cloud Deploy ejecuta el comando skaffold verify en el entorno de ejecución de Cloud Deploy.

    En el caso de las implementaciones en Google Kubernetes Engine y GKE Enterprise, 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 la prueba o las pruebas especificadas en la estrofa verify de tu archivo skaffold.yaml para ejecutarlas en la aplicación desplegada.

  5. Si las pruebas se realizan correctamente o no, se indica si la verificación se ha completado correctamente o no.

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

      0 indica que se ha completado correctamente. 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 salga con el código de salida adecuado. Si se ejecuta más de un contenedor como parte de la verificación, todos deben completarse correctamente para que la verificación se realice correctamente.

    • Si la verificación falla, la publicación tampoco se completará.

    • Si una implementación falla durante la verificación, puedes verlo inspeccionando la implementación:

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

  6. Puedes ignorar o volver a intentar una verificación fallida.

    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 la implementación:

  • Fase

    Conjunto de operaciones (trabajos) de un lanzamiento que se agrupan de forma lógica. Por ejemplo, una implementación o una implementación y una verificación.

  • Tarea

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

  • Ejecución de la tarea

    La ejecución de un trabajo, que es un elemento secundario del recurso de lanzamiento, 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 servicio de Cloud Deploy.

Notificaciones generadas por la verificación de despliegues

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

  • Creación, actualización y eliminación de ejecuciones de trabajos

    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

A continuación, se muestra un ejemplo de mensaje de Pub/Sub para una creación de ejecución de un 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"
    }
  },
  • Inicio, éxito y fallo de la ejecución de una tarea

    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 (Deploy o Verify)

A continuación, se muestra un ejemplo de mensaje de Pub/Sub de una ejecución de un trabajo fallida, 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"
    }
  },

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

Para habilitar la verificación del despliegue en un destino de Cloud Deploy, debes añadir la propiedad verify: true a un destino (o varios) de una progresión de una 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 del despliegue está habilitada en el destino dev, pero no en el destino prod. verify: false es equivalente a omitir la propiedad verify o toda la sección strategy.

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

Configurar Skaffold para la verificación de despliegues

Para habilitar la verificación de la implementación de un destino, se necesita una sección verify en el archivo de configuración skaffold.yaml de la implementación. Esta configuración puede ser para un perfil de Skaffold específico si usas perfiles independientes por destino.

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

A continuación, se muestra un ejemplo de skaffold.yaml 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 sencillo se muestra una sección verify que identifica un contenedor que se va a usar y una secuencia de comandos de prueba que se va a ejecutar en ese contenedor. #ENDPOINT_URL en este ejemplo es solo un marcador de posición para la URL de tus aplicaciones y no es una variable de entorno de Cloud Deploy disponible.

Ejecutar el contenedor de verificación en el clúster de aplicaciones

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 automáticamente en el clúster de ese destino.

Esta función solo está disponible para los despliegues en GKE y GKE Enterprise, no en 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 Skaffold versión 2.3 o posterior.

Para ejecutar el contenedor de verificación en el clúster, incluye una sección executionMode.kubernetesCluster en el archivo de configuración skaffold.yaml, dentro de la sección 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 stanza de verificación que incluye executionMode para invocar el contenedor de verificación en el clúster de aplicaciones:

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

Si falla una tarea de verificación, puedes volver a intentarla y crear una nueva ejecución de la tarea:

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, el estado del lanzamiento cambiará de FAILED a IN_PROGRESS.

Solo puedes volver a intentar la verificación de un lanzamiento cuya tarea de verificación haya fallado.

Variables de entorno disponibles

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

  • ANTHOS_MEMBERSHIP

    En el caso de los elementos de destino de tipo ANTHOS, el nombre de recurso totalmente especificado del miembro de Anthos.

  • CLOUD_RUN_LOCATION

    En el caso de los destinos de tipo RUN, la región en la que se ha desplegado el servicio de Cloud Run.

  • CLOUD_RUN_PROJECT

    En el caso de los destinos de tipo RUN, el proyecto en el que se creó el servicio de Cloud Run.

  • CLOUD_RUN_SERVICE

    En el caso de los destinos de tipo RUN, el nombre de recurso totalmente especificado del servicio de Cloud Run desplegado, por ejemplo, projects/p/locations/us-central1/services/dev.

  • CLOUD_RUN_SERVICE_URLS

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

  • CLOUD_RUN_REVISION

    En el caso de los destinos de tipo RUN, se trata de la revisión específica del servicio de Cloud Run.

  • GKE_CLUSTER

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

  • TARGET_TYPE

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

  • CLOUD_DEPLOY_LOCATION

    La región en la que se está ejecutando el entorno de ejecución.

  • CLOUD_DEPLOY_DELIVERY_PIPELINE

    La canalización de entrega de IDs en la que se ejecuta el entorno de ejecución.

  • CLOUD_DEPLOY_TARGET

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

  • CLOUD_DEPLOY_PROJECT

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

  • CLOUD_DEPLOY_PROJECT_ID

    El ID de proyecto Google Cloud que contiene los recursos de Cloud Deploy.

  • CLOUD_DEPLOY_RELEASE

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

  • CLOUD_DEPLOY_ROLLOUT

    El ID del lanzamiento que contiene los trabajos de verificación.

  • 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 del lanzamiento que contiene el trabajo de verificación.

Desplegar parámetros como variables de entorno

Además de las variables de entorno que se indican en esta sección, Cloud Deploy puede transferir a tus contenedores personalizados cualquier parámetro de implementación que hayas definido.

Más información