Referencia del esquema de configuración

El archivo o 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 los parámetros de configuración de destino se llama clouddeploy.yaml, y una configuración de la canalización sin objetivos 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:

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:
#
# 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 la progresión

    El archivo de configuración puede incluir cualquier cantidad de definiciones de canalización.

  • Las definiciones de los destinos

    Para simplificar, solo se muestra un objetivo en este ejemplo, pero puede haber cualquier número de ellos. Además, los destinos se pueden definir en uno o varios archivos independientes.

  • Definiciones de los tipos de segmentaciones personalizadas

    Los destinos personalizados requieren una definición del tipo de destino personalizado. Al igual que con los destinos 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 independiente.

  • Definiciones de la automatización

    Puedes crear cualquier automatización de implementación en el mismo archivo que tu canalización y destinos de entrega, o en uno o más archivos separados. Para simplificar, aquí solo se muestra 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 la canalización, como name, la definición de la canalización principal incluye una lista de referencias a destinos en el orden de la secuencia de implementación. Es decir, el primer destino de la lista es el primero de implementación. Después de implementar en ese destino, la promoción de la versión se implementa en el siguiente destino de la lista.

Las siguientes son las propiedades de configuración de una canalización de entrega, no incluyen las definiciones de destino.

metadata.name

El campo name toma 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 etiquetas se almacenan con el recurso de canalización de entrega después de que se registró la canalización.

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 configuró esta canalización de entrega para implementarse.

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 implementación final esté en production.

Propaga cada campo stages.targetId con el valor del campo metadata.name en la definición del objetivo correspondiente. Y 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 del destino.

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 utiliza 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, 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 objetivos 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 implementó por completo en el destino especificado.

    Esta es la estrategia de implementación predeterminada. Si omites strategy, Cloud Deploy usa la estrategia de implementación standard.

  • canary:

    En una implementación de versiones canary, implementas una versión nueva de la aplicación de forma progresiva, reemplazando 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 de versiones canary para tu objetivo de prod, pero una estrategia estándar (sin strategy especificada) para tus otros 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 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 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 las 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 routeUpdateWaitTime en este ejemplo. Se incluye porque la API de Gateway divide el tráfico con un recurso HTTPRoute y, a veces, hay una demora en la propagación de los cambios realizados en HTTPRoute. En esos casos, es posible que se descarten las solicitudes porque el tráfico se envía a recursos que no están disponibles. Puedes usar routeUpdateWaitTime para hacer que Cloud Deploy espere después de aplicar los cambios de HTTPRoute, si observas este retraso.

En el siguiente YAML, se muestra cómo configurar una estrategia de implementación de versiones canary personalizada o personalizada y automatizada. 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 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

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 la 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 con el fin de pasar valores a los manifiestos para objetivos de coincidencia de etiquetas cuando usas parámetros de implementación.

También puedes incluirlo en los objetivos.

Implementa los parámetros establecidos en una canalización de entrega, usa etiquetas para que coincidan con 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, se proporciona una etiqueta. El valor se aplica al manifiesto para cualquier destino que tenga una etiqueta que coincida.

Trabajos predeploy y postdeploy

Estos 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 los trabajos predeploy y postdeploy en cualquier estrategia (por ejemplo, standard, 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 los objetivos

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 dentro de 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 objetivos personalizados

Para 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:

     executionConfigs:
     - usages:
       - [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY]
       workerPool:
       serviceAccount:
       artifactStorage:
       executionTimeout:

metadata.name

Es 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 las 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 destino.

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 de la renderización.

La estrofa deployParameters toma pares clave-valor, como se muestra a continuación:

deployParameters:
  someKey: "someValue"
  someOtherKey: "someOtherValue"

Si configuras los parámetros de implementación en un 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 en paralelo.

El valor es una lista de destinos secundarios separados por comas. Los destinos secundarios se configuran como destinos normales y no incluyen esta propiedad multiTarget.

requireApproval

Indica si la promoción para 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 solicitar aprobación solo en destinos múltiples, no en destinos secundarios.

gke

Solo para los 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

    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 un multi-target. En su lugar, el clúster de GKE está configurado 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 una dirección IP privada o no. Esta propiedad es opcional. Según la configuración 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, establécela en true.

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:

metadata.name

Es el nombre de este destino. Este nombre debe ser único por 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 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 destino.

multiTarget.targetIds: []

Esta propiedad es opcional y se usa para configurar un multi-target que se usará en la implementación en paralelo.

El valor es una lista de destinos secundarios separados por comas. Los destinos secundarios se configuran como destinos normales y no incluyen esta propiedad multiTarget.

requireApproval

Indica si la promoción para 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 solicitar aprobación solo en destinos múltiples, no en 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

    Es el proyecto de Google Cloud en el que se alojará el servicio.

  • location

    Es la ubicación donde se brindará el servicio. Por ejemplo, us-central1.

Omite la propiedad run cuando configures un [multi-target]. La ubicación del servicio de Cloud Run se configura 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 a fin de implementar en un clúster de GKE es similar a la configuración de 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 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 usuario de Anthos.

Para destinos personalizados

La configuración de los destinos personalizados es similar a todos los demás tipos de destinos, excepto que no incluye una estrofa gke, ni 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 a fin de especificar un entorno de ejecución no predeterminado para este destino.

  • usages

    RENDER o DEPLOY o ambos, más PREDEPLOY, VERIFY o POSTDEPLOY si los hooks de verificación o 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. Si deseas indicar que un entorno de ejecución personalizado se usará para el hook, el procesamiento, la implementación, el hook posterior a la implementación y la verificación antes de la implementació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 estrofa usages, 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 y DEPLOY, debes especificar uno para VERIFY, PREDEPLOY O POSTDEPLOY si están configurados en la canalización de entrega.VERIFY, PREDEPLOY y POSTDEPLOY pueden estar en el mismo usages que RENDER o DEPLOY, o pueden estar en usages independientes.

    No puedes especificar usages.VERIFY, usages.PREDEPLOY ni usages.POSTDEPLOY, a menos que RENDER y DEPLOY se especifiquen en el mismo entorno de ejecución personalizado o en uno distinto.

  • workerPool

    Configuración del grupo de trabajadores que se usará. Para ello, se usa una ruta de acceso del recurso 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 (una para RENDER y otra para DEPLOY). 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 o DEPLOY) para este destino.

  • artifactStorage

    Es el bucket de Cloud Storage que se usará en esta operación (RENDER o DEPLOY) 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. El valor predeterminado es de 3600 segundos (1 hora).
    Ejemplo: executionTimeout: "5000s"

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 de 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 segmentaciones personalizadas

En esta sección, se describen los campos que se usan para definir tipos de destinos personalizados

Al igual que con los destinos y automatizaciones estándar, las definiciones de CustomTargetType se pueden incluir en la definición de tu canalización de entrega o en uno o más archivos independientes.

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 esta definición de tipo de destino personalizado. Se hace referencia a este nombre en la definición de 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 en skaffold.yaml.

  • [DEPLOY_ACTION_NAME]

    Es el nombre de la acción de implementación personalizada. Este valor es el customAction.name definido en skaffold.yaml.

  • Para includeSkaffoldModules, consulta Cómo usar configuraciones remotas de Skaffold.

Definiciones de la 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 destinos, las definiciones de Automation se pueden incluir con la definición de la 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 por 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 otro nombre descriptivo para esta automatización. Por lo general, esta sería la acción automatizada. Por ejemplo, my-app-pipeline/promote.

  • labels y annotations son todas las etiquetas o anotaciones que deseas asociar con esta automatización.

  • [DESCRIPTION]

    Es una descripción opcional para esta automatización.

  • suspended

    true o false, que indican si esta automatización está activa o suspendida. Si se configura como true, 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, esta cuenta de servicio realiza la promoción de la versión 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:

    • actAs para usar la identidad de la cuenta de servicio de ejecución.

    • permiso para realizar la operación que se automatiza, por ejemplo, clouddeploy.releases.promote para ascender una versión o clouddeploy.rollouts.advance para avanzar en una fase de lanzamiento.

  • [TARGET_ID]

    Es el ID del destino para el que se usa esta automatización. Aunque una automatización está vinculada a una canalización de entrega, solo se ejecuta en los destinos 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 objetivo. Mediante esta acción, se seleccionan todos los destinos asociados con la canalización de entrega que tengan la misma etiqueta y valor.

  • [RULE_TYPE]

    Es el nombre de la regla de automatización que se usa para esta automatización. Es promoteReleaseRule o advanceRolloutRule. Puedes incluir más de una regla en una automatización, incluso más de una de las mismas RULE_TYPE. Por ejemplo, puedes tener más de una regla promoteReleaseRule 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?