Vérifier votre déploiement

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

Vous pouvez configurer Cloud Deploy pour vérifier qu'une application que vous avez déployée sur une cible fonctionne correctement. La validation s'effectue à l'aide de votre ou vos propres images de test. Vous configurez Cloud Deploy pour qu'il exécute ces tests une fois le déploiement terminé.

Comment fonctionne la validation du déploiement ?

Vous configurez une ou plusieurs cibles dans votre pipeline de déploiement pour la validation du déploiement en définissant les tâches à exécuter.
Une fois l'application déployée, Cloud Deploy exécute les tâches de validation dans l'environnement d'exécution Cloud Deploy.

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 généré par le conteneur.
  
  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 attendu, 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 :
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 déployer ou valider.
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.

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 strophe verify à une ou plusieurs cibles dans la progression d'un pipeline de livraison, comme illustré 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:
         tasks:
         - type: container
           image: "VERIFY_IMAGE"
           command: [COMMANDS_TO_RUN]
           args: [LIST_OF_ARGS]
           env: {VERIFY_TASK_ENV_MAP}

Dans ce fichier YAML :

VERIFY_IMAGE

Nom de l'image que vous souhaitez exécuter pour le job de validation. Par exemple, us-central1-docker.pkg.dev/gcp-project-id-12345/my-repository/my-app:v1.2 pour une image Artifact Registry.
COMMANDS_TO_RUN

Liste des points d'entrée à exécuter sur ce conteneur. "/bin/sh" est une commande typique à spécifier ici pour appeler un shell.
LIST_OF_ARGS

Il s'agit d'une liste d'arguments à fournir à la commande. Il s'agit d'une liste séparée par des virgules, avec chaque argument entre guillemets. Si votre COMMAND_TO_RUN est "/bin/sh", l'un des arguments ici serait "-c", et un autre argument serait la commande entière que vous souhaitez exécuter dans le shell que vous invoquez.

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

Il s'agit d'une carte des variables d'environnement transmises au conteneur, au format KEY:VAL.

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.

Exécuter la validation sur le cluster d'application

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 qu'il exécute la validation sur le même cluster que celui sur lequel votre application est exécutée.

Pour exécuter vos conteneurs de validation sur le cluster, vous devez les configurer sous la strophe verify de votre fichier skaffold.yaml. Pour chaque conteneur défini, vous devez également définir executionMode.kubernetesCluster.

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

Voici un exemple de section 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: {}

De plus, vous devez définir le stanza verify sur true dans la configuration de votre pipeline de livraison.

Voici un exemple de définition de pipeline de déploiement dans lequel la vérification est activée pour la cible dev.

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

Cette fonctionnalité n'est disponible que pour les déploiements sur GKE, 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 les déploiements parallèles, la validation est configurée sur la multicible, et les conteneurs de validation s'exécutent sur chaque cible enfant.

Vous pouvez également inclure les propriétés jobManifestPath et overrides sous kubernetesCluster pour pointer vers un fichier manifeste pour votre conteneur de validation et toutes les valeurs que vous souhaitez remplacer. (overrides utilise le JSON intégré de Kubernetes avec les valeurs que vous souhaitez remplacer.) En savoir plus

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, ce qui crée 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 également les variables d'environnement suivantes dans l'environnement d'exécution. Vous pouvez utiliser ces variables d'environnement dans votre hook de déploiement, votre tâche de validation ou votre cible personnalisée pour le rendu ou le déploiement.

ANTHOS_MEMBERSHIP

Pour les cibles de type ANTHOS, nom complet de la ressource de l'abonnement Anthos.
CLOUD_RUN_LOCATION

Pour les cibles de type RUN, 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, nom du service Cloud Run déployé.
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 . Les URL sont générées par Cloud Run une fois que votre ou vos services Cloud Run ont été déployés. Par conséquent, cette variable d'environnement n'est disponible que dans les hooks post-déploiement et les jobs de validation.
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. Pour les cibles personnalisées, cette valeur ne sera pas définie.
CLOUD_DEPLOY_LOCATION

Région contenant les ressources Cloud Deploy.
CLOUD_DEPLOY_DELIVERY_PIPELINE

ID du pipeline de livraison.
CLOUD_DEPLOY_TARGET

ID de la cible.
CLOUD_DEPLOY_PROJECT

Numéro de projet Google Cloud pour le projet contenant les ressources Cloud Deploy.
CLOUD_DEPLOY_PROJECT_ID

ID du projet Google Cloud .
CLOUD_DEPLOY_RELEASE

ID de la version dans laquelle les hooks s'exécuteront.
CLOUD_DEPLOY_ROLLOUT

ID du déploiement contenant les jobs pour les hooks.
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 pour le crochet de déploiement, le job de validation ou le rendu ou déploiement personnalisé.

Étapes suivantes

En savoir plus sur les tâches
Lisez le guide de démarrage rapide : Vérifier votre déploiement.