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 un aplicación que implementó en cualquier destino funciona correctamente. La verificación se realiza con tu propia imagen de prueba y tú configuras Cloud Deploy y Skaffold para ejecutar esas pruebas después de la implementación para finalizar la tarea.

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

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

  1. Configuras Skaffold para la verificación.

    Esta configuración identifica las imágenes de contenedor que se usarán para ejecutar pruebas y los comandos específicos (por ejemplo, secuencias de comandos) que se ejecutarán a partir de ella imagen de contenedor.

  2. Debes configurar uno o más destinos en tu entrega. para verificar la implementación.

    Esta configuración permite la verificación de las cargas de trabajo implementadas en esa objetivo.

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

    Para las implementaciones en Google Kubernetes Engine y GKE Enterprise, puedes ejecuta el contenedor de verificación en el mismo clúster en el que se encuentra se ejecute tu contenedor.

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

  5. El éxito o el fracaso de las pruebas ejecutadas indica que la verificación se realizó correctamente o no.

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

      0 indica que la operación se realizó correctamente. Un código de salida distinto de cero indica un error. Para generar resultado de la 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 esta se realice correctamente.

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

    • Si una implementación falla durante la verificación, podrás verlo inspeccionando el lanzamiento:

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

  6. Puedes ignorar o reintenta una verificación con errores.

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

Componentes que se usan para la verificación

El recurso rollout incluye el 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 en conjunto, 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 de un intento de implementación.

Para obtener más información sobre los recursos de Cloud Deploy, consulta Cloud Deploy. arquitectura del servicio

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

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

  • Crea, actualiza y borra la ejecución de un trabajo

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

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

El siguiente es un ejemplo de mensaje de Pub/Sub para la ejecución de un trabajo crear, 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. contienen los siguientes atributos:

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

El siguiente es un ejemplo de mensaje de Pub/Sub para un trabajo con errores ejecutada, publicada 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 verificar la implementación

La habilitación de la verificación de implementación para un destino de Cloud Deploy consiste en de agregar una propiedad verify: true a uno o más objetivos específicos 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 implementación está habilitada en el destino dev, pero no en el objetivo prod. verify: false equivale a omitir la La propiedad verify o la estrofa strategy completa.

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 se puede para RENDER y DEPLOY.

Configura Skaffold para verificar la implementación

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

La estrofa verify identifica un contenedor que se ejecutará para realizar la verificación: como una prueba de integración.

El siguiente es 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. identificar un contenedor que se usará y una secuencia de comandos de prueba para ejecutar en ese contenedor. En este ejemplo, #ENDPOINT_URL es solo un marcador de posición para 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 Cloud Deploy entorno de ejecución. También puedes configurar Skaffold para ejecutar el contenedor de verificación en el mismo clúster donde se ejecuta tu aplicación. Cuando configuras la verificación en el clúster Si skaffold.yaml y habilitas la verificación en un destino, la verificación se ejecutará automáticamente en el clúster de ese destino.

Esta capacidad está disponible para implementaciones en GKE y Solo para GKE Enterprise, no para Cloud Run. Deployments en Cloud Run solo puede 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 tu contenedor de verificación en el clúster, incluye un executionMode.kubernetesCluster estrofa en tu configuración skaffold.yaml dentro de la estrofa verify para el contenedor de verificación específico:

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

El siguiente es un ejemplo de estrofa de verificación que incluye executionMode en Invoca 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 la de verificación de identidad en el entorno de ejecución de Cloud Deploy.

Vuelve a intentar la verificación

Cuando un trabajo de verificación falla, puedes reintentar la verificación y crear una ejecución del 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

Volver a intentar la verificación 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 el siguiente entorno variables en el entorno de ejecución VERIFY que puedes usar para tus pruebas:

  • ANTHOS_MEMBERSHIP

    Para destinos de tipo ANTHOS, el nombre del recurso completamente especificado de Anthos membresía.

  • CLOUD_RUN_LOCATION

    Para los destinos de tipo RUN, la región en la que se encuentra el servicio de Cloud Run implementar en la nube.

  • CLOUD_RUN_PROJECT

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

  • CLOUD_RUN_SERVICE

    Para destinos de tipo RUN, el nombre del recurso especificado por completo del objeto Servicio de Cloud Run, por ejemplo, projects/p/locations/us-central1/services/dev.

  • CLOUD_RUN_SERVICE_URLS

    Para destinos de tipo RUN, la URL o las URL (lista separada por comas) que finalizan que usarán los usuarios para acceder a tu servicio. Puedes encontrarlas en la Detalles del servicio de Cloud Run para tu servicio, en la Consola de Google Cloud

  • CLOUD_RUN_REVISION

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

  • GKE_CLUSTER

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

  • TARGET_TYPE

    El tipo de entorno de ejecución específico del destino. 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

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

  • CLOUD_DEPLOY_TARGET

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

  • CLOUD_DEPLOY_PROJECT

    Es 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 el trabajo.

  • CLOUD_DEPLOY_PHASE

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