Documentation de référence du schéma de configuration

Le ou les fichiers de configuration Cloud Deploy définissent le pipeline de diffusion, les cibles vers lesquelles effectuer le déploiement et la progression de ces cibles.

Le fichier de configuration du pipeline de livraison peut inclure des définitions de cibles, ou celles-ci peuvent se trouver dans un ou plusieurs fichiers distincts. Par convention, un fichier contenant à la fois la configuration du pipeline de déploiement et les configurations cibles est appelé clouddeploy.yaml, et une configuration de pipeline sans cibles est appelée delivery-pipeline.yaml. Toutefois, vous pouvez leur donner le nom de votre choix. D'autres définitions de ressources, telles que les automations et les deploy policies, peuvent également figurer dans le même fichier qu'une définition de pipeline de livraison ou de cible.

Configuration matérielle

Cloud Deploy utilise deux principaux fichiers de configuration :

Il peut s'agir de fichiers distincts, ou le pipeline de livraison et les cibles peuvent être configurés dans le même fichier.

Structure d'un fichier de configuration de pipeline de livraison

Vous trouverez ci-dessous la structure d'une configuration de pipeline de livraison, y compris les propriétés des définitions cibles. Certaines propriétés cibles ne sont pas incluses ici. Consultez Définitions des cibles pour connaître toutes les propriétés de configuration des cibles.

# Delivery pipeline config
apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
 name:
 annotations:
 labels:
description:
suspended:
serialPipeline:
 stages:
 - targetId:
   profiles: []
# Deployment strategies
# One of:
#   standard:
#   canary:
# See the strategy section in this document for details.
   strategy:
     standard:
       predeploy:
         tasks: []
       verify:
         tasks: []
       analysis:
       postdeploy:
         tasks: []
   deployParameters:
   - values:
     matchTargetLabels:
 - targetId:
   profiles: []
   strategy:
   deployParameters:
---

# Target config
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
 name:
 annotations:
 labels:
description:
multiTarget:
 targetIds: []
deployParameters:
requireApproval:
#
# Runtimes
# one of the following runtimes:
gke:
 cluster:
 dnsEndpoint:
 internalIp:
 proxyUrl:
#
# or:
anthosCluster:
 membership:
#
# or:
run:
 location:
#
# or:
customTarget:
  customTargetType:
#
# (End runtimes. See documentation in this article for more details.)
#
executionConfigs:
- usages:
  - [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY | ANALYSIS]
  workerPool:
  serviceAccount:
  artifactStorage:
  executionTimeout:
  verbose:
---

# Custom target type config
apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
  name:
  annotations:
  labels:
description:
tasks:
  render:
  deploy:
---

# Automation config
apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name:
  labels:
  annotations:
description:
suspended:
serviceAccount:
selector:
  targets:
    -  id: [TARGET_ID]
       labels:
         [LABEL_KEY]:[LABEL_VALUE]
rules:
- [RULE_TYPE]:
  id:
  [RULE-SPECIFIC_CONFIG]

Ce fichier YAML comporte trois composants principaux :

  • Pipeline de livraison principal et progression

    Le fichier de configuration peut inclure un nombre illimité de définitions de pipeline.

  • Définitions des cibles

    Par souci de simplicité, un seul groupe cible est présenté dans cet exemple, mais il peut y en avoir autant que vous le souhaitez. Les cibles peuvent également être définies dans un ou plusieurs fichiers distincts.

  • Définitions des types de cibles personnalisées

    Les cibles personnalisées nécessitent une définition de type de cible personnalisée. Comme pour les cibles et les automatisations, les types de cibles personnalisés peuvent être définis dans le même fichier que le pipeline de diffusion ou dans un fichier distinct.

  • Définitions de l'automatisation

    Vous pouvez créer des automatisations de déploiement dans le même fichier que votre pipeline de diffusion et vos cibles, ou dans un ou plusieurs fichiers distincts. Pour plus de simplicité, un seul Automation est affiché ici, mais vous pouvez en créer autant que vous le souhaitez.

Ces composants sont définis dans le reste de ce document.

Définition et progression du pipeline

En plus des métadonnées du pipeline, telles que name, la définition du pipeline principal inclut une liste de références aux cibles dans l'ordre de la séquence de déploiement. En d'autres termes, la première cible listée est la première cible de déploiement. Une fois le déploiement effectué sur cette cible, la promotion de la version permet de la déployer sur la cible suivante de la liste.

Vous trouverez ci-dessous les propriétés de configuration d'un pipeline de diffusion, à l'exclusion des définitions de cibles.

metadata.name

Le champ name accepte une chaîne qui doit être unique par projet et par emplacement.

metadata.annotations et metadata.labels

La configuration du pipeline de livraison peut inclure des annotations et des libellés. Les annotations et les libellés sont stockés avec la ressource de pipeline de diffusion une fois le pipeline enregistré.

Pour en savoir plus, consultez Utiliser des libellés et des annotations avec Cloud Deploy.

description

Chaîne arbitraire décrivant ce pipeline de livraison. Cette description s'affiche dans les détails du pipeline de livraison dans la console Google Cloud .

suspended

Valeur booléenne qui, si elle est définie sur true, suspend le pipeline de déploiement de sorte qu'il ne peut pas être utilisé pour créer, promouvoir, annuler ou redéployer des versions. De plus, si le pipeline de livraison est suspendu, vous ne pouvez pas approuver ni refuser un déploiement créé à partir de ce pipeline.

La valeur par défaut est false.

serialPipeline

Début de la définition d'un pipeline de diffusion à progression séquentielle. Cette strophe est obligatoire.

stages

Liste de toutes les cibles vers lesquelles ce pipeline de déploiement est configuré pour le déploiement.

La liste doit être dans l'ordre de la séquence de diffusion souhaitée. Par exemple, si vous avez des cibles appelées dev, staging et production, listez-les dans le même ordre, de sorte que votre premier déploiement soit sur dev et votre dernier déploiement sur production.

Renseignez chaque champ stages.targetId avec la valeur du champ metadata.name dans la définition de cible correspondante. Sous targetId, incluez profiles :

serialPipeline:
 stages:
 - targetId:
   profiles: []
   strategy:
     standard:
       verify:

targetId

Identifie la cible spécifique à utiliser pour cette étape du pipeline de déploiement. La valeur correspond à la propriété metadata.name de la définition de la cible.

Si strategy.standard.verify est défini sur true, la validation du déploiement est activée sur la cible. Si aucune stratégie de déploiement n'est spécifiée, la stratégie de déploiement standard est utilisée, avec la validation définie sur false.

profiles

Accepte une liste de zéro ou plusieurs noms de profils Skaffold, à partir de skaffold.yaml. Cloud Deploy utilise le profil avec skaffold render lors de la création de la version. Les profils Skaffold vous permettent de varier la configuration entre les cibles tout en utilisant un seul fichier de configuration.

strategy

Inclut des propriétés permettant de spécifier une stratégie de déploiement. Les stratégies suivantes sont acceptées :

  • standard:

    L'application est entièrement déployée sur la cible spécifiée.

    Il s'agit de la stratégie de déploiement par défaut. Si vous omettez strategy, Cloud Deploy utilise la stratégie de déploiement standard.

  • canary:

    Dans un déploiement Canary, vous déployez progressivement une nouvelle version de votre application, en remplaçant la version déjà en cours d'exécution par incréments en pourcentage (par exemple, 25 %, puis 50 %, puis 75 %, puis complètement).

La stratégie de déploiement est définie par cible. Par exemple, vous pouvez avoir une stratégie canary pour votre cible prod, mais une stratégie standard (sans strategy spécifié) pour vos autres cibles.

Pour en savoir plus, consultez Utiliser une stratégie de déploiement.

Configuration du réseau strategy

Cette section présente les éléments de configuration de strategy pour chaque environnement d'exécution compatible.

Stratégie de déploiement standard

La stratégie standard n'inclut que les éléments suivants :

strategy:
  standard:
    verify:
      tasks: []
    analysis:

La propriété verify vous permet de référencer une ou plusieurs tâches à exécuter pour valider votre déploiement. Si elles sont configurées, les tâches de validation s'exécutent de manière séquentielle, immédiatement après le job de déploiement.

La propriété verify est facultative. Si aucune tâche verify n'est spécifiée, il n'y en aura pas dans les déploiements résultants.

La section analysis est facultative et doit être utilisée avec l'analyse Cloud Deploy.

Vous pouvez omettre l'élément strategy pour une stratégie de déploiement standard.

Stratégie de déploiement Canary

Les sections suivantes décrivent la configuration d'une stratégie de déploiement Canary pour chaque environnement d'exécution compatible avec Cloud Deploy.

Pour les cibles Cloud Run
strategy:
  canary:
    runtimeConfig:
      cloudRun:
        automaticTrafficControl: true | false
    canaryDeployment:
      percentages: [PERCENTAGES]
      verify:
        tasks: []
      analysis:

Pour les cibles Cloud Run, AutomaticTrafficControl doit être true, sauf si vous configurez un canari personnalisé.

Pour les cibles GKE et les clusters associés à GKE

Le fichier YAML suivant montre comment configurer une stratégie de déploiement pour une cible qui effectue un déploiement sur des clusters GKE ou GKE associés, à l'aide de la mise en réseau basée sur les services :

      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              disablePodOverprovisioning: true | false
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify:
            tasks: []

Le fichier YAML suivant montre comment configurer une stratégie de déploiement pour une cible qui se déploie sur des clusters GKE ou GKE associés, à l'aide de l'API Gateway :

      canary:
        runtimeConfig:
          kubernetes:
            gatewayServiceMesh:
              httpRoute: "HTTP_ROUTE_NAME"
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              routeUpdateWaitTime: "WAIT_TIME"
              routeDestinations:
                destinationIds: ["KEY"]
                propagateService: [true|false]
        canaryDeployment:
          percentages: ["PERCENTAGES"]
          verify:
            tasks: []

Dans cet exemple, notez routeUpdateWaitTime. Cette étape est incluse, car l'API Gateway répartit le trafic à l'aide d'une ressource HTTPRoute. Parfois, la propagation des modifications apportées à HTTPRoute prend du temps. Dans ce cas, les requêtes peuvent être abandonnées, car le trafic est envoyé à des ressources indisponibles. Vous pouvez utiliser routeUpdateWaitTime pour que Cloud Deploy attende après l'application des modifications HTTPRoute, si vous constatez ce délai.

Le fichier YAML suivant montre comment configurer une stratégie de déploiement canary personnalisée (pour Service Networking, Gateway API ou Cloud Run) ou une stratégie de déploiement canary automatisée personnalisée (pour Service Networking, Gateway API ou Cloud Run). La configuration spécifique au runtime, dans la section runtimeConfig, est omise pour le canary personnalisé, mais incluse dans la configuration du canary automatisé et du canary automatisé personnalisé.

Configuration Canary personnalisée

strategy:
  canary:
    # Runtime configs are configured as shown in the
    # Canary Deployment Strategy section of this document.
    runtimeConfig:

    # Manual configuration for each canary phase
    customCanaryDeployment:
      - name: "PHASE1_NAME"
        percent: PERCENTAGE1
        profiles: [ "PROFILE1_NAME" ]
        verify:
          tasks: []
      - …
      - name: "stable"
        percent: 100
        profiles: [ "LAST_PROFILE_NAME" ]
        analysis: [ANALYSIS_CONFIGS]
        verify:
          tasks: []

verify

La strophe verify peut être incluse sous strategy.standard, strategy.canary.canaryDeployment ou sous chaque phase dans strategy.canary.customCanaryDeployment. Il permet d'activer la validation du déploiement pour une cible. Cette strophe est facultative. Si elle est omise, aucune vérification n'est effectuée pour la phase de déploiement ou de test Canary.

Vous pouvez configurer verify de deux manières :

  • Définissez verify: true.

    Dans ce cas, vous devez également configurer une strophe verify dans votre skaffold.yaml, comme décrit dans Configurer Skaffold pour la validation.

  • Configurez verify à l'aide d'une ou de plusieurs tâches à exécuter pour la validation :

    verify:
  tasks: [VERIFY_TASKS]

analysis

L'analyse du déploiement, que vous pouvez utiliser pour exécuter une ou plusieurs vérifications sur les alertes Google Cloud Observability, est configurée dans une section strategy. Pour en savoir plus sur la configuration, consultez Définitions d'analyse.

deployParameters

Vous permet de spécifier des paires clé/valeur pour transmettre des valeurs aux manifestes pour les cibles correspondant aux libellés, lorsque vous utilisez des paramètres de déploiement.

Vous pouvez également l'inclure dans les cibles.

Les paramètres de déploiement définis sur un pipeline de livraison utilisent des libellés pour faire correspondre les cibles :

deployParameters:
- values:
    someKey: "value1"
  matchTargetLabels:
    label1: firstLabel
- values:
    someKey: "value2"
  matchTargetLabels:
    label2: secondLabel

Dans cet exemple, deux valeurs sont fournies pour la clé, et un libellé est associé à chacune d'elles. La valeur est appliquée au fichier manifeste pour toute cible portant un libellé correspondant.

predeploy et postdeploy jobs

Les hooks de prédéploiement et de post-déploiement sont des tâches à exécuter avant ou après la tâche de déploiement dans un déploiement. Vous pouvez définir des hooks predeploy et postdeploy de deux manières :

Les jobs de pré-déploiement s'exécutent immédiatement avant le job de déploiement dans un déploiement progressif. Les jobs post-déploiement s'exécutent après tous les autres jobs du déploiement, y compris les jobs de vérification et d'analyse, le cas échéant.

Les hooks de déploiement sont configurés sous strategy.standard ou strategy.canary comme suit :

  • Utiliser tasks

    serialPipeline:
  stages:
  - targetId:
    strategy:
      standard:
        predeploy:
          tasks: [PREDEPLOY_TASKS]
        postdeploy:
          tasks: [POSTDEPLOY_TASKS]

    Où :

    • PREDEPLOY_TASKS correspond à une ou plusieurs tâches que vous souhaitez exécuter dans votre hook de pré-déploiement.

    • POSTDEPLOY_TASKS correspond à une ou plusieurs tâches que vous souhaitez exécuter dans votre hook post-déploiement.

  • Utiliser actions (et Skaffold)

    serialPipeline:
  stages:
  - targetId:
    strategy:
      standard:
        predeploy:
          actions: [ACTION_NAME]
        postdeploy:
          actions: [ACTION_NAME]

    Où ACTION_NAME est le nom configuré dans skaffold.yaml pour customActions.name.

    Vous pouvez configurer des jobs predeploy et postdeploy sous n'importe quelle stratégie (standard, canary, par exemple).

Pour en savoir plus sur la configuration et l'utilisation des hooks avant et après le déploiement, consultez Exécuter des hooks avant et après le déploiement.

Définitions des cibles

Le fichier de définition du pipeline de diffusion peut contenir des définitions de cibles, ou vous pouvez spécifier des cibles dans un fichier distinct.

Vous pouvez réutiliser des cibles dans plusieurs pipelines de diffusion. Toutefois, vous ne pouvez référencer une cible qu'une seule fois dans la progression d'un même pipeline de livraison.

Consultez également Définitions des types de cibles personnalisés.

Pour les cibles GKE

Le fichier YAML suivant montre comment configurer une cible qui déploie sur un cluster GKE :

     apiVersion: deploy.cloud.google.com/v1
     kind: Target
     metadata:
      name:
      annotations:
      labels:
     description:
     deployParameters:
     multiTarget:
      targetIds: []

     requireApproval:
     gke:
      cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
      dnsEndpoint:
      internalIp:
      proxyUrl:

     associatedEntities:
       [KEY]:
         gkeClusters:
         - cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
           dnsEndpoint: [true|false]
           internalIp: [true|false]
           proxyUrl:

     executionConfigs:
     - usages:
       - [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY | ANALYSIS]
       workerPool:
       serviceAccount:
       artifactStorage:
       executionTimeout:
       verbose:

metadata.name

Nom de cette cible. Ce nom doit être unique par région.

metadata.annotations et metadata.labels

La configuration cible accepte les annotations Kubernetes et les libellés, mais Cloud Deploy ne les requiert pas.

Les annotations et les libellés sont stockés avec la ressource cible. Pour en savoir plus, consultez Utiliser des libellés et des annotations avec Cloud Deploy.

description

Ce champ accepte une chaîne arbitraire décrivant l'utilisation de cette cible.

deployParameters

Vous pouvez inclure des paramètres de déploiement sur n'importe quelle cible, ainsi que des valeurs. Ces valeurs sont attribuées aux clés correspondantes de votre fichier manifeste après le rendu.

La strophe deployParameters accepte les paires clé-valeur, comme indiqué ci-dessous :

deployParameters:
  someKey: "someValue"
  someOtherKey: "someOtherValue"

Si vous définissez des paramètres de déploiement sur un multicible, la valeur est attribuée au fichier manifeste de toutes les cibles enfants de ce multicible.

multiTarget.targetIds: []

Cette propriété est facultative et permet de configurer un multi-target à utiliser pour le déploiement parallèle.

La valeur est une liste de cibles enfants séparées par une virgule. Les cibles enfants sont configurées comme des cibles normales et n'incluent pas cette propriété multiTarget.

requireApproval

Indique si la promotion vers cette cible nécessite une approbation manuelle. Il peut s'agir de true ou false.

Cette propriété est facultative. La valeur par défaut est false.

Lorsque vous configurez un déploiement parallèle, vous pouvez exiger une approbation uniquement pour la multicible, et non pour les cibles enfants.

gke

Pour les clusters GKE uniquement, chemin d'accès à la ressource identifiant le cluster sur lequel votre application sera déployée :

gke:
  cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]

  • project_name

    Le projet Google Cloud dans lequel réside le cluster.

  • location

    Emplacement du cluster. Par exemple, us-central1. Le cluster peut également être zonal (us-central1-c).

  • cluster_name

    Nom du cluster tel qu'il apparaît dans la liste des clusters de la consoleGoogle Cloud .

Exemple :

gke:
  cluster: projects/cd-demo-01/locations/us-central1/clusters/prod

Omettez la propriété gke lorsque vous configurez un multi-target. Le cluster GKE est configuré dans la cible enfant correspondante.

Pour obtenir la description des propriétés de l'environnement d'exécution, consultez executionConfigs dans ce document. Pour savoir comment déployer la ressource HTTPRoute dans un autre cluster que celui cible, consultez Déployer une ressource HTTPRoute dans un autre cluster.

associatedEntities.[KEY]

Dans une configuration canary, vous utilisez ce nom pour faire référence aux entités de routeDestinations. En savoir plus

dnsEndpoint

Lorsque la valeur est définie sur true, Cloud Deploy se connecte au cluster GKE à l'aide du point de terminaison DNS au lieu du point de terminaison par défaut, qui peut être une adresse IP publique, une adresse IP privée ou le point de terminaison DNS, selon la configuration du cluster.

Cette option ne peut pas être utilisée en même temps que l'option internalIp.

internalIp

Lorsque la valeur est définie sur true, Cloud Deploy se connecte au cluster GKE à l'aide de l'adresse IP privée au lieu du point de terminaison par défaut, qui peut être une adresse IP publique, une adresse IP privée ou le point de terminaison DNS, selon la configuration du cluster.

Cette option ne peut pas être utilisée en même temps que l'option dnsEndpoint. Étant donné que la configuration réseau pour dnsEndpoint est beaucoup plus simple, nous vous recommandons de l'utiliser à la place.

proxyUrl

Si vous accédez aux clusters via un proxy HTTP, indiquez la propriété proxyUrl ici. La valeur correspond à l'URL du proxy, qui est transmise à kubectl lors de la connexion à votre cluster.

Pour les cibles Cloud Run

Le code YAML suivant montre comment configurer une cible qui déploie un service Cloud Run :

     apiVersion: deploy.cloud.google.com/v1
     kind: Target
     metadata:
      name:
      annotations:
      labels:
     description:
     multiTarget:
      targetIds: []

     requireApproval:
     run:
      location: projects/[project_name]/locations/[location]

     executionConfigs:
     - usages:
       - [RENDER | PREDEPLOY|  DEPLOY | VERIFY | POSTDEPLOY | ANALYSIS]
       workerPool:
       serviceAccount:
       artifactStorage:
       executionTimeout:
       verbose:

metadata.name

Nom de cette cible. Ce nom doit être unique par région.

metadata.annotations et metadata.labels

La configuration cible accepte les annotations et les libellés, mais Cloud Deploy ne les requiert pas.

Les annotations et les libellés sont stockés avec la ressource cible. Pour en savoir plus, consultez Utiliser des libellés et des annotations avec Cloud Deploy.

description

Ce champ accepte une chaîne arbitraire décrivant l'utilisation de cette cible.

multiTarget.targetIds: []

Cette propriété est facultative et permet de configurer un multi-target à utiliser pour le déploiement parallèle.

La valeur est une liste de cibles enfants séparées par une virgule. Les cibles enfants sont configurées comme des cibles normales et n'incluent pas cette propriété multiTarget.

requireApproval

Indique si la promotion vers cette cible nécessite une approbation manuelle. Il peut s'agir de true ou false.

Cette propriété est facultative. La valeur par défaut est false.

Lorsque vous configurez un déploiement parallèle, vous pouvez exiger une approbation uniquement pour la multicible, et non pour les cibles enfants.

run

Pour les services Cloud Run uniquement, il s'agit de l'emplacement où le service sera créé :

run:
  location: projects/[project_name]/locations/[location]

  • project_name

    Le projet Google Cloud dans lequel le service sera hébergé.

  • location

    Emplacement où le service sera disponible. Par exemple, us-central1.

Omettez la propriété run lorsque vous configurez un [multi-target]. L'emplacement du service Cloud Run est configuré dans la cible enfant correspondante.

Pour obtenir la description des propriétés de l'environnement d'exécution, consultez executionConfigs dans cet article.

Pour les cibles de clusters associés à GKE

La configuration cible pour déployer sur des clusters GKE associés est semblable à la configuration d'une cible GKE, sauf que la propriété est anthosCluster.membership au lieu de gke.cluster, que le chemin d'accès aux ressources est différent et que les méthodes de connexion spécifiques (dnsEndpoint ou internalIp) ne sont pas applicables.

anthosCluster:
  membership: projects/[project_name]/locations/global/memberships/[membership_name]

  • project_name

    Le projet Google Cloud dans lequel réside le cluster.

  • /location/global/

    Emplacement où le cluster est enregistré. global, dans tous les cas.

  • membership_name

    Nom de l'appartenance au cluster.

Exemple :

anthosCluster:
  membership: projects/cd-demo-01/locations/global/memberships/prod

Omettez la propriété anthosCluster lorsque vous configurez un [multi-target]. Le cluster est configuré à l'intérieur de la cible enfant correspondante.

Pour en savoir plus sur le déploiement sur des clusters GKE associés, consultez Déployer sur des clusters GKE associés.

Pour les cibles personnalisées

La configuration des cibles personnalisées est semblable à celle de tous les autres types de cibles, sauf qu'elle n'inclut pas de strophe gke, run ni anthosCluster.

Les cibles personnalisées incluent plutôt une strophe customTarget :

customTarget:
  customTargetType: [CUSTOM_TARGET_TYPE_NAME]

Où CUSTOM_TARGET_TYPE_NAME est le nom que vous avez utilisé dans la définition du type de cible personnalisée.

Exemple :

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: sample-env
customTarget:
  customTargetType: basic-custom-target

executionConfigs

Ensemble de champs permettant de spécifier un environnement d'exécution non défini par défaut pour cette cible.

  • usages

    RENDER ou DEPLOY, ou les deux, plus PREDEPLOY, VERIFY ou POSTDEPLOY si les crochets de validation ou de déploiement sont activés sur la cible. Elles indiquent les opérations à effectuer pour cette cible à l'aide de cet environnement d'exécution. Pour indiquer qu'un environnement d'exécution personnalisé doit être utilisé pour le hook de prédéploiement, le rendu, le déploiement, le hook de post-déploiement et la validation, vous devez le configurer comme suit :

    usages:
- RENDER
- PREDEPLOY
- DEPLOY
- VERIFY
- POSTDEPLOY
- ANALYSIS

    Si la validation est activée dans la phase du pipeline et que vous ne spécifiez pas VERIFY dans une strophe usages, Cloud Deploy utilise l'environnement d'exécution par défaut pour la validation. Les crochets de pré-déploiement et de post-déploiement fonctionnent de la même manière.

    Toutefois, s'il existe un environnement d'exécution personnalisé pour RENDER et DEPLOY, vous devez en spécifier un pour VERIFY, PREDEPLOY, POSTDEPLOY ou ANALYSIS s'ils sont configurés dans le pipeline de diffusion.VERIFY, PREDEPLOY, POSTDEPLOY et ANALYSIS peuvent se trouver dans le même usages que RENDER ou DEPLOY, ou dans des usages distincts.

    Vous ne pouvez pas spécifier usages.VERIFY, usages.PREDEPLOY, usages.POSTDEPLOY ni usages.ANALYSIS, sauf si RENDER et DEPLOY sont spécifiés dans le même environnement d'exécution personnalisé ou dans des environnements d'exécution personnalisés distincts.

  • workerPool

    Configuration à utiliser pour le pool de nœuds de calcul. Il s'agit d'un chemin d'accès à la ressource qui identifie le pool de nœuds de calcul Cloud Build à utiliser pour cette cible. Exemple :

    projects/p123/locations/us-central1/workerPools/wp123.

    Pour utiliser le pool Cloud Build par défaut, omettez cette propriété.

    Une cible donnée peut avoir deux workerPool (un pour RENDER et un pour DEPLOY). Lorsque vous configurez le pool par défaut, vous pouvez spécifier un autre compte de service ou un autre emplacement de stockage, ou les deux.

  • serviceAccount

    Nom du compte de service à utiliser pour cette opération (RENDER ou DEPLOY) pour cette cible.

  • artifactStorage

    Bucket Cloud Storage à utiliser pour cette opération (RENDER ou DEPLOY) pour cette cible, au lieu du bucket par défaut.

  • executionTimeout

    Facultatif. Définit le délai avant expiration, en secondes, pour les opérations que Cloud Build effectue pour Cloud Deploy. Par défaut, cette valeur est de 3600 secondes (1 heure).
    Exemple : executionTimeout: "5000s"

  • verbose

    Facultatif. Si la valeur est true, les niveaux de verbosité sont définis sur debug pour les outils suivants :

    • Skaffold --verbosity est défini sur debug. La valeur par défaut de Skaffold est warn.

    • kubectl --v est défini sur 4, qui est le mode débogage. La valeur par défaut de kubectl est 2.

    • Google Cloud CLI --verbosity est défini sur debug. La valeur par défaut est warning.

Autre syntaxe acceptée

La configuration executionConfigs décrite dans ce document est nouvelle. L'ancienne syntaxe est toujours acceptée :

executionConfigs:
- privatePool:
    workerPool:
    serviceAccount:
    artifactStorage:
  usages:
  - [RENDER | DEPLOY]
- defaultPool:
    serviceAccount:
    artifactStorage:
  usages:
  - [RENDER | DEPLOY]

Lorsque vous configurez une strophe executionConfigs pour un groupe multicible, chaque cible enfant peut hériter de cet environnement d'exécution à partir de ce groupe multicible.

Définitions des types de cibles personnalisées

Cette section décrit les champs utilisés pour définir des types de cibles personnalisés.

Comme pour les cibles et les automatisations standards, les définitions CustomTargetType peuvent être incluses dans la définition de votre pipeline de diffusion, ou dans un ou plusieurs fichiers distincts.

Le code YAML suivant montre comment configurer un type de cible personnalisé :

apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
  name: [CUSTOM_TARGET_TYPE_NAME]
  annotations:
  labels:
description:
customActions:
  renderAction: [RENDER_ACTION_NAME]
  deployAction: [DEPLOY_ACTION_NAME]
  includeSkaffoldModules:
    - configs:
    # either:
    googleCloudStorage:
      source:
      path:
    # or:
    git:
      repo:
      path:
      ref:

Où :

  • [CUSTOM_TARGET_TYPE_NAME]

    Nom arbitraire que vous attribuez à cette définition de type de ciblage personnalisé. Ce nom est référencé dans la définition de la cible pour toute cible qui utilise le type de cible personnalisée que vous définissez.

  • [RENDER_ACTION_NAME]

    Nom de l'action de rendu personnalisée. Cette valeur correspond à la customAction.name définie dans skaffold.yaml.

  • [DEPLOY_ACTION_NAME]

    Nom de l'action de déploiement personnalisée. Cette valeur correspond à la customAction.name définie dans skaffold.yaml.

  • Pour includeSkaffoldModules, consultez Utiliser des configurations Skaffold à distance.

Définitions de l'automatisation

Cette section décrit les champs utilisés pour définir les ressources d'automatisation Cloud Deploy.

Comme pour les cibles, les définitions Automation peuvent être incluses dans la définition de votre pipeline de livraison, ou dans un ou plusieurs fichiers distincts.

Pour en savoir plus sur l'automatisation dans Cloud Deploy, consultez la documentation sur l'automatisation.

Le code YAML suivant montre comment configurer une automatisation. Notez que les spécificités d'une règle d'automatisation varient selon la règle. (La configuration des types de règles d'automatisation disponibles est décrite dans le document Utiliser des règles d'automatisation.)

apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name: [PIPELINE_NAME]/[PURPOSE]
  labels:
  annotations:
description: [DESCRIPTION]
suspended: true | false
serviceAccount: [SERVICE_ACCOUNT_ID]
selector:
  targets:
    -  id: [TARGET_ID]
       labels:
         [LABEL_KEY]:[LABEL_VALUE]

rules:
- [RULE_TYPE]:
    id:[RULE_NAME]
  [RULE-SPECIFIC_CONFIG]

Où :

  • [PIPELINE_NAME]

    Identique à la valeur metadata.name dans le pipeline de diffusion qui utilise cette automatisation. Toutes les automatisations sont exclusives aux pipelines de livraison pour lesquels elles ont été créées. En d'autres termes, vous ne pouvez pas partager une automatisation sur plusieurs pipelines de livraison.

  • [PURPOSE]

    Nom descriptif supplémentaire pour cette automatisation. Il s'agit généralement de l'action automatisée. Par exemple, my-app-pipeline/promote.

  • labels et annotations correspondent aux libellés ou annotations que vous souhaitez associer à cette automatisation.

  • [DESCRIPTION]

    Description facultative de cette automatisation.

  • suspended

    true ou false, indiquant si l'automatisation est active ou suspendue. Si la valeur est définie sur true, l'automatisation n'est pas utilisée. Cela peut être utile pour tester une automatisation sans affecter le pipeline de diffusion.

  • [SERVICE_ACCOUNT_ID]

    ID du compte de service utilisé pour effectuer l'automatisation. Par exemple, si l'automatisation utilise promoteReleaseRule, ce compte de service effectue la promotion de la version et nécessite donc les autorisations requises pour promouvoir une version.

    Veuillez indiquer une valeur pour cette propriété. Cloud Deploy n'utilise pas le compte de service par défaut pour les automatisations.

    Ce compte de service doit disposer des autorisations suivantes :

    • Autorisation actAs pour emprunter l'identité du compte de service d'exécution.

    • autorisation pour effectuer l'opération automatisée, par exemple clouddeploy.releases.promote pour promouvoir une version ou clouddeploy.rollouts.advance pour faire passer une phase de déploiement à la suivante.

  • [TARGET_ID]

    ID de la cible pour laquelle cette automatisation est utilisée. Bien qu'une automatisation soit associée à un pipeline de livraison, elle n'est exécutée que sur la ou les cibles spécifiées.

    Vous pouvez définir ce paramètre sur * pour sélectionner toutes les cibles dans le pipeline de diffusion.

  • [LABEL_KEY]:[LABEL_VALUE]

    Paire clé-valeur à comparer à une paire clé-valeur définie sur la cible. Sélectionne toutes les cibles associées au pipeline de diffusion qui ont le même libellé et la même valeur.

  • [RULE_TYPE]

    Nom de la règle d'automatisation utilisée pour cette automatisation. Il peut s'agir de promoteReleaseRule, timedPromoteReleaseRule, advanceRolloutRule ou repairRolloutRule. Vous pouvez inclure plusieurs règles dans une automatisation, y compris plusieurs règles identiques RULE_TYPE. Par exemple, vous pouvez avoir plusieurs règles promoteReleaseRule dans la même automatisation. En savoir plus

  • [RULE_NAME]

    Nom de la règle. Ce nom doit être unique dans la ressource d'automatisation. Veuillez indiquer une valeur pour cette propriété.

  • [RULE-SPECIFIC_CONFIG]

    La configuration diffère pour chaque type d'automatisation compatible. Ces configurations sont présentées dans Utiliser des règles d'automatisation.

Déployer des définitions de règles

Cette section décrit les champs utilisés pour définir les stratégies de déploiement.

Comme pour les autres ressources Cloud Deploy, vous pouvez inclure des définitions DeployPolicy avec la définition de votre pipeline de déploiement ou dans un fichier distinct.

Le fichier YAML suivant montre comment configurer une stratégie de déploiement :

apiVersion: deploy.cloud.google.com/v1
kind: DeployPolicy
metadata:
  name: [POLICY_NAME]
  annotations: [ANNOTATIONS]
  labels: [LABELS]
description: [DESCRIPTION]
suspended: [true | false]
selectors:
- deliveryPipeline:
    id: [PIPELINE_ID]
    labels:
      [LABEL_KEY]:[LABEL_VALUE]
  target:
    id: [TARGET_ID]
    labels:
      [LABEL_KEY]:[LABEL_VALUE]
rules:
  - [RULE_TYPE]
      [CONFIGS]

Où :

  • [DESCRIPTION]

    Texte facultatif décrivant cette règle.

  • [POLICY_NAME]

    Nom de la règle. Ce champ accepte une chaîne qui doit être unique par projet et par emplacement. Il doit être composé de lettres minuscules, de chiffres et de traits d'union. Le premier caractère doit être une lettre, le dernier doit être une lettre ou un chiffre, et le nombre de caractères ne doit pas dépasser 63. Ce nom est utilisé comme nom à afficher dans la consoleGoogle Cloud .

  • [ANNOTATIONS] et [LABELS]

    Les règles peuvent inclure des annotations et des libellés, qui font partie de la ressource de règle une fois celle-ci créée. Pour en savoir plus, consultez Utiliser des annotations et des libellés avec Cloud Deploy.

  • suspended: [true | false]

    Si vous définissez suspended sur true, cette règle est désactivée.

  • [PIPELINE_ID]

    ID du pipeline de déploiement auquel vous souhaitez que cette règle s'applique. Vous pouvez utiliser * pour désigner tous les pipelines. Cet ID est identique à la propriété metadata.name du pipeline de diffusion.

  • [TARGET_ID]

    ID de la cible à laquelle vous souhaitez appliquer cette règle. Vous pouvez utiliser * pour désigner toutes les cibles. Cet ID est identique à la propriété metadata.name de la cible.

  • [LABEL_KEY]:[LABEL_VALUE]

    Paire clé/valeur à comparer à une paire clé/valeur définie sur le pipeline ou la cible de diffusion. Cette option permet de sélectionner tous les pipelines ou cibles qui ont le même libellé et la même valeur. Vous pouvez spécifier labels au lieu de id ou en plus de celui-ci.

  • [RULE_TYPE]

    Type de règle spécifique que vous configurez. La seule valeur valide est rolloutRestriction.

  • [CONFIGS]

    Il s'agit de l'ensemble des propriétés de configuration de la règle de stratégie spécifique que vous créez. La configuration des règles est décrite plus loin dans cette section de cette référence, pour chacune des règles disponibles.

Déployer des règles de stratégie

Cette section explique comment configurer chaque règle de stratégie de déploiement.

rolloutRestriction

La règle rolloutRestriction empêche Cloud Deploy d'effectuer certaines opérations sur les déploiements progressifs pendant la ou les périodes spécifiées, pour les pipelines de livraison et les cibles indiqués par selectors pour la règle de déploiement.

Le fichier YAML suivant montre comment configurer une règle rolloutRestriction :

rules:
- rolloutRestriction:
    id: [RULE_ID]
    actions:
    - [ACTIONS]
    invokers:
    - [INVOKERS]
    timeWindows:
      timeZone: [TIMEZONE]
      oneTimeWindows:
      - start: [START_DATE_TIME]
        end: [END_DATE_TIME]
      weeklyWindows:
      - daysOfWeek:
        - [DAY_OF_WEEK]
        - [DAY_OF_WEEK]
        startTime: [START_TIME]
        endTime: [END_TIME]

Où :

  • RULE_ID

    Identifiant de cette règle. Ce champ est obligatoire. Il doit être composé de lettres minuscules, de chiffres et de traits d'union. Le premier caractère doit être une lettre, le dernier caractère doit être une lettre ou un chiffre, et le nom ne doit pas comporter plus de 63 caractères. Il doit être unique dans la stratégie de déploiement.

  • ACTIONS

    Facultatif : actions de déploiement à limiter dans la règle. Si ce champ est vide, toutes les actions sont restreintes. Les valeurs possibles sont les suivantes :

    • ADVANCE

      Il n'est pas possible d'avancer les phases de déploiement.

    • APPROVE

      La promotion de déploiement ne peut pas être approuvée.

    • CANCEL

      Les déploiements ne peuvent pas être annulés.

    • CREATE

      Il est impossible de créer des déploiements.

    • IGNORE_JOB

      Les jobs ne peuvent pas être ignorés.

    • RETRY_JOB

      Il n'est pas possible de relancer les jobs.

    • ROLLBACK

      Les déploiements ne peuvent pas être annulés.

    • TERMINATE_JOBRUN

      Impossible d'arrêter les exécutions de jobs

  • INVOKERS

    La spécification d'invocateurs permet de filtrer l'application des règles selon que l'action restreinte a été appelée par un utilisateur ou par une automatisation de déploiement. Les valeurs valides sont les suivantes :

    • USER

      L'action est déclenchée par l'utilisateur. Par exemple, en créant un déploiement manuellement à l'aide d'une commande gcloud CLI.

    • DEPLOY_AUTOMATION

      Une action automatisée par Cloud Deploy.

    Vous pouvez spécifier l'une des valeurs ou les deux. La valeur par défaut, si vous ne spécifiez rien, est "both" (les deux).

  • TIMEZONE

    Fuseau horaire au format IANA dans lequel vous exprimez la période. Exemple :America/New_York Ce champ est obligatoire.

  • START_DATE_TIME

    Pour oneTimeWindows, la date et l'heure qui marquent le début de la période de restriction, au format "yyyy-mm-dd hh:mm". Pour le début de la journée, utilisez 00:00. Ce champ est obligatoire.

  • END_DATE_TIME

    Pour oneTimeWindows, la date et l'heure marquant la fin de la période de restriction, au format "yyyy-mm-dd hh:mm". Pour la fin de la journée, utilisez 24:00. Ce champ est obligatoire.

  • DAY_OF_WEEK

    Pour weeklyWindows, le jour de la semaine, SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY ou SATURDAY. Si vous laissez ce champ vide, il correspond à tous les jours de la semaine.

  • START_TIME

    Pour weeklyWindows, heure de début du jour de la semaine spécifié. Si vous incluez une heure de début, vous devez également inclure une heure de fin. Pour le début de la journée, utilisez 00:00.

  • END_TIME

    Pour weeklyWindows, l'heure de fin du jour de la semaine spécifié. Si vous incluez une heure de début, vous devez également inclure une heure de fin. Pour la fin de la journée, utilisez 24:00.

Définitions des analyses

Une strophe analysis vous permet de configurer un job d'analyse pour exécuter une ou plusieurs vérifications sur les alertes Google Cloud Observability, ou des données similaires provenant d'autres fournisseurs de surveillance, afin d'effectuer des actions en fonction de ces alertes.

La strophe analysis diffère selon que vous la configurez pour Google Cloud Observability ou pour un autre fournisseur utilisant l'analyse personnalisée.

analysis pour Google Cloud Observability

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).

analysis:
  duration: DURATION
  googleCloud:
    alertPolicyChecks:
    - id: CHECK_ID
      alertPolicies:
      - ALERT_POLICY_NAME
      labels:
        LABEL_KEY: LABEL_VALUE

Voici les propriétés de configuration pour analysis lorsque vous utilisez Google Cloud Observability :

  • Vous pouvez avoir un nombre illimité de alertPolicyChecks.

  • DURATION correspond à la durée d'exécution de l'analyse, en secondes, minutes ou heures. Une fois ce délai écoulé, l'analyse n'est plus affectée par les alertes de Google Cloud Observability. Exemple : 200s.

    CHECK_ID est un ID unique pour la vérification des règles d'alerte. Cette information s'affiche dans les résultats de l'analyse, pour chaque vérification.

  • ALERT_POLICY_NAME est le nom de la règle d'alerte que vous avez créée dans Google Cloud Observability.

  • LABEL_KEY est le nom d'un libellé que votre vérification utilisera pour correspondre à la règle d'alerte Google Cloud Observability.

  • LABEL_VALUE est la valeur à faire correspondre pour chaque libellé.

analysis personnalisé

Tâche d'analyse qui utilise des vérifications personnalisées (par rapport aux données d'un fournisseur de surveillance autre que Google Cloud Observability). Un contrôle personnalisé utilise une tâche pour spécifier le conteneur qui inclut le comportement personnalisé, ainsi que la ou les commandes à exécuter sur ce conteneur.

Voici la configuration d'une analyse personnalisée :

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

  • DURATION correspond à la durée d'exécution de l'analyse, en secondes, minutes ou heures. Une fois ce délai écoulé, l'analyse n'est plus affectée par la télémétrie entrante de votre système de surveillance. Exemple : 200s.

  • CHECK_ID est un ID unique que vous fournissez pour la vérification des règles d'alerte. Cette information s'affiche dans les résultats de l'analyse, pour chaque vérification.

  • FREQUENCY indique la fréquence d'exécution de la vérification, en secondes, minutes ou heures. Exemple :300s

  • IMAGE_NAME correspond au chemin d'accès à l'image du conteneur dans un dépôt d'images.

  • COMMAND est le point d'entrée à exécuter sur ce conteneur. "/bin/sh" est une commande typique à spécifier ici pour appeler un shell. Vous incluez les commandes à exécuter dans ce shell dans les arguments.

  • ARGS est une liste d'arguments à fournir à la commande. Si votre COMMAND 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.

    Étapes suivantes

  • Découvrez-en plus sur le fonctionnement de Cloud Deploy.

  • Découvrez comment configurer un pipeline de diffusion pour votre application.

  • Découvrez comment gérer vos fichiers manifestes.

  • Évitez les incohérences entre votre version et votre pipeline de livraison en découvrant les instances de pipeline.