Définir une analyse personnalisée

Cloud Deploy est compatible avec les jobs d'analyse qui utilisent des alertes générées par Google Cloud Observability en fonction de métriques et d'autres données provenant également de Google Cloud Observability. Toutefois, vous pouvez également étendre Cloud Deploy pour utiliser d'autres fournisseurs de métriques. Ce document explique comment configurer et utiliser un job d'analyse, ainsi que les exigences relatives à un conteneur personnalisé incluant la logique permettant d'analyser les métriques du fournisseur de votre choix.

Avant de commencer

  1. Connectez-vous à votre compte Google.

    Si vous n'en possédez pas déjà un, vous devez en créer un.

  2. Installez la Google Cloud CLI.

  3. Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.

  4. Pour initialiser la gcloud CLI, exécutez la commande suivante :

    gcloud init
  5. Vérifiez que vous disposez des autorisations requises pour suivre les instructions de ce guide.

  6. Vérifiez que la facturation est activée pour votre projet Google Cloud .

  7. Activez les API Compute Engine et Cloud Deploy :

    Rôles requis pour activer les API

    Pour activer les API, vous avez besoin du rôle IAM Administrateur Service Usage (roles/serviceusage.serviceUsageAdmin), qui contient l'autorisation serviceusage.services.enable. Découvrez comment attribuer des rôles.

    gcloud services enable clouddeploy.googleapis.com  compute.googleapis.com
  8. Installez la Google Cloud CLI.

  9. Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.

  10. Pour initialiser la gcloud CLI, exécutez la commande suivante :

    gcloud init
  11. Vérifiez que vous disposez des autorisations requises pour suivre les instructions de ce guide.

  12. Vérifiez que la facturation est activée pour votre projet Google Cloud .

  13. Activez les API Compute Engine et Cloud Deploy :

    Rôles requis pour activer les API

    Pour activer les API, vous avez besoin du rôle IAM Administrateur Service Usage (roles/serviceusage.serviceUsageAdmin), qui contient l'autorisation serviceusage.services.enable. Découvrez comment attribuer des rôles.

    gcloud services enable clouddeploy.googleapis.com  compute.googleapis.com

Rôles requis

Pour obtenir les autorisations nécessaires pour créer et utiliser des jobs d'analyse, demandez à votre administrateur de vous accorder les rôles IAM suivants sur le compte de votre projet :

Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

Pour vous assurer que le compte de service Cloud Deploy dispose des autorisations nécessaires pour créer et utiliser des jobs d'analyse, demandez à votre administrateur d'accorder les rôles IAM suivants au compte de service Cloud Deploy dans votre projet :

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Votre administrateur peut également attribuer au compte de service Cloud Deploy les autorisations requises à l'aide de rôles personnalisés ou d'autres rôles prédéfinis.

Configurer un job d'analyse personnalisé

Un job d'analyse personnalisé est identique à un job d'analyse qui utilise des alertes de Google Cloud Observability, mais le job personnalisé utilise une ou plusieurs tâches qui font référence à des conteneurs personnalisés et aux commandes à exécuter sur ces conteneurs pour traiter les données de votre fournisseur de métriques.

Cette section explique comment configurer un job d'analyse Cloud Deploy qui utilise un fournisseur de surveillance autre queGoogle Cloud .

La strophe analysis peut être utilisée directement dans une configuration de stratégie de déploiement (strategy.standard.analysis, pour une stratégie standard). Si vous souhaitez configurer l'analyse par phase, vous devez utiliser une configuration Canary personnalisée (strategy.canary.customCanaryDepolyment.phaseConfigs.phaseId.analysis).

strategy:
  standard:
    analysis:
      duration: DURATION
      customChecks:
      - id: CHECK_ID
        frequency: FREQUENCY
        task:
          type: container
          image: IMAGE_NAME
          command: COMMAND
          args: [ARGS]
          env:
            [VAR_NAME: VALUE]

Où :

  • DURATION

    Durée d'exécution du job d'analyse, en secondes. Une fois la durée écoulée, le job est terminé. Si l'analyse échoue (le conteneur renvoie un code de sortie non nul), le job se termine (FAILED) avant l'expiration de la durée.

  • CHECK_ID

    Identifiant du contrôle individuel. Cet ID doit être unique dans ce job d'analyse.

  • FREQUENCY

    Indique la fréquence (en secondes) à laquelle exécuter la vérification individuelle.

  • IMAGE_NAME

    Il s'agit du chemin d'accès et du nom qui identifient votre image de conteneur.

  • COMMAND

    Il s'agit de la commande à exécuter sur ce conteneur, par exemple un script shell (/bin/bash).

  • ARGS

    Il s'agit d'une liste d'arguments pour cette commande. Il s'agit d'une liste d'éléments séparés par une virgule. 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 appelez.

  • VAR_NAME

    est le nom d'une variable d'environnement à transmettre au conteneur. Vous utilisez des variables d'environnement pour configurer le comportement du conteneur. En d'autres termes, les variables et leurs valeurs indiquent au conteneur ce qu'il doit surveiller spécifiquement dans le fournisseur de métriques.

    Vous pouvez utiliser des paramètres système comme variables d'environnement ici.

  • VALUE

    Il s'agit de la valeur de chaque variable d'environnement. Cloud Deploy ne fait rien avec ces variables d'environnement, si ce n'est les transmettre, avec leurs valeurs, à votre conteneur. Il appartient à votre conteneur d'utiliser les valeurs dans votre logique d'analyse.

Chaque vérification dans une définition d'analyse personnalisée inclut une tâche qui fait référence à un conteneur, à la ou aux commandes à exécuter sur ce conteneur, et à toutes les variables d'environnement applicables à transmettre à ce conteneur.

Conteneur personnalisé

Pour l'analyse personnalisée, le conteneur que vous fournissez est responsable de l'analyse des données de télémétrie, des journaux ou d'autres données du fournisseur de métriques que vous utilisez. La tâche d'analyse Cloud Deploy attend le code de retour du conteneur.

Fonctionnalités du conteneur personnalisé

Le conteneur personnalisé est chargé d'ingérer les données de votre fournisseur de métriques, de déterminer si les métriques, les journaux ou d'autres données indiquent que l'application fonctionne correctement, et de renvoyer les résultats à Cloud Deploy.

Ce que le conteneur personnalisé doit renvoyer

Cloud Deploy n'exige rien du conteneur personnalisé, si ce n'est qu'il renvoie un code de sortie nul ou non nul. Si le conteneur renvoie un code de sortie différent de zéro, l'analyse échoue.

Le conteneur peut écrire les résultats dans un fichier nommé results.json (au format JSON), situé dans le bucket Cloud Storage fourni par Cloud Deploy. Le fichier contiendra les métadonnées sous forme de paires clé/valeur. Cette étape n'est pas obligatoire.

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