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 d'un conteneur personnalisé incluant la logique d'analyse des métriques du fournisseur de votre choix.

Avant de commencer

  1. Installez la Google Cloud CLI.

  2. Configurez la gcloud CLI afin d'utiliser votre identité fédérée.

    Pour en savoir plus, consultez Se connecter à la gcloud CLI avec votre identité fédérée.

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

    gcloud init

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

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

  6. Activez les API Compute Engine et Cloud Deploy si elles ne le sont pas déjà :

    Rôles requis pour activer les API

    Pour activer des API, vous devez disposer de l'autorisation serviceusage.services.enable. Si vous avez créé le projet, vous disposez probablement déjà de cette autorisation via le rôle Propriétaire (roles/owner). Sinon, vous pouvez l'obtenir via le rôle Administrateur Service Usage (roles/serviceusage.serviceUsageAdmin). 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 sur 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 un canary personnalisé (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

    Il s'agit de l'ID du contrôle individuel. Cet ID doit être unique dans ce job d'analyse.

  • FREQUENCY

    Fréquence d'exécution de la vérification individuelle (en secondes).

  • 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

    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 est -c, et un autre argument est la commande entière que vous souhaitez exécuter dans l'interface système que vous appelez.

  • VAR_NAME

    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. C'est à 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 chargé d'analyser la télémétrie, les 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.

Ce que le conteneur personnalisé doit faire

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 non nul, 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 job de validation ou votre cible personnalisée pour le rendu ou le déploiement.

  • ANTHOS_MEMBERSHIP

    Pour les cibles de type ANTHOS, le nom de ressource entièrement spécifié de l'appartenance Anthos.

  • CLOUD_RUN_LOCATION

    Pour les cibles de type RUN, 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. Valeurs possibles : GKE, ANTHOS ou RUN. Pour les cibles personnalisées, ce paramètre n'est pas défini.

  • 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 du projet Google Cloud 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 seront exécutés.

  • CLOUD_DEPLOY_ROLLOUT

    ID du déploiement contenant les jobs pour les hooks.

  • CLOUD_DEPLOY_JOB_RUN

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

  • CLOUD_DEPLOY_PHASE

    La phase du déploiement qui contient le job pour le hook de déploiement, le job de validation ou le rendu ou déploiement personnalisé.

Étapes suivantes