Le ou les fichiers de configuration Cloud Deploy définissent le pipeline de livraison, 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 livraison et les configurations cibles est appelé clouddeploy.yaml
, et une configuration de pipeline sans cibles s'appelle delivery-pipeline.yaml
. Mais vous pouvez donner à ces fichiers
le nom de votre choix.
Configuration matérielle
Cloud Deploy utilise deux fichiers de configuration principaux:
- Définition du pipeline de livraison
- Définition de la cible
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
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:
#
# 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:
---
# 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.
Les définitions des cibles
Pour des raisons de simplicité, une seule cible est présentée dans cet exemple, mais il peut y en avoir n'importe quel nombre. 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ées peuvent être définis 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 livraison 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 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 principale du pipeline inclut une liste de références à des cibles dans l'ordre séquentiel du déploiement. Autrement dit, la première cible répertoriée est la première cible de déploiement. Une fois le déploiement effectué sur cette cible, la promotion de la version est déployée sur la cible suivante de la liste.
Vous trouverez ci-dessous les propriétés de configuration d'un pipeline de livraison, à l'exclusion des définitions de cible.
metadata.name
Le champ name
accepte une chaîne qui doit être unique pour chaque projet et emplacement.
metadata.annotations
et metadata.labels
La configuration du pipeline de livraison peut inclure des annotations et des étiquettes. Les annotations et les étiquettes sont stockées avec la ressource du pipeline de livraison une fois que le pipeline a été enregistré.
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 est affichée dans les détails du pipeline de livraison dans la console Google Cloud.
suspended
Valeur booléenne, qui si true
suspend le pipeline de livraison de sorte 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 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 livraison par progression en série. Cette stanza est obligatoire.
stages
Liste de toutes les cibles sur lesquelles ce pipeline de livraison est configuré pour le déploiement.
La liste doit respecter l'ordre de diffusion souhaité. Par exemple, si vous avez des cibles appelées dev
, staging
et production
, répertoriez-les dans le même ordre, de sorte que votre premier déploiement soit 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 cible correspondante. Et sous targetId
, incluez profiles
:
serialPipeline:
stages:
- targetId:
profiles: []
strategy:
standard:
verify:
targetId
Identifie la cible spécifique à utiliser pour cette étape du pipeline de livraison.
La valeur est la propriété metadata.name
de la définition de la cible.
strategy.standard.verify
défini sur true
active la vérification du déploiement 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
Prend une liste de zéro, un ou plusieurs noms de profil 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éploiementstandard
.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 basés sur un pourcentage (par exemple, 25%, puis 50%, puis 75%, puis entièrement).
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 (aucun strategy
spécifié) pour vos autres cibles.
Pour en savoir plus, consultez la section 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 vérification pour les déploiements résultants.
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: true | false
Pour les cibles GKE et GKE Enterprise
Le code 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 code 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
Notez, dans cet exemple, routeUpdateWaitTime
. Ce point est inclus, car l'API Gateway répartit le trafic à l'aide d'une ressource HTTPRoute
, et il arrive parfois qu'il y ait un retard dans la propagation des modifications apportées au HTTPRoute
. Dans ce cas, les requêtes peuvent être abandonnées, car le trafic est envoyé vers des ressources indisponibles. Vous pouvez utiliser routeUpdateWaitTime
pour faire attendre Cloud Deploy après l'application des modifications de HTTPRoute
, si vous observez ce délai.
Le code YAML suivant montre comment configurer une stratégie de déploiement Canary personnalisé ou personnalisé. La configuration spécifique à l'environnement d'exécution, dans la section runtimeConfig
, est omise pour les versions Canary personnalisées, mais est incluse dans la 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
Booléen facultatif indiquant si la validation du déploiement doit être ou non pour cette cible. La valeur par défaut est false
.
L'activation de la vérification du déploiement nécessite également un bloc verify
dans le skaffold.yaml
. Si vous ne fournissez pas cette propriété, la tâche de validation échouera.
deployParameters
Permet de spécifier des paires clé/valeur pour transmettre des valeurs aux fichiers manifestes pour les cibles correspondant aux libellés, en cas d'utilisation de paramètres de déploiement.
Vous pouvez également l'inclure dans des cibles.
Pour déployer les paramètres définis sur un pipeline de livraison, utilisez des étiquettes 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é. La valeur est appliquée au fichier manifeste pour toute cible associée à un libellé correspondant.
predeploy
et postdeploy
jobs
Elles 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 vérification, le cas échéant (postdeploy
). En l'absence de tâche de vérification, la tâche de postdéploiement est exécutée 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 des tâches 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 pré et post-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 livraison peut contenir des définitions de cibles ou spécifier des cibles dans un fichier distinct. Vous pouvez répéter les noms des cibles au sein d'un projet, mais ils doivent être uniques au sein d'un pipeline de livraison.
Vous pouvez réutiliser les cibles dans plusieurs pipelines de livraison. Cependant, une cible ne peut être référencée qu'une seule fois dans la progression d'un seul pipeline de livraison.
Voir aussi: Définitions des types de cibles personnalisées
Pour les cibles GKE
Le fichier YAML suivant montre comment configurer une cible qui déploie 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:
executionConfigs:
- usages:
- [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY]
workerPool:
serviceAccount:
artifactStorage:
executionTimeout:
metadata.name
Nom de cette cible. Ce nom doit être unique.
metadata.annotations
et metadata.labels
La configuration cible est compatible avec les annotations Kubernetes et les libellés, mais pas avec Cloud Deploy.
Les annotations et les étiquettes sont stockées avec la ressource cible. Pour en savoir plus, 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, avec des valeurs. Ces valeurs sont attribuées aux clés correspondantes dans votre fichier manifeste, après le rendu.
Le bloc deployParameters
utilise des paires clé-valeur, comme indiqué ci-dessous:
deployParameters:
someKey: "someValue"
someOtherKey: "someOtherValue"
Si vous définissez les paramètres de déploiement sur un multi-target, la valeur est attribuée au fichier manifeste pour toutes ses cibles enfants.
multiTarget.targetIds: []
Cette propriété est facultative et permet de configurer un multi-target à utiliser pour un 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 ne pouvez exiger une approbation que pour le groupe multicible, et non pour les cibles enfants.
gke
Pour les clusters GKE uniquement, le 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
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 console Google Cloud.
Exemple :
gke:
cluster: projects/cd-demo-01/locations/us-central1/clusters/prod
Omettez la propriété gke
lorsque vous configurez un multi-target.
À la place, 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 la section executionConfigs
de cet article.
internalIp
Indique si le cluster GKE spécifié utilise ou non une adresse IP privée. 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 que vous souhaitez utiliser, définissez-la sur true
.
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]
workerPool:
serviceAccount:
artifactStorage:
executionTimeout:
metadata.name
Nom de cette cible. Ce nom doit être unique dans chaque région.
metadata.annotations
et metadata.labels
La configuration cible est compatible avec les annotations et libellés, mais Cloud Deploy n'en a pas besoin.
Les annotations et les étiquettes sont stockées avec la ressource cible. Pour en savoir plus, 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.
multiTarget.targetIds: []
Cette propriété est facultative et permet de configurer un multi-target à utiliser pour un 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 ne pouvez exiger une approbation que pour le groupe multicible, et non pour les cibles enfants.
run
Pour les services Cloud Run uniquement, l'emplacement où le service sera créé:
run:
location: projects/[project_name]/locations/[location]
project_name
Projet Google Cloud dans lequel le service sera hébergé.
location
Emplacement du service. Par exemple,
us-central1
.
Omettez la propriété run
lors de la configuration d'un [multicible]. L'emplacement du service Cloud Run est configuré à la place dans la cible enfant correspondante.
Pour obtenir la description des propriétés de l'environnement d'exécution, consultez la section executionConfigs
de cet article.
Pour les cibles GKE Enterprise
La configuration cible pour le déploiement sur un cluster GKE est semblable à la configuration d'une cible pour une cible GKE, sauf que la propriété est anthosCluster.membership
, au lieu de gke.cluster
, le chemin d'accès aux ressources 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 réside le cluster GKE Enterprise.
/location/global/
Emplacement où le cluster est enregistré.
global
, dans tous les cas.membership_name
Nom de l'appartenance au cluster GKE Enterprise.
Exemple :
anthosCluster:
membership: projects/cd-demo-01/locations/global/memberships/prod
Omettez la propriété anthosCluster
lors de la configuration d'un [multicible]. À la place, le cluster GKE Enterprise est configuré dans la cible enfant correspondante.
Pour en savoir plus sur le déploiement sur des clusters GKE, consultez la page Déployer sur des clusters d'utilisateur Anthos.
Pour les cibles personnalisées
La configuration des cibles personnalisées est semblable à tous les autres types de cibles, sauf qu'elle n'inclut pas de stanza gke
, run
, ni anthosCluster
.
À la place, les cibles personnalisées incluent un stanza 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 autre que celui par défaut pour cette cible.
usages
RENDER
,DEPLOY
ou les deux, plusPREDEPLOY
,VERIFY
ouPOSTDEPLOY
si la validation ou les hooks de déploiement sont activés sur la cible. Ils 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 vérification, vous devez le configurer comme suit:usages: - RENDER - PREDEPLOY - DEPLOY - VERIFY - POSTDEPLOY
Si la vérification est activée à l'étape du pipeline et que vous ne spécifiez pas
VERIFY
dans un blocusages
, Cloud Deploy utilise l'environnement d'exécution par défaut pour la validation. Les hooks 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
etDEPLOY
, vous devez en spécifier un pourVERIFY
,PREDEPLOY
ouPOSTDEPLOY
s'ils sont configurés sur le pipeline de livraison.VERIFY
,PREDEPLOY
etPOSTDEPLOY
peuvent se trouver dans le mêmeusages
queRENDER
ouDEPLOY
, ou dans desusages
distinctes.Vous ne pouvez pas spécifier
usages.VERIFY
,usages.PREDEPLOY
niusages.POSTDEPLOY
, sauf siRENDER
etDEPLOY
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 du pool de nœuds de calcul à utiliser. Elle utilise 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 pourRENDER
et un pourDEPLOY
). Lors de la configuration du 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
ouDEPLOY
) pour cette cible.artifactStorage
Bucket Cloud Storage à utiliser pour cette opération (
RENDER
ouDEPLOY
) pour cette cible, au lieu du bucket par défaut.executionTimeout
Facultatif. Définit le délai avant expiration, en secondes, des opérations que Cloud Build exécute pour Cloud Deploy. La valeur par défaut est de
3600
secondes (1 heure).
Exemple:executionTimeout: "5000s"
Autre syntaxe prise en charge
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 un stanza executionConfigs
pour un multi-target, 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 livraison, 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é que vous définissez.
[RENDER_ACTION_NAME]
est le nom de l'action de rendu personnalisé. Cette valeur correspond au
customAction.name
défini dansskaffold.yaml
.[DEPLOY_ACTION_NAME]
est le nom de l'action de déploiement personnalisé. Cette valeur correspond au
customAction.name
défini dansskaffold.yaml
.Pour
includeSkaffoldModules
, consultez Utiliser des configurations Skaffold distantes.
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 avec 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 fichier 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]
Est identique à la valeur
metadata.name
dans le pipeline de livraison qui utilise cette automatisation. Toutes les automatisations sont exclusives aux pipelines de livraison pour lesquels elles sont créées. Autrement dit, vous ne pouvez pas partager une automatisation sur plusieurs pipelines de livraison.[PURPOSE]
Il s'agit d'un autre nom descriptif pour cette automatisation. En général, il s'agit de l'action automatisée. Par exemple,
my-app-pipeline/promote
.labels
etannotations
sont des étiquettes ou des annotations que vous souhaitez associer à cette automatisation.[DESCRIPTION]
Description facultative de cette automatisation.
suspended
true
oufalse
, qui indique si cette automatisation est active ou suspendue. Si la valeur esttrue
, l'automatisation n'est pas utilisée. Cela peut être utile pour tester une automatisation sans affecter le pipeline de livraison.[SERVICE_ACCOUNT_ID]
correspond à l'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 nécessaires pour la promouvoir.Veuillez saisir 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
permettant d'emprunter l'identité du compte de service d'exécution.L'autorisation permettant d'effectuer l'opération automatisée, par exemple
clouddeploy.releases.promote
pour promouvoir une version ouclouddeploy.rollouts.advance
pour avancer une phase de déploiement.
[TARGET_ID]
correspond à l'ID de la cible pour laquelle cette automatisation est utilisée. Bien qu'une automatisation soit liée à un pipeline de livraison, elle n'est exécutée que sur la ou les cibles spécifiées.
Vous pouvez définir la valeur sur
*
pour sélectionner toutes les cibles du pipeline de livraison.[LABEL_KEY]:[LABEL_VALUE]
Paire clé-valeur à mettre en correspondance avec une paire clé-valeur définie sur la cible. Cette opération sélectionne toutes les cibles associées au pipeline de livraison ayant le même libellé et la même valeur.
[RULE_TYPE]
Nom de la règle d'automatisation utilisée pour cette automatisation.
promoteReleaseRule
ouadvanceRolloutRule
. Vous pouvez inclure plusieurs règles dans une automatisation, y compris plusieurs du mêmeRULE_TYPE
. Par exemple, vous pouvez avoir plusieurs règlespromoteReleaseRule
dans la même automatisation. En savoir plus[RULE_NAME]
Nom de la règle. Ce nom doit être unique dans le pipeline de livraison. Veuillez saisir une valeur pour cette propriété.
[RULE-SPECIFIC_CONFIG]
La configuration est différente pour chaque type d'automatisation compatible. Ces configurations sont présentées dans la section Utiliser des règles d'automatisation.
Étapes suivantes
En savoir plus sur le fonctionnement de Cloud Deploy
Découvrez comment configurer un pipeline de livraison pour votre application.
Découvrez comment gérer vos fichiers manifestes.
Évitez les incohérences entre votre version et votre pipeline de livraison en vous familiarisant avec les instances de pipeline.