Los archivos de configuración de Cloud Deploy definen la canalización de entrega, los destinos en los que se implementará y la progresión de esos destinos.
El archivo de configuración de la canalización de entrega puede incluir definiciones de destino, o pueden estar en uno o varios archivos separados. Por convención, un archivo que contiene la configuración de la canalización de entrega y la de destino se llama clouddeploy.yaml
, y una configuración de canalización sin destinos se llama delivery-pipeline.yaml
. Pero puedes darles
el nombre que quieras a estos archivos.
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 se pueden configurar 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 cualquier cantidad de ellos. Además, los destinos se pueden definir en uno o varios archivos separados.
Definiciones de los tipos de segmentación personalizada
Los destinos personalizados requieren una definición del tipo de objetivo personalizado. Al igual que con los objetivos y las automatizaciones, los tipos de destinos personalizados se pueden definir 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 la canalización de entrega y los destinos, o en uno o más archivos separados. Para simplificar, aquí se muestra solo un
Automation
, pero puedes crear todos los que 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 canalización, como name
, la definición de la canalización principal incluye una lista de referencias a destinos en el orden de secuencia de implementación. Es decir, el primer destino de la lista es el primero de implementación. Después de realizar la implementación en ese destino, promover la implementación de la versión al siguiente destino de la lista.
A continuación, se muestran las propiedades de configuración para una canalización de entrega, sin incluir las definiciones de destino.
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. Las anotaciones y las etiquetas se almacenan con el recurso de canalización de entrega después de que la canalización se registra.
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. Esta descripción se muestra 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 pueda usar para crear, ascender, revertir o volver a implementar versiones.
Además, si la canalización de entrega está suspendida, no puedes aprobar ni rechazar un 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 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 mismo orden para que tu primera implementación sea en dev
y la última, en production
.
Propaga cada campo stages.targetId
con el valor del campo metadata.name
en la definición de destino correspondiente. En targetId
, incluye profiles
:
serialPipeline:
stages:
- targetId:
profiles: []
strategy:
standard:
verify:
targetId
Identifica el destino específico que se usará para esta etapa de la canalización de entrega.
El valor es la propiedad metadata.name
de la definición objetivo.
strategy.standard.verify
configurado como true
habilita la verificación de la implementación en el destino. Si no se especifica una 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 crea la versión. Los perfiles de Skaffold te permiten variar la configuración entre los destinos mientras usas un solo archivo de configuración.
strategy
Incluye propiedades para especificar una estrategia de implementación. 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, implementas una versión nueva de tu aplicación de manera progresiva y reemplazas la versión que ya se ejecuta por incrementos basados en porcentajes (por ejemplo, 25%, luego 50%, luego 75% y, luego, completamente).
La estrategia de implementación se define por objetivo. Por ejemplo, puedes tener una estrategia de versiones canary para tu objetivo prod
, pero una estrategia estándar (sin strategy
especificado) para los demás objetivos.
Para obtener más información, consulta Usa una estrategia de implementación.
Configuración strategy
En esta sección, se muestran los elementos de configuración de strategy
para cada entorno de ejecución compatible.
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 no habrá una fase de verificación para los lanzamientos resultantes.
Puedes omitir el elemento strategy
en una estrategia de implementación estándar.
Estrategia de implementación de versiones canary
En las siguientes secciones, se describe la configuración de una estrategia de implementación de versiones canary para cada entorno de ejecución que admite 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
En el siguiente YAML, se muestra cómo configurar una estrategia de implementación para un destino de GKE o GKE Enterprise mediante 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
En el siguiente YAML, se muestra cómo configurar una estrategia de implementación para un destino de GKE o GKE Enterprise mediante la 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 el objeto routeUpdateWaitTime
de este ejemplo. Esto se incluye porque la API de puerta de enlace divide el tráfico mediante un recurso HTTPRoute
y, a veces, hay una demora que propaga los cambios realizados en HTTPRoute
. En esos casos, las solicitudes se pueden descartar porque el tráfico se envía a recursos que no están disponibles. Si observas esta demora, puedes usar routeUpdateWaitTime
para hacer que Cloud Deploy espere después de aplicar cambios de HTTPRoute
.
En el siguiente YAML, se muestra cómo configurar una estrategia de implementación de versiones canary personalizada o personalizada. La configuración específica del entorno de ejecución, en la sección runtimeConfig
, se omite para las versiones canary personalizadas, pero se incluye en la configuración de versiones canary automatizadas y personalizadas.
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
Es un valor booleano opcional que indica si se admite o no la verificación de implementación para este destino. El valor predeterminado es false
.
Habilitar la verificación de implementación también requiere una estrofa verify
en skaffold.yaml
. Si no proporcionas esta propiedad, el trabajo de verificación fallará.
deployParameters
Te permite especificar pares clave-valor para pasar valores a manifiestos para destinos con etiquetas coincidentes 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, por cada valor, hay una etiqueta. El valor se aplica al manifiesto para cualquier destino que tenga una etiqueta coincidente.
Trabajos predeploy
y postdeploy
Te permiten hacer referencia a acciones personalizadas (definidas por separado, en skaffold.yaml
) que se ejecutarán antes del trabajo de implementación (predeploy
) y después del trabajo de verificación, si está presente (postdeploy
). Si no hay un trabajo de verificación, el trabajo posterior a la implementación se ejecuta después del trabajo 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]
En el ejemplo anterior, ACTION_NAME es el nombre configurado en skaffold.yaml
para customActions.name
.
Puedes configurar trabajos predeploy
y postdeploy
con cualquier estrategia (standard
, canary
, por ejemplo).
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 los destinos
El archivo de definición de la canalización de entrega puede contener definiciones de destino, o puedes especificar destinos en un archivo separado. Puedes repetir los nombres de destino dentro de un proyecto, 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 destino una vez desde el progreso de una sola canalización de entrega.
Consulta también: Definiciones de los tipos de segmentación personalizados
Para los destinos de GKE
En el siguiente YAML, se muestra cómo configurar un destino que se implemente 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 de Kubernetes y etiquetas, pero Cloud Deploy no las 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 manifiesto, después del procesamiento.
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 en multi-target, el valor se asigna al manifiesto para todos los destinos secundarios de esos destinos múltiples.
multiTarget.targetIds: []
Esta propiedad es opcional y se usa para configurar un multi-target que se usará en la 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 esta
propiedad 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 y no en los secundarios.
gke
Solo para los clústeres de GKE, la ruta del 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, como aparece en tu lista de clústeres en la consola de Google Cloud.
Por ejemplo:
gke:
cluster: projects/cd-demo-01/locations/us-central1/clusters/prod
Omite la propiedad gke
cuando configures una opción de multi-target.
El clúster de GKE se configura en su lugar dentro del destino secundario correspondiente.
Consulta executionConfigs
, en este artículo, para obtener descripciones de las propiedades del entorno de ejecución.
internalIp
Indica si el clúster de GKE especificado usa o no una dirección IP privada. 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 del proxy, que se pasa a kubectl cuando te conectas a tu clúster.
Para los destinos de Cloud Run
En el siguiente YAML, se muestra cómo configurar un destino que se implemente 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 las 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.
multiTarget.targetIds: []
Esta propiedad es opcional y se usa para configurar un multi-target que se usará en la 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 esta
propiedad 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 y no en los secundarios.
run
Solo para los servicios de Cloud Run, la ubicación en la que se creará el servicio:
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 del servicio de Cloud Run se configura dentro del destino 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
La configuración objetivo para implementar en un clúster de GKE es similar a la configuración de 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.
Por ejemplo:
anthosCluster:
membership: projects/cd-demo-01/locations/global/memberships/prod
Omite la propiedad anthosCluster
cuando configures una opción [múltiples destinos]. El clúster de GKE Enterprise se configura dentro del destino secundario correspondiente.
Para obtener más información sobre la implementación en clústeres de GKE, consulta Implementa en clústeres de usuario de Anthos.
Para destinos personalizados
La configuración de los destinos personalizados es similar a todos los demás tipos de objetivos, excepto que no incluye una estrofa gke
, una run
ni una anthosCluster
.
En su lugar, los destinos personalizados incluyen una estrofa customTarget
:
customTarget:
customTargetType: [CUSTOM_TARGET_TYPE_NAME]
En el ejemplo anterior, CUSTOM_TARGET_TYPE_NAME
es el nombre que usaste en la definición del tipo de destino personalizado.
Por 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 destino
usages
RENDER
,DEPLOY
o ambos, másPREDEPLOY
,VERIFY
oPOSTDEPLOY
si la verificación o los hooks de implementación están habilitados en el destino. Estos indican cuál de esas operaciones realizar para este destino mediante este entorno de ejecución. Para indicar que un entorno de ejecución personalizado se usará 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 previos a la implementación y posteriores a ella 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 están configurados en la canalización de entrega.VERIFY
,PREDEPLOY
yPOSTDEPLOY
pueden estar en el mismousages
queRENDER
oDEPLOY
, o enusages
independientes.No puedes especificar
usages.VERIFY
,usages.PREDEPLOY
ousages.POSTDEPLOY
, a menos queRENDER
yDEPLOY
se especifiquen en el mismo entorno de ejecución personalizado o en uno separado.workerPool
La configuración del grupo de trabajadores que se usará. Se toma una ruta de acceso a recursos que identifica el grupo de trabajadores de Cloud Build que se usará para este destino. Por ejemplo:
projects/p123/locations/us-central1/workerPools/wp123
.Para usar el grupo predeterminado de Cloud Build, omite esta propiedad.
Un destino determinado puede tener dos
workerPool
(uno paraRENDER
y otro paraDEPLOY
). Cuando configuras 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á en esta operación (
RENDER
oDEPLOY
) para este destino.artifactStorage
El bucket de Cloud Storage que se usará en esta operación (
RENDER
oDEPLOY
) para este destino, en lugar del bucket predeterminado.executionTimeout
Opcional. Configura el tiempo de espera, en segundos, de las operaciones que realiza Cloud Build para Cloud Deploy. De forma predeterminada, es
3600
segundos (1 hora).
Ejemplo:executionTimeout: "5000s"
verbose
Opcional. Si es
true
, los niveles de verbosidad se establecen endebug
para las siguientes herramientas:--verbosity
de Skaffold está configurado endebug
. La configuración predeterminada de Skaffold eswarn
.kubectl
--v
se configura en4
, que es depuración. El valor predeterminado de kubectl es2
.--verbosity
de Google Cloud CLI está configurado endebug
. El valor predeterminado eswarning
.
Sintaxis alternativa admitida
La configuración de executionConfigs
que se describe en este documento es nueva. Aún 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
multi-target, cada destino secundario
puede heredar ese entorno de ejecución
de ese destino múltiple.
Definiciones de los tipos de segmentación personalizada
En esta sección, se describen los campos que se usan para definir los tipos de destinos personalizados.
Al igual que con los objetivos y las automatizaciones estándar, las definiciones de CustomTargetType
se pueden incluir con la definición de tu 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. Se hace referencia a este nombre en la definición del destino para cualquier destino 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 los recursos de automatización de Cloud Deploy.
Al igual que con los objetivos, las definiciones de Automation
se pueden incluir con la definición de tu canalización de entrega o en uno o varios archivos separados.
Para obtener más información sobre la automatización en Cloud Deploy, consulta la documentación sobre 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 para cada regla. (La configuración de los tipos de reglas de automatización disponibles se encuentra 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 el mismo que el valor
metadata.name
en la canalización de entrega que usa esta automatización. Todas las automatizaciones son exclusivas de las canalizaciones de entrega para las que se crean. Es decir, no puedes compartir una automatización en más de una canalización de entrega.[PURPOSE]
Es cualquier nombre descriptivo adicional para esta automatización. Por lo general, esta sería la acción automatizada. Por ejemplo,
my-app-pipeline/promote
.labels
yannotations
son cualquier etiqueta o anotación que desees asociar a 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 usó para realizar la automatización. Por ejemplo, si la automatización usa
promoteReleaseRule
, esta cuenta de servicio realiza la promoción de lanzamiento y, por lo tanto, requiere los permisos necesarios para promover una versión.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.permission para realizar la operación automatizada; por ejemplo,
clouddeploy.releases.promote
para promocionar una versión oclouddeploy.rollouts.advance
para avanzar en una fase de lanzamiento.
[TARGET_ID]
Es el ID de la orientación para la que se utiliza esta automatización. Aunque la automatización está vinculada a una canalización de entrega, solo se ejecuta en los objetivos especificados.
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 destino. Con esto, se seleccionan todos los destinos asociados con la canalización de entrega que tienen 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. Es
promoteReleaseRule
oadvanceRolloutRule
. Puedes incluir más de una regla en una automatización, incluida más de una de la mismaRULE_TYPE
. Por ejemplo, puedes tener más de una reglapromoteReleaseRule
en la misma 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. Esas configuraciones 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 la versión y la canalización de entrega, obtén información sobre las instancias de canalización.