Verifica tu implementación

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

Puedes configurar Cloud Deploy para verificar que una aplicación que implementaste en cualquier destino funcione correctamente. La verificación se realiza con tus propias imágenes de prueba, y configuras Cloud Deploy para que ejecute esas pruebas después de que finalice la implementación.

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

Puedes configurar uno o más destinos en tu canalización de entrega para la verificación de la implementación definiendo tareas para ejecutar.
Después de implementar una aplicación, Cloud Deploy ejecuta las tareas de verificación en el entorno de ejecución de Cloud Deploy.

El éxito o el fracaso de las pruebas ejecutadas indica el éxito o el fracaso de la verificación:
- El éxito de la verificación se determina según el código de salida que genera el contenedor.
  
  0 indica que la operación se realizó correctamente. Un código de salida distinto de cero indica un error. Para generar el resultado de verificación esperado, 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 falla la verificación, también fallará el lanzamiento.
- Si una implementación falla durante la verificación, puedes inspeccionar el lanzamiento para ver el motivo:
Puedes ignorar o volver a intentar una verificación fallida.

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

Componentes que se usan para la verificación

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

Fase

Es 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

Operación específica que se realizará en un lanzamiento, como la implementación o la verificación.
Ejecución del trabajo

Es 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 del servicio de Cloud Deploy.

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

Para habilitar la verificación de la implementación en un destino de Cloud Deploy, debes agregar una estrofa verify a un destino determinado (o a varios destinos) en una progresión de la 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:
         tasks:
         - type: container
           image: "VERIFY_IMAGE"
           command: [COMMANDS_TO_RUN]
           args: [LIST_OF_ARGS]
           env: {VERIFY_TASK_ENV_MAP}

En este archivo YAML:

VERIFY_IMAGE

Es el nombre de la imagen que deseas ejecutar para el trabajo de verificación. Por ejemplo, us-central1-docker.pkg.dev/gcp-project-id-12345/my-repository/my-app:v1.2 para una imagen de Artifact Registry.
COMMANDS_TO_RUN

Es una lista de puntos de entrada para ejecutar en ese contenedor. "/bin/sh" es un comando típico que se puede especificar aquí para invocar un shell.
LIST_OF_ARGS

Es una lista de argumentos que se proporcionan al comando. Es una lista separada por comas, con cada argumento entre comillas. Si tu COMMAND_TO_RUN es "/bin/sh", uno de los argumentos aquí sería "-c", y otro argumento sería todo el comando que deseas ejecutar en el shell que invocas.

Por ejemplo:
```
command: ["/bin/sh"]
args: ["-c", `echo "This command ran!"`]
```
VERIFY_TASK_ENV_MAP

Es un mapa de variables de entorno que se pasan al contenedor, en el formato KEY:VAL.

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 manera que para RENDER y DEPLOY.

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

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

Para ejecutar tus contenedores de verificación en el clúster, debes configurarlos en la sección verify de tu skaffold.yaml. Para cada contenedor definido, también debes establecer executionMode.kubernetesCluster.

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

A continuación, se muestra un ejemplo de una cláusula verify 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: {}

Además, debes establecer la estrofa verify en true dentro de la configuración de tu canalización de entrega.

A continuación, se muestra un ejemplo de definición de una canalización de entrega en la que el destino dev tiene habilitada la verificación.

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

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

En el caso de las implementaciones paralelas, la verificación se configura en el destino múltiple, y los contenedores de verificación se ejecutan en cada destino secundario.

También puedes incluir las propiedades jobManifestPath y overrides, en kubernetesCluster, para apuntar a un manifiesto de tu contenedor de verificación y a cualquier valor que desees anular. (overrides toma JSON intercalado de Kubernetes con los valores que deseas reemplazar). Obtén más información.

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

Vuelve a intentar la verificación

Cuando falla un trabajo de verificación, puedes volver a intentarlo, lo que creará una nueva ejecución del trabajo:

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 de la actualización progresiva cambiará de FAILED a IN_PROGRESS.

Solo puedes reintentar una verificación para una versión cuyo trabajo de verificación falló.

Variables de entorno disponibles

Cloud Deploy también proporciona y completa las siguientes variables de entorno en el entorno de ejecución. Puedes usar estas variables de entorno como parte de tu gancho de implementación, trabajo de verificación o destino personalizado de renderización o implementación.

ANTHOS_MEMBERSHIP

Para los destinos de tipo ANTHOS, es el nombre del recurso completamente especificado 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 los 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 los destinos de tipo RUN, son 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 de tu servicio, en la consola deGoogle Cloud . Cloud Run genera las URLs después de que se implementan correctamente tus servicios de Cloud Run. Por lo tanto, esta variable de entorno solo está disponible en los hooks posteriores a la implementación y en los trabajos de verificación.
CLOUD_RUN_REVISION

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

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

Es el tipo de tiempo de ejecución específico del destino. Puede ser GKE, ANTHOS o RUN. En el caso de los objetivos personalizados, no se establecerá este parámetro.
CLOUD_DEPLOY_LOCATION

Es la región que contiene los recursos de Cloud Deploy.
CLOUD_DEPLOY_DELIVERY_PIPELINE

Es el ID de la canalización de entrega.
CLOUD_DEPLOY_TARGET

Es el ID del objetivo.
CLOUD_DEPLOY_PROJECT

Número del proyecto Google Cloud que contiene los recursos de Cloud Deploy.
CLOUD_DEPLOY_PROJECT_ID

ID del proyecto Google Cloud .
CLOUD_DEPLOY_RELEASE

Es el ID de la versión en la que se ejecutarán los hooks.
CLOUD_DEPLOY_ROLLOUT

Es el ID del lanzamiento que contiene los trabajos de los hooks.
CLOUD_DEPLOY_JOB_RUN

Es el ID de la ejecución del trabajo que representa la ejecución actual del trabajo.
CLOUD_DEPLOY_PHASE

Es la fase de la versión que contiene el trabajo para el gancho de implementación, el trabajo de verificación o la renderización o implementación personalizadas.

¿Qué sigue?

Obtén más información sobre las tareas
Prueba la guía de inicio rápido: Verifica tu implementación