Vérifier votre déploiement

Ce document explique comment valider un déploiement Cloud Deploy.

Vous pouvez configurer Cloud Deploy et Skaffold pour vérifier qu'une application que vous avez déployée sur une cible fonctionne correctement. La validation est effectuée à l'aide de votre propre image de test. Vous configurez Cloud Deploy et Skaffold pour exécuter ces tests une fois le déploiement terminé.

Par défaut, la validation du déploiement s'exécute dans l'environnement d'exécution Cloud Deploy, mais vous pouvez également la configurer pour qu'elle s'exécute sur le même cluster que celui sur lequel l'application s'exécute.

Comment fonctionne la validation du déploiement ?

  1. Vous configurez Skaffold pour la validation.

    Cette configuration identifie l'image ou les images de conteneur à utiliser pour exécuter les tests, ainsi que les commandes spécifiques (script, par exemple) à exécuter à partir de cette image de conteneur.

    Vous pouvez spécifier plusieurs images de conteneur. Si vous spécifiez plusieurs conteneurs, ils sont exécutés en parallèle, et non de manière séquentielle.

  2. Vous configurez une ou plusieurs cibles dans votre pipeline de livraison pour la validation du déploiement.

    Cette configuration active la validation des charges de travail déployées sur cette cible.

  3. Une fois le déploiement effectué (skaffold apply), Cloud Deploy exécute la commande skaffold verify dans l'environnement d'exécution Cloud Deploy.

    Pour les déploiements sur Google Kubernetes Engine et GKE Enterprise, vous pouvez éventuellement exécuter le ou les conteneurs de validation sur le même cluster que celui sur lequel s'exécute le conteneur d'application.

  4. Skaffold appelle le ou les tests spécifiés dans la strophe verify de votre skaffold.yaml pour les exécuter sur l'application déployée.

  5. La réussite ou l'échec des tests exécutés indique la réussite ou l'échec de la validation.

    • La réussite de la validation est déterminée par le code de sortie du conteneur exécuté.

      0 indique que l'opération a réussi. Un code de sortie non nul indique un échec. Pour générer le résultat de validation souhaité, assurez-vous que le conteneur se ferme avec le code de sortie approprié. Si plusieurs conteneurs sont exécutés lors de la validation, ils doivent tous réussir pour que la validation aboutisse.

    • Si la validation échoue, le déploiement échoue également.

    • Si un déploiement échoue lors de la validation, vous pouvez le constater en inspectant le déploiement :

      Détails dans la console Google Cloud pour le déploiement, y compris l'état de validation

  6. Vous pouvez ignorer ou réessayer une validation ayant échoué.

    Vous pouvez également arrêter une tâche de validation en cours.

Composants utilisés pour la validation

La ressource rollout inclut les objets suivants, qui permettent de vérifier le déploiement :

  • Phase

    Ensemble d'opérations (jobs) d'un déploiement qui sont regroupées de manière logique, par exemple un déploiement ou un déploiement et une vérification.

  • Job

    Opération spécifique à effectuer sur un déploiement, comme "deploy" (déployer) ou "verify" (vérifier).

  • Exécution du job

    Enfant de la ressource de déploiement, l'exécution du job est une instance de job, par exemple une tentative de déploiement.

Pour en savoir plus sur les ressources Cloud Deploy, consultez Architecture du service Cloud Deploy.

Notifications générées par la validation du déploiement

Cloud Deploy génère des messages Pub/Sub et les publie pour les événements suivants :

  • Créer, modifier et supprimer des exécutions de jobs

    Ces notifications sont publiées dans le thème clouddeploy-resources et contiennent les attributs suivants :

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

Voici un exemple de message Pub/Sub pour la création d'une exécution de job, publié sur le sujet 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"
    }
  },

  • Démarrage, réussite et échec de l'exécution d'un job

    Ces notifications sont publiées dans le thème clouddeploy-operations et contiennent les attributs suivants :

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

Voici un exemple de message Pub/Sub pour une exécution de job ayant échoué, publié dans le sujet 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"
    }
  },

Configurer Cloud Deploy pour la validation du déploiement

Pour activer la validation du déploiement pour une cible Cloud Deploy, vous devez ajouter une propriété verify: true à une ou plusieurs cibles dans la progression d'un pipeline de livraison, comme indiqué dans cet exemple :

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

Dans cette configuration, la validation du déploiement est activée sur la cible dev, mais pas sur la cible prod. verify: false équivaut à omettre la propriété verify ou l'intégralité du stanza strategy.

L'opération de validation est exécutée dans son propre environnement d'exécution. Cet environnement d'exécution peut être configuré pour VERIFY de la même manière que pour RENDER et DEPLOY.

Configurer Skaffold pour la validation du déploiement

Pour activer la validation du déploiement pour une cible, vous devez ajouter une strophe verify dans le fichier de configuration skaffold.yaml de votre déploiement. Cette configuration peut concerner un profil Skaffold spécifique si vous utilisez des profils distincts par cible.

Cette strophe verify identifie un ou plusieurs conteneurs à exécuter pour effectuer la vérification (par exemple, les tests d'intégration). Si vous spécifiez plusieurs conteneurs, ils sont exécutés en parallèle, et non de manière séquentielle.

Voici un exemple de skaffold.yaml incluant une stanza 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"]

Cet exemple montre une strophe verify identifiant un conteneur à utiliser et un script de test à exécuter dans ce conteneur. Dans cet exemple, #ENDPOINT_URL n'est qu'un espace réservé pour l'URL de vos applications. Il ne s'agit pas d'une variable d'environnement Cloud Deploy disponible.

Exécutez le ou les conteneurs de validation sur le cluster d'applications.

Par défaut, la validation du déploiement s'exécute dans l'environnement d'exécution Cloud Deploy. Vous pouvez également configurer Skaffold pour exécuter le ou les conteneurs de validation sur le même cluster que celui sur lequel votre application est exécutée. Lorsque vous configurez la validation dans le cluster dans skaffold.yaml et que vous activez la validation sur une cible, la validation s'exécute automatiquement dans le cluster de cette cible.

Cette fonctionnalité est disponible uniquement pour les déploiements sur GKE et GKE Enterprise, et non pour Cloud Run. Les déploiements sur Cloud Run ne peuvent exécuter la validation que dans l'environnement d'exécution Cloud Deploy.

Pour exécuter vos conteneurs de validation sur le cluster, incluez une strophe executionMode.kubernetesCluster dans votre fichier de configuration skaffold.yaml, à l'intérieur de la strophe verify pour le conteneur de validation spécifique :

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

Voici un exemple de stanza de validation qui inclut executionMode pour appeler le conteneur de validation sur le cluster d'application :

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

La strophe executionMode est facultative. Si vous l'omettez, Skaffold exécute les conteneurs de validation dans l'environnement d'exécution Cloud Deploy.

Réessayer la validation

Lorsqu'un job de validation échoue, vous pouvez réessayer la validation en créant une exécution de job :

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 vous réessayez la validation, l'état du déploiement passe de FAILED à IN_PROGRESS.

Vous ne pouvez relancer la validation que pour un déploiement dont le job de validation a échoué.

Variables d'environnement disponibles

Cloud Deploy fournit et renseigne les variables d'environnement suivantes dans l'environnement d'exécution VERIFY, que vous pouvez utiliser pour vos tests :

  • ANTHOS_MEMBERSHIP

    Pour les cibles de type ANTHOS, nom de ressource Anthos complet de l'appartenance.

  • CLOUD_RUN_LOCATION

    Pour les cibles de type RUN, il s'agit de la région dans laquelle le service Cloud Run est déployé.

  • CLOUD_RUN_PROJECT

    Pour les cibles de type RUN, il s'agit du projet dans lequel le service Cloud Run a été créé.

  • CLOUD_RUN_SERVICE

    Pour les cibles de type RUN, le nom de ressource complet du service Cloud Run déployé, par exemple projects/p/locations/us-central1/services/dev.

  • CLOUD_RUN_SERVICE_URLS

    Pour les cibles de type RUN, il s'agit de l'URL ou des URL (liste séparée par des virgules) que les utilisateurs finaux utiliseront pour accéder à votre service. Vous les trouverez dans les détails du service Cloud Run pour votre service, dans la consoleGoogle Cloud .

  • CLOUD_RUN_REVISION

    Pour les cibles de type RUN, il s'agit de la révision spécifique du service Cloud Run.

  • GKE_CLUSTER

    Pour les cibles de type GKE, le nom de ressource complet du cluster Google Kubernetes Engine, par exemple projects/p/locations/us-central1/clusters/dev.

  • TARGET_TYPE

    Type d'exécution spécifique de la cible. GKE, ANTHOS ou RUN.

  • CLOUD_DEPLOY_LOCATION

    Région dans laquelle l'environnement d'exécution est en cours d'exécution.

  • CLOUD_DEPLOY_DELIVERY_PIPELINE

    Pipeline de distribution d'ID sur lequel l'environnement d'exécution s'exécute.

  • CLOUD_DEPLOY_TARGET

    ID de la cible sur laquelle l'environnement d'exécution s'exécute.

  • CLOUD_DEPLOY_PROJECT

    Numéro du projet Google Cloud dans lequel l'environnement d'exécution s'exécute.

  • CLOUD_DEPLOY_PROJECT_ID

    ID du projet Google Cloud contenant les ressources Cloud Deploy.

  • CLOUD_DEPLOY_RELEASE

    ID de la version dans laquelle la vérification sera exécutée.

  • CLOUD_DEPLOY_ROLLOUT

    ID du déploiement contenant les tâches de validation.

  • CLOUD_DEPLOY_JOB_RUN

    ID de l'exécution du job qui représente l'exécution actuelle du job.

  • CLOUD_DEPLOY_PHASE

    La phase du déploiement qui contient le job de vérification.

Déployer des paramètres en tant que variables d'environnement

En plus des variables d'environnement listées dans cette section, Cloud Deploy peut transmettre à vos conteneurs personnalisés tous les paramètres de déploiement que vous avez définis.

En savoir plus