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 bien estas pueden estar en un archivo o archivos separados. 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
. Pero puedes darles a estos archivos
el nombre que quieras. Otras definiciones de recursos, como
automatizaciones y
políticas de implementación, también pueden estar en el mismo archivo que un
la canalización de entrega o la definición del destino.
Componentes
Cloud Deploy usa dos archivos de configuración principales:
- Definición de canalización de entrega
- Definición del objetivo
Estos pueden ser archivos separados, o bien 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:
verbose:
---
# Custom target type config
apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
name:
annotations:
labels:
description:
customActions:
renderAction:
deployAction:
includeSkaffoldModules:
- configs:
# either:
googleCloudStorage:
source:
path:
# or:
git:
repo:
path:
ref:
---
# Automation config
apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
name:
labels:
annotations:
description:
suspended:
serviceAccount:
selector:
- target:
id:
# or
labels:
rules:
- [RULE_TYPE]:
name:
[RULE-SPECIFIC_CONFIG]
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 objetivo, 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
Orientaciones personalizadas, requieren un tipo de segmentación personalizada definición. Al igual que con los objetivos y las automatizaciones, los tipos de objetivos 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 como tu canalización de entrega y 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
de Deployment. Es decir, el primer objetivo de la lista es el primero
de implementación. Después de implementar la versión en ese destino, la promoción de la versión se implementará en el siguiente destino de la lista.
Las siguientes son las propiedades de configuración de una canalización de publicación, 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. 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 Cómo usar etiquetas y anotaciones con Cloud Deploy.
description
Es 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
Es un valor booleano que, si es true
, suspende la canalización de publicación para que no se pueda usar para crear, promocionar, 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 progresión 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
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 del campo metadata.name
en la definición de segmentación correspondiente. Y en targetId
, incluye profiles
:
serialPipeline:
stages:
- targetId:
profiles: []
strategy:
standard:
verify:
targetId
Identifica el objetivo específico que se usará para esta etapa de la canalización de publicación.
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 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 perfiles de Skaffold, desde 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 Canary, implementas una versión nueva de tu aplicación de forma progresiva y reemplazas la versión que ya se está ejecutando por incrementos basados en porcentajes (por ejemplo, 25%, luego 50%, luego 75% y, luego, por completo).
La estrategia de implementación se define por objetivo. Por ejemplo, puedes tener una estrategia Canary para tu objetivo prod
, pero una estrategia estándar (sin strategy
especificado) para tus otros objetivos.
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 no habrá una fase de verificación para los lanzamientos resultantes.
Puedes omitir el elemento strategy
en una instancia estándar
de implementación de Google Cloud.
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
En el siguiente YAML, se muestra cómo configurar una estrategia de implementación para un objetivo de GKE o GKE Enterprise con 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 esperará 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 automáticamente personalizada
de implementación de versiones canary. La configuración específica del entorno de ejecución, en la sección runtimeConfig
, se omite para la versión canary personalizada, pero se incluye en la configuración de la versión canary automática 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
Permite especificar pares clave-valor para pasar valores a manifiestos objetivos de coincidencia de etiqueta cuando se usan 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 publicación usan etiquetas para hacer coincidir los objetivos:
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 predeploy
y postdeploy
Permiten hacer referencia a acciones personalizadas.
(definidos por separado, en
skaffold.yaml
) para ejecutar antes del trabajo de implementación (predeploy
) y después de la verificación
trabajo, 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 que ACTION_NAME es el nombre configurado en skaffold.yaml
para customActions.name
.
Puedes configurar tareas predeploy
y postdeploy
en 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 objetivos
El archivo de definición de la canalización de entrega puede contener definiciones de destino, o puedes especificar objetivos 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 los destinos de GKE
En el siguiente YAML, se 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 objetivo. 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 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 los valores. Esos valores se asignan a las claves correspondientes en tu manifiesto 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 en un objetivo múltiple, el valor se asigna al manifiesto de todos los objetivos secundarios de ese objetivo múltiple.
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
Si la promoción a este objetivo 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 en la que 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 la lista de clústeres de la 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.
En su lugar, el clúster de GKE se configura dentro del objetivo secundario correspondiente.
Consulta executionConfigs
, en este artículo, para obtener descripciones
de las propiedades del entorno de ejecución.
internalIp
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 IP privada
y quieres usarla, establécela en true
.
proxyUrl
Si accedes a los clústeres a través de un proxy, proporciona proxyUrl
.
aquí. El valor es la URL de tu proxy de GKE
clúster, que es
se pasan 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 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 objetivo. 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 un destino múltiple que se usará para la implementación en paralelo.
El valor es una lista separada por comas de objetivos secundarios.
Los destinos secundarios se configuran como objetivos normales y no incluyen
multiTarget
.
requireApproval
Si la promoción a este objetivo requiere aprobación manual Puede ser true
o false
.
Esta propiedad es opcional. El valor predeterminado es false
.
Cuando configuras la implementación en paralelo, puedes solicitar aprobación solo en el destino múltiple, no en los destinos 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 alojará el servicio. Por ejemplo,
us-central1
.
Omite la propiedad run
cuando configures un [multi-target]. 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
La configuración de destino para la implementación 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 de acceso al 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 casosmembership_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 un [multi-target]. En su lugar, 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 usuarios de Anthos.
Para objetivos 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]
En el que CUSTOM_TARGET_TYPE_NAME
es el nombre que usaste en la 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. Estos indican cuál de esas operaciones realizar para este objetivo con este 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. Implementación previa y Los hooks posteriores a la implementación 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
pueden estar en el mismousages
queRENDER
oDEPLOY
, o enusages
separados.No puedes especificar
usages.VERIFY
,usages.PREDEPLOY
niusages.POSTDEPLOY
a menos queRENDER
yDEPLOY
se especifiquen en la misma configuración entornos de ejecución.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 objetivo determinado puede tener dos
workerPool
(uno paraRENDER
y otro paraDEPLOY
). Cuando configuras el grupo predeterminado, puedes especificar un grupo alternativo cuenta de servicio, ubicación de almacenamiento o ambas.serviceAccount
Es el nombre de la cuenta de servicio que se usará para esta operación (
RENDER
oDEPLOY
) para este destino.artifactStorage
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 las siguientes herramientas:Skaffold
--verbosity
se configura comodebug
. La configuración predeterminada de Skaffold eswarn
.kubectl
--v
está configurado en4
, que es depuración. El valor predeterminado de kubectl es2
.Google Cloud CLI
--verbosity
se establece 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 destino múltiple, 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 segmentación personalizados.
Al igual que con los destinos 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 varios 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 objetivo para cualquier objetivo que use el tipo de objetivo personalizado que definas.
[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, 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 publicación 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 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 indica 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
,advanceRolloutRule
orepairRolloutRule
. Puedes incluir más de una regla en una automatización, incluida más de una de las mismoRULE_TYPE
. Por ejemplo, puedes tener más de unpromoteReleaseRule
. en la misma automatizació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 Cómo usar reglas de automatización.
Implementa definiciones de políticas (versión preliminar)
En esta sección, se describen los campos que se usan para definir implementar políticas.
Al igual que con otros recursos de Cloud Deploy, puedes incluir DeployPolicy
con la definición de tu canalización de entrega o en un archivo separado.
En el siguiente YAML, se muestra cómo configurar una política de implementación:
apiVersion: deploy.cloud.google.com/v1
kind: DeployPolicy
metadata:
name: [POLICY_NAME]
annotations: [ANNOTATIONS]
labels: [LABELS]
description: [DESCRIPTION]
suspended: [true | false]
selectors:
- deliveryPipeline:
id: [PIPELINE_ID]
labels:
[LABEL_KEY]:[LABEL_VALUE]
target:
id: [TARGET_ID]
labels:
[LABEL_KEY]:[LABEL_VALUE]
rules:
- [RULE_TYPE]
[CONFIGS]
Aquí:
[DESCRIPTION]
Es un texto opcional que describe esta política.
[POLICY_NAME]
Un nombre para la política. Este campo toma una cadena que debe ser única el proyecto y la ubicación. Debe contener letras minúsculas, números y guiones, con el primer carácter como una letra, el último como una letra o un número, y un máximo de 63 caracteres. Este nombre se usa como un nombre visible en el Consola de Google Cloud
[ANNOTATIONS]
y[LABELS]
Las políticas pueden incluir anotaciones y etiquetas, que forman parte del recurso de la política después de su creación. Para obtener más información, consulta Cómo usar anotaciones y etiquetas con Cloud Deploy.
suspended: [true | false]
Si estableces
suspended
comotrue
, se desactivará esta política.[PIPELINE_ID]
Es el ID de la canalización de entrega a la que quieres que afecte esta política. Puedes usa
*
para denotar todas las canalizaciones. Este ID es el mismo que la propiedadmetadata.name
en la canalización de publicación.[TARGET_ID]
Es el ID del objetivo al que deseas que se aplique esta política. Puedes usar
*
para lo siguiente: denotar todos los objetivos. Este ID es el mismo que elmetadata.name
propiedad en el objetivo.[LABEL_KEY]:[LABEL_VALUE]
Es un par clave-valor que debe coincidir con un par clave-valor definido en la publicación. canalización o destino. Esto selecciona todas las canalizaciones o los objetivos que tienen la misma etiqueta y valor. Puedes especificar
labels
en lugar deid
o además de este.[RULE_TYPE]
Es el tipo de regla de política específica que estás configurando. El único valor válido es
rolloutRestriction
[CONFIGS]
Es el conjunto de propiedades de configuración de la regla de política específica que estás creando. Se describe la configuración de las reglas más adelante en esta sección de esta referencia para cada uno de las reglas disponibles.
Implementa reglas de políticas
En esta sección, se describe cómo configurar cada regla de política de implementación.
rolloutRestriction
La regla rolloutRestriction
evita que Cloud Deploy realice
ciertas operaciones en los lanzamientos durante el
período o los períodos especificados, para las canalizaciones de entrega y los objetivos
que indica el selectors
para la política de implementación.
En el siguiente YAML, se muestra cómo configurar una regla rolloutRestriction
:
rules:
- rolloutRestriction:
id: [RULE_ID]
actions:
- [ACTIONS]
invokers:
- [INVOKERS]
timeWindows:
timeZone: [TIMEZONE]
oneTimeWindows:
- start: [START_DATE_TIME]
end: [END_DATE_TIME]
weeklyWindows:
- daysOfWeek:
- [DAY_OF_WEEK]
- [DAY_OF_WEEK]
startTime: [START_TIME]
endTime: [END_TIME]
Aquí:
RULE_ID
Es un identificador para esta regla. Este campo es obligatorio. Debe incluir letras minúsculas, números y guiones, con el primer carácter una letra, el último carácter una letra o un número, y un máximo de 63 caracteres. Debe ser único dentro de la política de implementación.
ACTIONS
Opcional: Lanzamiento de acciones que se restringirán como parte de la política. Si está vacía, todas las acciones están restringidas. Estos son los valores válidos:
ADVANCE
Las fases de lanzamiento no pueden avanzada.
APPROVE
No se puede aprobar la promoción de lanzamiento.
CANCEL
No se pueden cancelar los lanzamientos.
CREATE
No se pueden crear lanzamientos.
IGNORE_JOB
No se pueden ignorar las tareas.
RETRY_JOB
No se pueden reintentar trabajos.
ROLLBACK
Los lanzamientos no se pueden revertir.
TERMINATE_JOBRUN
Las ejecuciones de trabajos no se pueden finalizar.
INVOKERS
Especificar invocadores filtrará la aplicación forzosa de políticas según si un usuario o una automatización de implementación invocó la acción que se restringe. Válida son los siguientes:
USER
La acción es impulsada por el usuario. Por ejemplo, crear un lanzamiento de forma manual gcloud CLI.
DEPLOY_AUTOMATION
Una acción automatizada de Cloud Deploy.
Puedes especificar uno o ambos valores. El valor predeterminado, si especificas nada, es ambas cosas.
TIMEZONE
Es la zona horaria, en formato IANA, en la que expresas el intervalo de tiempo. Por ejemplo,
America/New_York
Este campo es obligatorio.START_DATE_TIME
Para
oneTimeWindows
, la fecha y hora que marca el comienzo de la ventana de restricción, en el formato"yyyy-mm-dd hh:mm"
. Para los inicios del del día, usa00:00
. Este campo es obligatorio.END_DATE_TIME
Para
oneTimeWindows
, la fecha y hora que marca el final de la restricción en el formato"yyyy-mm-dd hh:mm"
. Para el final del día, usa24:00
. Este campo es obligatorio.DAY_OF_WEEK
Para
weeklyWindows
, el día de la semana,SUNDAY
,MONDAY
,TUESDAY
,WEDNESDAY
,THURSDAY
,FRIDAY
oSATURDAY
. Si dejas este campo en blanco, se mostrará todos los días de la semana.START_TIME
Para
weeklyWindows
, es la hora de inicio del día de la semana especificado. Si incluyes una hora de inicio, debes incluir una hora de finalización. Para el comienzo del día, usa00:00
.END_TIME
Para
weeklyWindows
, la hora de finalización del día de la semana especificado. Si incluyes una hora de inicio, debes incluir una hora de finalización. Para el final del día, usa24:00
.
¿Qué sigue?
Obtén más información sobre cómo funciona Cloud Deploy.
Obtén más información para configurar una canalización de publicación 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.