Los archivos de configuración de Cloud Deploy definen la canalización de entrega, el objetivos para implementar y el la progresión de esos objetivos.
El archivo de configuración de la canalización de entrega puede incluir
en las definiciones de los destinos o en un archivo independiente.
archivos. Por convención, un archivo que contiene la configuración de la canalización de entrega y
la configuración de destino se llama clouddeploy.yaml
, y una configuración de canalización sin
objetivos se llama delivery-pipeline.yaml
. Sin embargo, puedes asignarles el nombre que desees.
Componentes
Cloud Deploy usa dos archivos de configuración principales:
- Definición de canalización de entrega
- Definición del objetivo
Pueden ser archivos separados, o la canalización de entrega y los destinos configurados en el mismo archivo.
Estructura de un archivo de configuración de la canalización de entrega
La siguiente configuración incluye una definición de destino:
# 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]
Este YAML tiene tres componentes principales:
La canalización de entrega principal y el progreso
El archivo de configuración puede incluir cualquier cantidad de definiciones de canalización.
Las definiciones de destino
Para simplificar, en este ejemplo solo se muestra un destino, pero puede haber cantidad de ellos. Además, los destinos se pueden definir en uno o varios archivos separados.
Definiciones de los tipos de segmentación personalizada
Orientaciones personalizadas, requieren un tipo de segmentación personalizada definición. Al igual que con los objetivos y las automatizaciones, definidos en el mismo archivo que la canalización de entrega o en un archivo separado.
Definiciones de automatización
Puedes crear cualquier automatización de implementación en el mismo archivo que tu canalización de entrega y tus destinos, o en uno o más archivos separados. Para simplificar, aquí solo se muestra un
Automation
, pero puedes crear tantos como desees.
Estos componentes se definen en el resto de este documento.
Definición y progreso de la canalización
Además de los metadatos de la canalización, como name
, la definición de la canalización principal
incluye una lista de referencias a objetivos en
Deployment. Es decir, el primer destino que se indica es el primer destino de implementación. Después de realizar la implementación en ese destino, promocionar la versión
implementa en el siguiente destino de la lista.
Las siguientes son las propiedades de configuración para una canalización de entrega, no incluidas las definiciones de objetivos.
metadata.name
El campo name
incluye una cadena que debe ser única por proyecto y ubicación.
metadata.annotations
y metadata.labels
La configuración de la canalización de entrega puede incluir anotaciones y etiquetas. Anotaciones y las etiquetas se almacenan con el recurso de canalización de entrega después de que esta Fue registrado.
Para obtener más información, consulta Usa etiquetas y anotaciones con Cloud Deploy.
description
Una cadena arbitraria que describe esta canalización de entrega. Se muestra esta descripción en los detalles de la canalización de entrega en la consola de Google Cloud.
suspended
Un valor booleano, que si true
suspende la canalización de entrega
de modo que no se puedan usar para crear, promover, revertir ni volver a implementar versiones.
Además, si se suspende la canalización de entrega, no puedes aprobar ni rechazar
lanzamiento creado a partir de esa canalización.
El valor predeterminado es false
.
serialPipeline
El comienzo de la definición de una canalización de entrega de progreso en serie. Esta La estrofa es obligatoria.
stages
Una lista de todos los destinos en los que se puede implementar esta canalización de entrega.
La lista debe estar en el orden de la secuencia de publicación que desees. Por ejemplo:
si tienes objetivos llamados dev
, staging
y production
, enuméralos en ese
en el mismo orden, para que la primera implementación sea en dev
y la última
está en production
.
Propaga cada campo stages.targetId
con el valor de metadata.name
en la definición objetivo correspondiente. En targetId
, incluye
profiles
:
serialPipeline:
stages:
- targetId:
profiles: []
strategy:
standard:
verify:
targetId
Identifica el destino específico que se usará en esta etapa de la canalización de entrega.
El valor es la propiedad metadata.name
de la definición objetivo.
strategy.standard.verify
se estableció en true
habilitaciones
la verificación de la implementación en el destino. Si la respuesta es no
se especifica la estrategia de implementación, se usa la estrategia de implementación standard
con la verificación establecida en false
.
profiles
Toma una lista de cero o más nombres de perfil de Skaffold, de skaffold.yaml
.
Cloud Deploy usa el perfil con skaffold render
cuando crees el lanzamiento. Los perfiles de Skaffold te permiten variar la configuración entre
mientras usan un único archivo de configuración.
strategy
Incluye propiedades para especificar una estrategia de implementación. Lo siguiente se admiten las siguientes estrategias:
standard:
La aplicación se implementa por completo en el destino especificado.
Esta es la estrategia de implementación predeterminada. Si omites
strategy
, Cloud Deploy usa la estrategia de implementaciónstandard
.canary:
En una implementación de versiones canary, implementar una versión nueva de tu aplicación de manera progresiva y reemplazar la versión a la versión en ejecución en incrementos basados en porcentajes (por ejemplo, 25%, luego 50%, luego un 75% y, luego, el total).
La estrategia de implementación se define por objetivo. Por ejemplo, puedes tener un
una estrategia de versión canary para su objetivo de prod
, pero una estrategia estándar (sin strategy
especificada) para los demás destinos.
Para obtener más información, consulta Cómo usar una estrategia de implementación.
Configuración strategy
En esta sección, se muestran los elementos de configuración de strategy
para cada uno compatible
tiempo de ejecución.
Estrategia de implementación estándar
La estrategia estándar incluye solo los siguientes elementos:
strategy:
standard:
verify: true|false
La propiedad verify
es opcional. El valor predeterminado es false
, lo que significa que habrá
No debe haber una fase de verify para los lanzamientos resultantes.
Puedes omitir el elemento strategy
para una estrategia de implementación estándar.
Estrategia de implementación de versiones canary
En las siguientes secciones, se describe la configuración de un de implementación de versiones canary, para cada entorno de ejecución compatible con Cloud Deploy.
Para los destinos de Cloud Run
strategy:
canary:
runtimeConfig:
cloudRun:
automaticTrafficControl: true | false
canaryDeployment:
percentages: [PERCENTAGES]
verify: true | false
Para los destinos de GKE y GKE Enterprise
El siguiente YAML muestra cómo configurar una estrategia de implementación para una destino de GKE o GKE Enterprise, con Herramientas de redes basadas en servicios:
canary:
runtimeConfig:
kubernetes:
serviceNetworking:
service: "SERVICE_NAME"
deployment: "DEPLOYMENT_NAME"
disablePodOverprovisioning: true | false
canaryDeployment:
percentages: [PERCENTAGES]
verify: true | false
El siguiente YAML muestra cómo configurar una estrategia de implementación para una destino de GKE o GKE Enterprise, con API de Gateway:
canary:
runtimeConfig:
kubernetes:
gatewayServiceMesh:
httpRoute: "HTTP_ROUTE_NAME"
service: "SERVICE_NAME"
deployment: "DEPLOYMENT_NAME"
routeUpdateWaitTime: "WAIT_TIME"
canaryDeployment:
percentages: ["PERCENTAGES"]
verify: true | false
Observa que, en este ejemplo,
routeUpdateWaitTime
Esta
se incluye porque la API de puerta de enlace divide el tráfico con un recurso HTTPRoute
,
y, a veces, hay una demora en la propagación de los cambios realizados a HTTPRoute
. En
En esos casos, las solicitudes podrían descartarse
porque el tráfico se envía a los recursos
que no están disponibles. Puedes usar routeUpdateWaitTime
para provocar
Cloud Deploy espere después de aplicar los cambios de HTTPRoute
, si
notará este retraso.
En el siguiente YAML, se muestra cómo configurar un clúster personalizado
o bien custom-automated
de implementación de versiones canary. Configuración específica del entorno de ejecución, en
sección runtimeConfig
, se omite para las versiones canary personalizadas, pero se incluye en
configuración de versiones canary, automatizada y personalizada.
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
Booleano opcional que indica si se admite o no la verificación de la implementación
para este objetivo. El valor predeterminado es false
.
Habilitar la verificación de implementación también requiere una estrofa verify
en el skaffold.yaml
. Si no proporcionas esta propiedad, el trabajo de verificación
fallan.
deployParameters
Te permite especificar pares clave-valor para pasar valores a manifiestos para objetivos que coinciden con etiquetas cuando usas parámetros de implementación.
También la puedes incluir en los objetivos.
Los parámetros de implementación establecidos en una canalización de entrega usan etiquetas para hacer coincidir los destinos:
deployParameters:
- values:
someKey: "value1"
matchTargetLabels:
label1: firstLabel
- values:
someKey: "value2"
matchTargetLabels:
label2: secondLabel
En este ejemplo, se proporcionan dos valores para la clave y, para cada valor, hay una etiqueta. El valor se aplica al manifiesto para cualquier destino que tenga un etiqueta coincidente.
Trabajos de predeploy
y postdeploy
Estos te permiten hacer referencia a acciones personalizadas (definidas por separado, en skaffold.yaml
) para ejecutarlas antes de la tarea de implementación (predeploy
) y después de la tarea de verificación, si está presente (postdeploy
). Si no hay una tarea de verificación, la tarea posterior a la implementación se ejecuta después de la tarea de implementación.
Los hooks de implementación se configuran en strategy.standard
o
strategy.canary
de la siguiente manera:
serialPipeline:
stages:
- targetId:
strategy:
standard:
predeploy:
actions: [ACTION_NAME]
postdeploy:
actions: [ACTION_NAME]
Donde ACTION_NAME es el nombre configurado en skaffold.yaml
para
customActions.name
Puedes configurar trabajos predeploy
y postdeploy
con cualquier estrategia.
(por ejemplo, standard
y canary
).
Para obtener más información sobre la configuración y el uso de hooks previos y posteriores a la implementación, consulta Ejecuta hooks antes y después de la implementación.
Definiciones de objetivos
El archivo de definición de la canalización de entrega puede contener definiciones de destino, o bien puedes especificar los destinos en un archivo separado. Puedes repetir nombres de destinos dentro de un pero deben ser únicos en una canalización de entrega.
Puedes volver a usar los destinos entre varias canalizaciones de entrega. Sin embargo, solo puedes hacer referencia a un objetivo una vez dentro del progreso de una sola canalización de entrega.
Consulta también: Definiciones de los tipos de segmentación personalizados
Para objetivos de GKE
El siguiente YAML muestra cómo configurar un destino que Se implementa en un clúster de 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
El nombre de este destino. Este nombre debe ser único a nivel global.
metadata.annotations
y metadata.labels
La configuración de destino admite anotaciones y etiquetas de Kubernetes. pero Cloud Deploy no los requiere.
Las anotaciones y las etiquetas se almacenan con el recurso de destino. Para obtener más información, consulta Usa etiquetas y anotaciones con Cloud Deploy.
description
Este campo toma una cadena arbitraria que describe el uso de este objetivo.
deployParameters
Puedes incluir parámetros de implementación en cualquier destino, junto con valores. Esos valores se asignan a las claves correspondientes en tu después de la renderización.
La estrofa deployParameters
toma pares clave-valor, como se muestra a continuación:
deployParameters:
someKey: "someValue"
someOtherKey: "someOtherValue"
Si configuras parámetros de implementación múltiples objetivos, el valor se asigna a el manifiesto para todas las solicitudes de destinos secundarios.
multiTarget.targetIds: []
Esta propiedad es opcional y se usa para configurar un destino múltiple que se usará para la implementación en paralelo.
El valor es una lista separada por comas de destinos secundarios.
Los destinos secundarios se configuran como objetivos normales y no incluyen
multiTarget
.
requireApproval
Indica si la promoción a este destino requiere aprobación manual. Puede ser true
o
false
Esta propiedad es opcional. El valor predeterminado es false
.
Cuando configuras la implementación paralela, puedes requerir aprobación solo en los destinos múltiples, no en los secundarios.
gke
Solo para clústeres de GKE, la ruta de acceso al recurso que identifica el clúster en el que se implementará tu aplicación:
gke:
cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
project_name
El proyecto de Google Cloud en el que reside el clúster
location
Es la ubicación donde reside el clúster. Por ejemplo,
us-central1
. El clúster también puede ser zonal (us-central1-c
).cluster_name
El nombre del clúster, tal como aparece en tu lista de clústeres en Consola de Google Cloud
A continuación, se presenta un ejemplo:
gke:
cluster: projects/cd-demo-01/locations/us-central1/clusters/prod
Omite la propiedad gke
cuando configures una opción de varios destinos.
El clúster de GKE se configura en su lugar
como destino secundario.
Consulta executionConfigs
, en este artículo, para obtener descripciones
de las propiedades del entorno de ejecución.
internalIp
Define si el clúster de GKE especificado usa o no un
dirección IP pública. Esta propiedad es opcional. De forma predeterminada, Cloud Deploy usa
la dirección IP disponible públicamente para el clúster. Si hay una dirección IP privada y quieres usarla, configúrala como true
.
proxyUrl
Si accedes a los clústeres a través de un proxy, proporciona la propiedad proxyUrl
aquí. El valor es la URL de tu clúster de GKE con proxy, que se pasa a kubectl cuando te conectas a tu clúster.
Para destinos de Cloud Run
El siguiente YAML muestra cómo configurar un destino que implementa en un servicio de 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
El nombre de este destino. Este nombre debe ser único en cada región.
metadata.annotations
y metadata.labels
La configuración de destino admite anotaciones y etiquetas, pero Cloud Deploy no los requiere.
Las anotaciones y etiquetas se almacenan con el recurso de destino. Para obtener más información, consulta Usa etiquetas y anotaciones con Cloud Deploy.
description
Este campo toma una cadena arbitraria que describe el uso de este objetivo.
multiTarget.targetIds: []
Esta propiedad es opcional y se usa para configurar una objetivo múltiple que se utilizará para implementación paralela.
El valor es una lista separada por comas de destinos secundarios.
Los destinos secundarios se configuran como objetivos normales y no incluyen
multiTarget
.
requireApproval
Indica si la promoción a este destino requiere aprobación manual. Puede ser true
o
false
Esta propiedad es opcional. El valor predeterminado es false
.
Cuando configuras la implementación paralela, puedes requerir aprobación solo en los destinos múltiples, no en los secundarios.
run
Solo para los servicios de Cloud Run, la ubicación donde el servicio se crearán:
run:
location: projects/[project_name]/locations/[location]
project_name
El proyecto de Google Cloud en el que se alojará el servicio.
location
Es la ubicación donde se instalará el servicio. Por ejemplo,
us-central1
.
Omite la propiedad run
cuando configures una opción [múltiples destinos]. La ubicación de la
Cloud Run se configura en su lugar dentro del
objetivo secundario correspondiente.
Consulta executionConfigs
, en este artículo, para obtener descripciones
de las propiedades del entorno de ejecución.
Para los destinos de GKE Enterprise
Configuración de destino para
implementar en un clúster de GKE es similar a
configurar un destino para un destino de GKE
excepto que la propiedad es anthosCluster.membership
, en lugar de gke.cluster
,
la ruta del recurso es diferente y internalIp
no es aplicable.
anthosCluster:
membership: projects/[project_name]/locations/global/memberships/[membership_name]
project_name
El proyecto de Google Cloud en el que reside el clúster de GKE Enterprise
/location/global/
La ubicación en la que está registrado el clúster.
global
, en todos los casos.membership_name
El nombre de la membresía del clúster de GKE Enterprise.
A continuación, se presenta un ejemplo:
anthosCluster:
membership: projects/cd-demo-01/locations/global/memberships/prod
Omite la propiedad anthosCluster
cuando configures una opción [múltiples destinos]. El
el clúster de GKE Enterprise se configura dentro del
como destino secundario.
Para obtener más información sobre la implementación en clústeres de GKE, consulta Implementa en clústeres de usuarios de Anthos.
Para destinos personalizados
La configuración de los destinos personalizados es similar a la siguiente:
todos los demás tipos de objetivos, salvo que no incluye una estrofa gke
ni una
run
ni anthosCluster
.
En su lugar, los destinos personalizados incluyen una estrofa customTarget
:
customTarget:
customTargetType: [CUSTOM_TARGET_TYPE_NAME]
Donde CUSTOM_TARGET_TYPE_NAME
es el nombre que usaste en el
definición del tipo de segmentación personalizada.
A continuación, se presenta un ejemplo:
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name: sample-env
customTarget:
customTargetType: basic-custom-target
executionConfigs
Un conjunto de campos para especificar un entorno de ejecución no predeterminado para este objetivo.
usages
RENDER
,DEPLOY
o ambos, másPREDEPLOY
,VERIFY
oPOSTDEPLOY
si se trata de verificación o Los hooks de implementación están habilitados en el destino. Estas indican cuál de esas operaciones perform para este objetivo usando entorno de ejecución. Para indicar que se usará un entorno de ejecución personalizado para el hook previo a la implementación, la renderización, la implementación, el hook posterior a la implementación y la verificación, debes configurarlo de la siguiente manera:usages: - RENDER - PREDEPLOY - DEPLOY - VERIFY - POSTDEPLOY
Si la verificación está habilitada en la etapa de canalización, y no especificas
VERIFY
en una estrofausages
, Cloud Deploy usa el entorno de ejecución predeterminado para la verificación. Los hooks de preaprovisionamiento y de postaprovisionamiento funcionan de la misma manera.Sin embargo, si hay un entorno de ejecución personalizado para
RENDER
yDEPLOY
, debes especificar uno paraVERIFY
,PREDEPLOY
oPOSTDEPLOY
si son configurados en la canalización de entrega.VERIFY
,PREDEPLOY
yPOSTDEPLOY
puede estar en el mismousages
queRENDER
oDEPLOY
, o enusages
separados.No puedes especificar
usages.VERIFY
,usages.PREDEPLOY
niusages.POSTDEPLOY
, a menos que se especifiquenRENDER
yDEPLOY
en el mismo entorno de ejecución personalizado o en entornos separados.workerPool
La configuración del grupo de trabajadores que se usará. Esto lleva un ruta de acceso del recurso que identifica el grupo de trabajadores de Cloud Build para usar este objetivo. Por ejemplo:
projects/p123/locations/us-central1/workerPools/wp123
Para usar el grupo predeterminado de Cloud Build, haz lo siguiente: omitir esta propiedad.
Un destino determinado puede tener dos
workerPool
(uno paraRENDER
y uno paraDEPLOY
). Cuando configures el grupo predeterminado, puedes especificar una cuenta de servicio alternativa, una ubicación de almacenamiento o ambas.serviceAccount
El nombre de la cuenta de servicio que se usará para esta operación (
RENDER
oDEPLOY
) para este destino.artifactStorage
Es el bucket de Cloud Storage que se usará para esta operación (
RENDER
oDEPLOY
) para este destino, en lugar del bucket predeterminado.executionTimeout
Opcional. Establece el tiempo de espera, en segundos, para las operaciones que Cloud Build realiza para Cloud Deploy. De forma predeterminada, el tiempo es de
3600
segundos (1 hora).
Ejemplo:executionTimeout: "5000s"
verbose
Opcional. Si es
true
, los niveles de verbosidad se establecen endebug
para los siguientes elementos: herramientas:Skaffold
--verbosity
se estableció endebug
. La configuración predeterminada de Skaffold eswarn
.kubectl
--v
se establece en4
, que es depuración. El valor predeterminado de kubectl es2
.Se configuró Google Cloud CLI
--verbosity
. adebug
. El valor predeterminado eswarning
.
Sintaxis alternativa admitida
La configuración de executionConfigs
que se describe en este documento es nueva. El
todavía se admite la sintaxis anterior:
executionConfigs:
- privatePool:
workerPool:
serviceAccount:
artifactStorage:
usages:
- [RENDER | DEPLOY]
- defaultPool:
serviceAccount:
artifactStorage:
usages:
- [RENDER | DEPLOY]
Cuando configuras una estrofa executionConfigs
para un
múltiples destinos, cada objetivo secundario
puede heredar ese entorno de ejecución
a partir de esos destinos múltiples.
Definiciones de los tipos de segmentación personalizada
En esta sección, se describen los campos que se usan para definir tipos de destinos personalizados
Al igual que con los objetivos y las automatizaciones estándar, las definiciones de CustomTargetType
pueden
incluidos en la definición de la canalización de entrega, o en uno o más archivos separados.
En el siguiente YAML, se muestra cómo configurar un tipo de destino personalizado:
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:
Aquí:
[CUSTOM_TARGET_TYPE_NAME]
Es un nombre arbitrario que le asignas a la definición de este tipo de destino personalizado. Este nombre se hace referencia en la definición del destino para cualquier objetivo, que use el tipo de destino personalizado que estás definiendo.
[RENDER_ACTION_NAME]
Es el nombre de la acción de renderización personalizada. Este valor es el
customAction.name
definido enskaffold.yaml
.[DEPLOY_ACTION_NAME]
Es el nombre de la acción de implementación personalizada. Este valor es el
customAction.name
definido enskaffold.yaml
.Para
includeSkaffoldModules
, consulta Usa la configuración remota de Skaffold.
Definiciones de automatización
En esta sección, se describen los campos que se usan para definir Cloud Deploy automation.
Al igual que con los objetivos, puedes incluir definiciones de Automation
con tu publicación
definición de la canalización, o en uno o varios archivos separados.
Para obtener más información sobre la automatización en Cloud Deploy, consulta el documentación de automatización.
En el siguiente YAML, se muestra cómo configurar una automatización. Ten en cuenta que los detalles de una regla de automatización son diferentes según la regla. (Configuración de los servicios disponibles los tipos de reglas de automatización están en el documento Usa reglas de automatización).
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]
Aquí:
[PIPELINE_NAME]
Es igual que el valor
metadata.name
en la canalización de publicación que usa esta automatización. Todas las automatizaciones son exclusivas de las canalizaciones de entrega para los que se crearon. Es decir, no puedes compartir una automatización de una canalización de entrega.[PURPOSE]
Es cualquier otro nombre descriptivo para esta automatización. Por lo general, esta sería la acción que se automatiza. Por ejemplo,
my-app-pipeline/promote
.labels
yannotations
son las etiquetas o anotaciones que deseas asociar con esta automatización.[DESCRIPTION]
Es una descripción opcional para esta automatización.
suspended
true
ofalse
, que indican si esta automatización está activa o suspendida. Si se establece entrue
, no se usa la automatización. Esto puede ser útil para Probar una automatización sin afectar la canalización de entrega.[SERVICE_ACCOUNT_ID]
Es el ID de la cuenta de servicio que se usa para realizar la automatización. Por ejemplo, si la automatización usa
promoteReleaseRule
, este la cuenta de servicio realiza la promoción del lanzamiento y, por lo tanto, requiere la los permisos necesarios para promocionar un lanzamiento.Se requiere un valor para esta propiedad. Cloud Deploy no usa la cuenta de servicio predeterminada para las automatizaciones.
Esta cuenta de servicio debe tener los siguientes permisos:
Permiso
actAs
para usar la identidad de la cuenta de servicio de ejecución.permiso para realizar operación que se está automatizando, por ejemplo, de
clouddeploy.releases.promote
a promocionar una versión oclouddeploy.rollouts.advance
para adelantar un lanzamiento y la fase de desarrollo.
[TARGET_ID]
Es el ID de la orientación para la que se utiliza esta automatización. Aunque un la automatización está vinculada a una canalización de entrega, solo se ejecuta en objetivo.
Puedes configurar esto como
*
para seleccionar todos los destinos en la canalización de entrega.[LABEL_KEY]:[LABEL_VALUE]
Es un par clave-valor que debe coincidir con un par clave-valor definido en el objetivo. De esta forma, se seleccionan todos los destinos asociados con la canalización de entrega que tienen la la misma etiqueta y el mismo valor.
[RULE_TYPE]
Es el nombre de la regla de automatización que se usa para esta automatización. Esto es
promoteReleaseRule
oadvanceRolloutRule
. Puedes incluir más de un regla de una automatización, lo que incluye más de una de las mismasRULE_TYPE
. Para Por ejemplo, puedes tener más de una reglapromoteReleaseRule
en la misma con la automatización. Obtén más información.[RULE_NAME]
Es un nombre para la regla. Este nombre debe ser único dentro de la canalización de entrega. Se requiere un valor para esta propiedad.
[RULE-SPECIFIC_CONFIG]
La configuración es diferente para cada tipo de automatización compatible. Los que de configuración se muestran en Usa reglas de automatización.
¿Qué sigue?
Obtén más información sobre cómo funciona Cloud Deploy.
Obtén información sobre cómo configurar una canalización de entrega para tu aplicación.
Obtén información para administrar tus manifiestos.
Para evitar discrepancias entre tu versión y la canalización de entrega sobre las instancias de canalización.