Le ou les fichiers de configuration Cloud Deploy définissent la pipeline de livraison, le cibles de déploiement progression de ces objectifs.
Le fichier de configuration du pipeline de livraison peut inclure
définitions de cibles, qui peuvent se trouver dans un fichier distinct ou
. 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é.
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:
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:
---
# 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:
Principaux pipelines de livraison et progression
Le fichier de configuration peut inclure un nombre illimité de définitions de pipeline.
Définitions des cibles
Par souci de simplicité, cet exemple ne représente qu'une seule cible, mais il peut y avoir leur nombre. De plus, les cibles peuvent être définies 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 comme votre pipeline de livraison et vos cibles, ou dans un ou plusieurs fichiers séparés. 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 du pipeline, telles que name
, la définition de pipeline principale
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 le déploiement sur cette cible effectué, promouvoir la version
se déploie sur la cible suivante dans 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 livraison peut inclure des annotations et des étiquettes. 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 livraison est suspendu, vous ne pouvez ni 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 sur lesquelles ce pipeline de livraison est configuré pour se déployer.
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
, répertoriez-les dans ce
dans le même ordre, de sorte que votre premier déploiement s'effectue sur dev
et votre déploiement final
est dans production
.
Renseignez chaque champ stages.targetId
avec la valeur de 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
permet d'activer
validation du déploiement sur la cible. Si non
la stratégie de déploiement est spécifiée, la stratégie de déploiement standard
est utilisée ;
avec le paramètre de validation défini 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
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éploiementstandard
.canary:
Dans un déploiement Canary, vous déployez progressivement une nouvelle version de votre application, en remplaçant version en cours d'exécution par incréments basés sur un 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
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 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 élément compatible
de l'environnement d'exécution.
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 que
n'a pas de phase de vérification 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 code YAML suivant montre comment configurer une stratégie de déploiement pour un une cible GKE ou GKE Enterprise, en utilisant 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 un une cible GKE ou GKE Enterprise, en utilisant 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 provoquer
Cloud Deploy doit attendre après avoir appliqué HTTPRoute
modifications, si vous
observer ce délai.
Le code YAML suivant montre comment configurer un objet personnalisé
ou personnalisé-automatisé
de déploiement Canary. Configuration spécifique à l'environnement d'exécution, au niveau
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
Booléen facultatif indiquant s'il est compatible ou non avec la validation du déploiement
pour cette cible. La valeur par défaut est false
.
L'activation de la validation du déploiement requiert également un bloc verify
dans skaffold.yaml
. Si vous ne fournissez pas cette propriété, le job de validation
échouer.
deployParameters
Permet de spécifier des paires clé-valeur pour transmettre des valeurs aux fichiers manifestes cibles avec étiquette correspondante, lors de l'utilisation de paramètres de déploiement.
Vous pouvez également l'inclure dans des cibles.
Pour déployer des 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é. Pour chaque valeur, il y a une étiquette. La valeur est appliquée au fichier manifeste pour toute cible ayant un libellé correspondant.
predeploy
et postdeploy
jobs
Ils vous permettent de référencer des actions personnalisées
(défini séparément, dans
skaffold.yaml
) s'exécutera avant la tâche de déploiement (predeploy
) et après la validation.
job, le cas échéant (postdeploy
). En l'absence de tâche de validation, la tâche de post
s'exécute après le job 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 livraison peut contenir des définitions de cibles, mais vous pouvez aussi spécifier des cibles dans un fichier distinct. Vous pouvez répéter les noms des cibles dans un projet, mais ils doivent être uniques au sein d'un pipeline de livraison.
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 décrivant l'utilisation de cette cible.
deployParameters
Vous pouvez inclure des paramètres de déploiement sur n'importe quelle cible, ainsi que les valeurs. Ces valeurs sont attribuées aux clés correspondantes dans votre après le rendu.
Le stanza deployParameters
accepte 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 à le fichier manifeste pour tous les cibles enfants.
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 un déploiement en parallèle, vous pouvez exiger l'approbation sur le multicible uniquement, et non sur les cibles enfants.
gke
Pour les clusters GKE uniquement, le chemin d'accès à la ressource identifiant cluster dans 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 où réside le 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
Omettez la propriété gke
lorsque vous configurez une classe multicible.
Le cluster GKE est configuré à l'intérieur du conteneur
cible enfant.
Pour obtenir une description, consultez la section executionConfigs
de cet article
des propriétés de l'environnement d'exécution.
internalIp
Indique si le cluster GKE spécifié utilise un cluster privé
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, indiquez le proxyUrl
cette propriété. 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 pour chaque 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. 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 un déploiement en parallèle, vous pouvez exiger l'approbation sur le multicible uniquement, et non sur 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
.
Omettez la propriété run
lors de la configuration d'une [zone cible multiple]. 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 réside 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
Omettez la propriété anthosCluster
lors de la configuration d'une [zone cible multiple]. La
Le cluster GKE Enterprise est configuré à l'intérieur du
cible enfant.
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 à
tous les autres types de cibles, à la différence qu'il n'inclut pas de strophe gke
ni de
run
ni anthosCluster
.
À la place, les cibles personnalisées incluent un strophe customTarget
:
customTarget:
customTargetType: [CUSTOM_TARGET_TYPE_NAME]
Où CUSTOM_TARGET_TYPE_NAME
est le nom que vous avez utilisé dans le
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 différent de celui par défaut pour cette cible.
usages
RENDER
,DEPLOY
ou les deux, plusPREDEPLOY
,VERIFY
ouPOSTDEPLOY
si validation ou Les hooks de déploiement sont activés sur la cible. Ils indiquent quelles opérations doivent perform pour cette cible en utilisant environnement d'exécution. Pour indiquer qu'un environnement d'exécution personnalisé être utilisé pour le hook de prédéploiement, le rendu, le déploiement, le hook post-déploiement et la vérification ; 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 sectionusages
, 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
etDEPLOY
, vous devez en spécifier un pourVERIFY
,PREDEPLOY
OUPOSTDEPLOY
s'ils sont configurés sur le pipeline de livraison.VERIFY
,PREDEPLOY
etPOSTDEPLOY
peut 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 fichier des environnements d'exécution.workerPool
Configuration à utiliser pour le pool de nœuds de calcul. Cela prend un chemin d'accès à la ressource 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, procédez comme suit : omettez cette propriété.
Une cible donnée peut avoir deux valeurs
workerPool
(une pourRENDER
et une pourDEPLOY
). Lorsque vous configurez le pool par défaut, vous pouvez spécifier un autre compte de service ou emplacement de stockage, ou les deux.serviceAccount
Nom du compte de service à utiliser pour cette opération (
RENDER
ouDEPLOY
) pour cette cible.artifactStorage
Le 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 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 surdebug
pour les éléments outils:Skaffold
--verbosity
est défini surdebug
. La valeur par défaut de Skaffold estwarn
.kubectl
--v
est défini sur4
(débogage). La valeur par défaut de kubectl est2
.La Google Cloud CLI
--verbosity
est configurée àdebug
. La valeur par défaut estwarning
.
Autre syntaxe acceptée
La configuration executionConfigs
décrite dans ce document est nouvelle. La
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 bloc executionConfigs
pour une
multi-target, chaque cible enfant
peuvent hériter de cet environnement d'exécution
à partir de ce multicible.
Définitions des types de cibles personnalisées
Cette section décrit les champs utilisés pour définir types de cibles personnalisées
Comme pour les cibles et les automatisations standards, les définitions CustomTargetType
peuvent être
inclus dans la définition de votre pipeline de livraison, ou dans un ou plusieurs fichiers séparés.
Le code YAML suivant montre comment configurer un type de cible personnalisée:
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ée dans la définition de la cible pour toute cible utilisant le type de cible personnalisée que vous définissez.
[RENDER_ACTION_NAME]
Nom de l'action de rendu personnalisé. Cette valeur est la
customAction.name
défini dansskaffold.yaml
.[DEPLOY_ACTION_NAME]
Nom de l'action de déploiement personnalisée. Cette valeur est la
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 l'objet Cloud Deploy automation.
Comme pour les cibles, les définitions de Automation
peuvent être incluses dans votre diffusion
la définition du pipeline, 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 détails d'une règle d'automatisation diffèrent selon les règles. (Configuration pour les métriques les types de règles d'automatisation à l'aide de 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 livraison dans lequel ils seront créés. Autrement dit, vous ne pouvez pas partager une automatisation avec d'autres plusieurs pipelines de livraison.[PURPOSE]
Indiquez 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 les libellés ou annotations que vous souhaitez à cette automatisation.[DESCRIPTION]
Description facultative pour cette automatisation.
suspended
true
oufalse
, indiquant 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]
L'ID du compte de service utilisé pour effectuer la 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.Vous devez indiquer une valeur pour cette propriété. Cloud Deploy n'utilise pas default service account (compte de service par défaut) pour les automatisations.
Ce compte de service doit disposer des autorisations suivantes:
L'autorisation
actAs
permet d'emprunter 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, ouclouddeploy.rollouts.advance
pour faire avancer un déploiement à chaque phase.
[TARGET_ID]
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 livraison.[LABEL_KEY]:[LABEL_VALUE]
Paire clé-valeur à mettre en correspondance avec une paire clé-valeur définie sur la cible. Cette opération permet de sélectionner 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. Il s'agit soit
promoteReleaseRule
ouadvanceRolloutRule
. Vous pouvez inclure plusieurs dans une automatisation, y compris plusieurs valeurs du mêmeRULE_TYPE
. Pour Par exemple, vous pouvez avoir plusieurs règlespromoteReleaseRule
dans la l'automatisation. En savoir plus[RULE_NAME]
Nom de la règle. Ce nom doit être unique dans le pipeline de livraison. Vous devez indiquer une valeur 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
Étape suivante
Découvrez-en 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 vos versions et votre pipeline de livraison en apprenant sur les instances de pipeline.