Se usó la API de Cloud Translation para traducir esta página.

Verifica tu 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 configuras Cloud Deploy y Skaffold para que ejecuten esas pruebas después de 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?

Configuras Skaffold para la verificación.

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

Puedes especificar más de una imagen de contenedor. Si especificas varios contenedores, se ejecutarán en paralelo, no de forma secuencial.
Configura 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 para las cargas de trabajo implementadas en ese destino.
Después de que se implementa una versión (skaffold apply), Cloud Deploy ejecuta el comando skaffold verify en el entorno de ejecución de Cloud Deploy.

Para las implementaciones en Google Kubernetes Engine y GKE Enterprise, puedes ejecutar de forma opcional el contenedor (o los contenedores) de verificación en el mismo clúster en el que se ejecuta el contenedor de la aplicación.
Skaffold invoca las pruebas especificadas en la sección verify de tu skaffold.yaml para que se ejecuten en la aplicación implementada.
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 del contenedor ejecutado.
  
  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 previsto, 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.

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

El siguiente es un ejemplo de un mensaje de Pub/Sub para la creación de una 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"
    }
  },

Inicio, éxito y falla de la ejecución del trabajo

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 u Verify)

El siguiente es un ejemplo de un mensaje de Pub/Sub para una ejecución de 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"
    }
  },

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 propiedad verify: true a un destino (o destinos) determinado en la 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 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 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 manera que para RENDER y DEPLOY.

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

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

Esta sección verify identifica uno o más contenedores que se ejecutarán para realizar la verificación, por ejemplo, pruebas de integración. Si especificas varios contenedores, se ejecutarán en paralelo, no de forma secuencial.

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, se muestra una cláusula verify que identifica un contenedor para usar y una secuencia de comandos de prueba para 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.

Ejecuta el contenedor o los contenedores de 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 el contenedor o los contenedores 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 capacidad solo está disponible para las 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.

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

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

A continuación, se muestra un ejemplo de una cláusula 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 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 y 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 proporciona y completa las siguientes variables de entorno en el VERIFY entorno de ejecución, que puedes usar para tus pruebas:

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 recurso completamente especificado del servicio de Cloud Run implementado, por ejemplo, projects/p/locations/us-central1/services/dev.
CLOUD_RUN_SERVICE_URLS

Para los 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 de tu servicio, en la consola deGoogle Cloud .
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.
CLOUD_DEPLOY_LOCATION

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

Es la canalización de entrega de ID en la que se ejecuta el entorno de ejecución.
CLOUD_DEPLOY_TARGET

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

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

ID del proyecto que contiene los recursos de Cloud Deploy. Google Cloud
CLOUD_DEPLOY_RELEASE

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

Es el ID de la versión de lanzamiento que contiene los trabajos de verificación.
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 del lanzamiento que contiene el trabajo de verificación.

Implementa parámetros como variables de entorno

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

Obtén más información.