Documentation de référence sur le 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, ainsi que la progression de ces cibles.

Le fichier de configuration du pipeline de diffusion 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 livraison et les configurations cibles s'appelle clouddeploy.yaml, et une configuration de pipeline sans s'appelle delivery-pipeline.yaml. Mais vous pouvez donner à ces fichiers le nom souhaité. D'autres définitions de ressources, telles que les automatisations et les règles de déploiement, peuvent également se trouver dans le même fichier qu'un pipeline de diffusion ou une définition de cible.

Configuration matérielle

Cloud Deploy utilise deux fichiers de configuration principaux:

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

Structure d'un fichier de configuration de pipeline de livraison

La configuration suivante inclut une définition de cible :

# 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:
       verify:
       predeploy:
         actions: []
       postdeploy:
         actions: []
   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:
 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]
  workerPool:
  serviceAccount:
  artifactStorage:
  executionTimeout:
  verbose:
---

# Custom target type config
apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
  name:
  annotations:
  labels:
description:
customActions:
  renderAction:
  deployAction:
  includeSkaffoldModules:
    - configs:
    # either:
    googleCloudStorage:
      source:
      path:
    # or:
    git:
      repo:
      path:
      ref:
---

# Automation config
apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name:
  labels:
  annotations:
description:
suspended:
serviceAccount:
selector:
- target:
    id:
    # or
    labels:
rules:
- [RULE_TYPE]:
  name:
  [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é, une seule cible est affichée dans cet exemple, mais il peut y en avoir autant que vous le souhaitez. Vous pouvez également définir des cibles dans un ou plusieurs fichiers distincts.

  • Définitions des types de cibles personnalisées

    Cibles personnalisées : vous devez indiquer un type de cible personnalisée définition. Comme pour les cibles et les automatisations, les types de cibles personnalisées défini dans le même fichier que le pipeline de livraison, 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. Par souci de simplicité, un seul Automation est affiché ici, mais vous pouvez créer en tant que autant que vous le souhaitez.

Ces composants sont définis dans la suite de ce document.

Définition et progression du pipeline

En plus des métadonnées de 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. Autrement dit, la première cible répertoriée est la première cible de déploiement. Une fois que vous avez déployé la version sur cette cible, la promotion de la version la déploie sur la cible suivante de la liste.

Vous trouverez ci-dessous les propriétés de configuration d'un pipeline de livraison, y compris les définitions des cibles.

metadata.name

Le champ name utilise une chaîne qui doit être unique pour chaque projet et emplacement.

metadata.annotations et metadata.labels

La configuration du pipeline de diffusion peut inclure des annotations et des libellés. Annotations et les étiquettes sont stockées avec la ressource du pipeline de livraison a bien été enregistrée.

Pour en savoir plus, consultez la page Utiliser des étiquettes 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 de la console Google Cloud.

suspended

Une valeur booléenne, qui, si true suspend le pipeline de livraison afin qu'il ne puisse pas être utilisé pour créer, promouvoir, effectuer un rollback ou redéployer des versions. De plus, si le pipeline de diffusion 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 livraison avec progression en série. Ce Veuillez indiquer un strophe.

stages

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

La liste doit respecter 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 cet ordre, de sorte que votre premier déploiement soit effectué dans dev et votre déploiement final dans production.

Renseignez chaque champ stages.targetId avec la valeur du champ metadata.name dans la définition de la 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 diffusion. La valeur est 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

Utilise une liste de zéro, un ou plusieurs noms de profil Skaffold, provenant 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 faire 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 éléments suivants : stratégies sont prises en charge:

  • 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 des incréments basés sur des pourcentages (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 stratégie Canary pour votre cible "prod", mais stratégie standard (pas de 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 ne comprend que les éléments suivants:

strategy:
  standard:
    verify: true|false

La propriété verify est facultative. La valeur par défaut est false, ce qui signifie qu'il n'y aura pas de phase de validation pour les déploiements qui en résultent.

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

Stratégie de déploiement Canary

Les sections suivantes décrivent la configuration de déploiement Canary, 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: true | false
Pour les cibles GKE et GKE Enterprise

Le fichier YAML suivant montre comment configurer une stratégie de déploiement pour une cible GKE ou GKE Enterprise à 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: true | false

Le fichier YAML suivant montre comment configurer une stratégie de déploiement pour une cible GKE ou GKE Enterprise à l'aide de l'API Gateway :

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

Dans cet exemple, notez routeUpdateWaitTime Ce est incluse, car l'API Gateway répartit le trafic à l'aide d'une ressource HTTPRoute. La propagation des modifications apportées à HTTPRoute prend parfois un certain temps. Dans les requêtes peuvent être abandonnées, car le trafic est envoyé aux ressources qui ne sont pas disponibles. Vous pouvez utiliser routeUpdateWaitTime pour que Cloud Deploy attende après l'application des modifications HTTPRoute, si vous observez ce délai.

Le fichier YAML suivant montre comment configurer une stratégie de déploiement canari personnalisée ou personnalisée et automatisée. Configuration spécifique à l'environnement d'exécution, dans la Section runtimeConfig, est omise pour la version Canary personnalisée, mais incluse dans une configuration Canary automatisée et 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: true | false
           - …
           - name: "stable"
             percent: 100
             profiles: [ "LAST_PROFILE_NAME" ]
             verify: true|false

verify

Valeur booléenne facultative indiquant si la validation du déploiement est prise en charge pour cette cible. La valeur par défaut est false.

L'activation de la validation du déploiement nécessite également une strophe verify dans le fichier skaffold.yaml. Si vous ne fournissez pas cette propriété, le job de validation échouer.

deployParameters

Vous permet de spécifier des paires clé-valeur pour transmettre des valeurs aux fichiers manifestes pour les cibles associées à une étiquette, 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 diffusion 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 pour chaque valeur, un libellé est associé. La valeur est appliquée au fichier manifeste pour toute cible associée à un libellé correspondant.

Jobs predeploy et postdeploy

Ils vous permettent de référencer des actions personnalisées (définies séparément, dans skaffold.yaml) à exécuter avant la tâche de déploiement (predeploy) et après la tâche de validation, le cas échéant (postdeploy). S'il n'y a pas de tâche de validation, la tâche post-déploiement s'exécute après la tâche de déploiement.

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

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 les jobs predeploy et postdeploy selon n'importe quelle stratégie (standard, canary, par exemple).

Pour en savoir plus sur la configuration et l'utilisation de hooks avant et après le déploiement, consultez la section 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épéter des noms de cibles dans un projet, mais ils doivent être uniques dans un pipeline de diffusion.

Vous pouvez réutiliser des cibles dans plusieurs pipelines de livraison. Toutefois, vous ne pouvez faire référence à une cible une seule fois depuis la progression d'un pipeline de livraison unique.

Voir également: Définitions des types de cibles personnalisées

Pour les cibles GKE

Le code YAML suivant montre comment configurer une cible 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]
      internalIp:
      proxyUrl:

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

metadata.name

Nom de cette cible. Ce nom doit être unique.

metadata.annotations et metadata.labels

La configuration cible est compatible avec les annotations et les étiquettes Kubernetes. mais Cloud Deploy n'en a pas besoin.

Les annotations et les étiquettes sont stockées avec la ressource cible. Pour plus d'informations, consultez la page Utiliser des étiquettes et des annotations avec Cloud Deploy.

description

Ce champ accepte une chaîne arbitraire qui décrit 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 dans votre après le rendu.

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

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

Si vous définissez des paramètres de déploiement sur une cible multiple, la valeur est attribuée au fichier manifeste pour toutes les cibles enfants de cette cible multiple.

multiTarget.targetIds: []

Cette propriété est facultative. Elle permet de configurer Multicible à utiliser 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 cet élément 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 le déploiement parallèle, vous pouvez exiger une approbation uniquement pour le groupe multicible, et non pour les cibles enfants.

gke

Pour les clusters GKE uniquement, le chemin de ressource identifiant le cluster sur lequel votre application sera déployée :

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

  • project_name

    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 votre liste de clusters dans console Google Cloud.

Exemple :

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

Omettre la propriété gke lors de la configuration d'une multicible. Le cluster GKE est configuré à la place dans la cible enfant correspondante.

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

internalIp

Indique si le cluster GKE spécifié utilise un cluster privé l'adresse IP. Cette propriété est facultative. Par défaut, Cloud Deploy utilise l'adresse IP publique du cluster. S'il existe une adresse IP privée et que vous souhaitez l'utiliser, définissez-la sur true.

proxyUrl

Si vous accédez aux clusters via un proxy, fournissez ici la propriété proxyUrl. La valeur est l'URL de votre proxy GKE d'un cluster, transmis à kubectl lorsque vous vous connectez à votre cluster.

Pour les cibles Cloud Run

Le code YAML suivant montre comment configurer une cible déploie sur 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]
       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 prend en charge les annotations et les étiquettes, mais Cloud Deploy n'en a pas besoin.

Les annotations et les étiquettes sont stockées avec la ressource cible. Pour plus d'informations, consultez la page Utiliser des étiquettes 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 une multicible à 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 le déploiement parallèle, vous pouvez exiger une approbation uniquement pour le groupe multicible, et non pour les cibles enfants.

run

Pour les services Cloud Run uniquement, l'emplacement est créé:

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

  • project_name

    Projet Google Cloud dans lequel le service réside.

  • location

    Emplacement où réside le service. Par exemple, us-central1.

Omettre la propriété run lors de la configuration d'un [multi-target]. L'emplacement le service Cloud Run est configuré à l'intérieur du la cible enfant correspondante.

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

Pour les cibles GKE Enterprise

Configuration cible pour le déploiement sur un cluster GKE est semblable configurer une cible pour une cible GKE ; sauf que la propriété est anthosCluster.membership au lieu de gke.cluster, le chemin d'accès à la ressource est différent et internalIp n'est pas applicable.

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

  • project_name

    Projet Google Cloud dans lequel se trouve le cluster GKE Enterprise.

  • /location/global/

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

  • membership_name

    Nom d'appartenance au cluster GKE Enterprise.

Exemple :

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

Omettre la propriété anthosCluster lors de la configuration d'un [multi-target]. Le cluster GKE Enterprise est plutôt configuré dans la cible enfant correspondante.

Pour en savoir plus sur le déploiement sur des clusters GKE, consultez Déployer sur des clusters d'utilisateur Anthos

Pour les cibles personnalisées

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

À la place, les cibles personnalisées incluent un strophe customTarget:

customTarget:
  customTargetType: [CUSTOM_TARGET_TYPE_NAME]

Où CUSTOM_TARGET_TYPE_NAME correspond au nom que vous avez utilisé dans la définition du type de cible personnalisé.

Exemple :

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

executionConfigs

Un ensemble de champs permettant de spécifier un environnement d'exécution différent de celui par défaut pour cette cible.

  • usages

    RENDER ou DEPLOY, ou les deux, plus PREDEPLOY, VERIFY ou POSTDEPLOY si la validation ou les hooks de déploiement sont activés sur la cible. Ils indiquent quelles 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 postdéploiement et la validation, vous devez le configurer comme suit :

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

    Si la validation est activée à l'étape 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 prédéploiements et Les hooks postdeploy 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 OU POSTDEPLOY s'ils sont configurés sur le pipeline de livraison.VERIFY, PREDEPLOY et POSTDEPLOY 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 ou usages.POSTDEPLOY, sauf si RENDER et DEPLOY sont spécifiés dans les mêmes environnements d'exécution personnalisés ou dans des environnements distincts.

  • workerPool

    Configuration à utiliser pour le pool de nœuds de calcul. Il s'agit d'un chemin d'accès aux ressources identifiant 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 compte de service ou un emplacement de stockage alternatifs, 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 effectuées par Cloud Build pour Cloud Deploy. Par défaut, il s'agit 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 éléments outils:

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

    • kubectl --v est défini sur 4 (débogage). La valeur par défaut de kubectl est 2.

    • La Google Cloud CLI --verbosity est configurée à debug. La valeur par défaut est warning.

Autre syntaxe acceptée

La configuration executionConfigs décrite dans ce document est nouvelle. La syntaxe précédente 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 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 avec la définition de votre pipeline de diffusion, ou dans un ou plusieurs fichiers distincts.

Le fichier 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 cible personnalisée. 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 est la customAction.name défini dans skaffold.yaml.

  • [DEPLOY_ACTION_NAME]

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

  • Pour includeSkaffoldModules, consultez Utiliser des configurations Skaffold distantes

Définitions des automatisations

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 avec la définition de votre pipeline de diffusion 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 d'une règle à l'autre. (La configuration des types de règles d'automatisation disponibles se trouve 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]:
    name:[RULE_NAME]
  [RULE-SPECIFIC_CONFIG]

Où :

  • [PIPELINE_NAME]

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

  • [PURPOSE]

    Il s'agit d'un autre nom descriptif de cette automatisation. Il s'agit généralement de l'action automatisée. Par exemple, my-app-pipeline/promote.

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

  • [DESCRIPTION]

    Description facultative pour cette automatisation.

  • suspended

    true ou false, qui indique si cette automatisation est active ou suspendue. Si la valeur est true, l'automatisation n'est pas utilisée. Cela peut être utile pour tester une automatisation sans affecter le pipeline de livraison.

  • [SERVICE_ACCOUNT_ID]

    Il s'agit de l'ID du compte de service utilisé pour effectuer l'automatisation. Par exemple, si l'automatisation utilise promoteReleaseRule, alors effectue la promotion de version et nécessite donc autorisations nécessaires pour promouvoir une sortie.

    Une valeur est requise 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 usurper l'identité du compte de service d'exécution.

    • autorisation d'effectuer l' opération en cours d'automatisation, par exemple, clouddeploy.releases.promote pour promouvoir une version, ou clouddeploy.rollouts.advance pour faire avancer un déploiement à chaque phase.

  • [TARGET_ID]

    Il s'agit de l'ID de la cible pour laquelle cette automatisation est utilisée. Bien qu'un est liée à un pipeline de livraison, elle ne s'exécute que sur le la ou les cibles.

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

  • [LABEL_KEY]:[LABEL_VALUE]

    Il s'agit d'une paire clé-valeur à faire correspondre à une paire clé-valeur définie sur la cible. Cette option 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 s'agit soit promoteReleaseRule, advanceRolloutRule ou repairRolloutRule. Vous pouvez inclure plusieurs règles dans une automatisation, y compris plusieurs RULE_TYPE identiques. Par exemple, vous pouvez avoir plusieurs promoteReleaseRule. dans la même automatisation. En savoir plus

  • [RULE_NAME]

    Nom de la règle. Ce nom doit être unique dans le pipeline de diffusion. Une valeur est requise pour cette propriété.

  • [RULE-SPECIFIC_CONFIG]

    La configuration est différente pour chaque type d'automatisation compatible. Ces de configuration s'affichent Utiliser des règles d'automatisation

Définitions des règles de déploiement (preview)

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

Comme avec d'autres ressources Cloud Deploy, vous pouvez inclure DeployPolicy avec la définition de votre pipeline de livraison ou dans un fichier distinct.

Le fichier YAML suivant montre comment configurer une règle 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 s'agir de lettres minuscules, de chiffres et de traits d'union. avec le premier caractère une lettre, le dernier caractère une lettre ou un chiffre, et 63 caractères maximum. Ce nom est utilisé comme nom à afficher dans la console Google 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 la section Utiliser des annotations et des libellés avec Cloud Deploy.

  • suspended: [true | false]

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

  • [PIPELINE_ID]

    ID du pipeline de diffusion auquel vous souhaitez appliquer cette règle. 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]

    Il s'agit d'une paire clé-valeur à mettre en correspondance avec une paire clé-valeur définie lors de la diffusion. le pipeline ou la cible. Cette opération permet de sélectionner tous les pipelines ou cibles ayant l'étiquette et la valeur. Vous pouvez spécifier labels à la place ou en plus de id.

  • [RULE_TYPE]

    Il s'agit du type de règle de stratégie spécifique que vous configurez. La seule valeur valide est rolloutRestriction.

  • [CONFIGS]

    Il s'agit de l'ensemble de 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.

Règles de déploiement des stratégies

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 pendant la ou les périodes spécifiées, pour les pipelines de diffusion et les cibles indiqués par le 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 écrit en minuscules. lettres, chiffres et traits d'union, le premier caractère une lettre, le dernier une lettre ou un chiffre, et 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 le cadre de la règle. Si ce champ est vide, toutes les actions sont limitées. Les valeurs possibles sont les suivantes :

    • ADVANCE

      Les phases de déploiement ne peuvent pas avancées.

    • APPROVE

      Impossible d'approuver la promotion de déploiement.

    • CANCEL

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

    • CREATE

      Impossible de créer des déploiements.

    • IGNORE_JOB

      Les jobs ne peuvent pas être ignorés.

    • RETRY_JOB

      Les tâches ne peuvent pas faire l'objet de nouvelles tentatives.

    • ROLLBACK

      Les déploiements ne peuvent pas faire l'objet d'un annulation.

    • TERMINATE_JOBRUN

      Les exécutions de tâches ne peuvent pas être arrêtées

  • INVOKERS

    La spécification des demandeurs permet de filtrer l'application de la stratégie 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 gérée par l'utilisateur. Par exemple, créer manuellement un déploiement à l'aide d'un gcloud CLI.

    • DEPLOY_AUTOMATION

      Action automatisée effectuée par Cloud Deploy.

    Vous pouvez spécifier une ou les deux valeurs. Par défaut, si vous ne spécifiez rien, les deux sont sélectionnés.

  • TIMEZONE

    Le fuseau horaire, dans Format IANA dans laquelle vous exprimez la fenêtre temporelle. 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 fenêtre de restriction au format "yyyy-mm-dd hh:mm". Au début de la journée, utilisez 00:00. Ce champ est obligatoire.

  • END_DATE_TIME

    Pour oneTimeWindows, date et 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, correspond à tous les jours de la semaine

  • START_TIME

    weeklyWindows : heure de début du jour de la semaine spécifié. Si vous inclure une heure de début, vous devez inclure une heure de fin. Au début du cours jour, 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.

Étape suivante