Referencia del esquema de configuración

Los archivos de configuración de Cloud Deploy definen la canalización de entrega, el objetivos para implementar y el la progresión de esos objetivos.

El archivo de configuración de la canalización de entrega puede incluir en las definiciones de los destinos o en un archivo independiente. archivos. Por convención, un archivo que contiene la configuración de la canalización de entrega y la configuración de destino se llama clouddeploy.yaml, y una configuración de canalización sin objetivos se llama delivery-pipeline.yaml. Pero puedes darles a estos archivos el nombre que quieras.

Nota: Es posible que tu organización prefiera separar las definiciones de destino del definición de la canalización, para que los distintos roles puedan administrar esos parámetros de configuración por separado. Cloud Deploy admite esa práctica.

Componentes

Cloud Deploy usa dos archivos de configuración principales:

• Definición de canalización de entrega
• Definición del objetivo

Pueden ser archivos separados, o la canalización de entrega y los destinos configurados en el mismo archivo.

Nota: Después de definir los archivos de configuración, crea el archivo de la canalización y los recursos de destino con la línea de comandos, como se describe en Registra la canalización de entrega y los destinos.

Estructura de un archivo de configuración de la canalización de entrega

La siguiente configuración incluye una definición de destino:

# Delivery pipeline config
apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
 name:
 annotations:
 labels:
description:
suspended:
serialPipeline:
 stages:
 - targetId:
   profiles: []
# Deployment strategies
# One of:
#   standard:
#   canary:
# See the strategy section in this document for details.
   strategy:
     standard:
       verify:
       predeploy:
         actions: []
       postdeploy:
         actions: []
   deployParameters:
   - values:
     matchTargetLabels:
 - targetId:
   profiles: []
   strategy:
   deployParameters:
---

# Target config
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
 name:
 annotations:
 labels:
description:
multiTarget:
 targetIds: []
deployParameters:
requireApproval:
#
# Runtimes
# one of the following runtimes:
gke:
 cluster:
 internalIp:
 proxyUrl:
#
# or:
anthosCluster:
 membership:
#
# or:
run:
 location:
#
# or:
customTarget:
  customTargetType:
#
# (End runtimes. See documentation in this article for more details.)
#
executionConfigs:
- usages:
  - [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY]
  workerPool:
  serviceAccount:
  artifactStorage:
  executionTimeout:
---

# Custom target type config
apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
  name:
  annotations:
  labels:
description:
customActions:
  renderAction:
  deployAction:
  includeSkaffoldModules:
    - configs:
    # either:
    googleCloudStorage:
      source:
      path:
    # or:
    git:
      repo:
      path:
      ref:
---

# Automation config
apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name:
  labels:
  annotations:
description:
suspended:
serviceAccount:
selector:
- target:
    id:
    # or
    labels:
rules:
- [RULE_TYPE]:
  name:
  [RULE-SPECIFIC_CONFIG]

Este YAML tiene tres componentes principales:

• La canalización de entrega principal y el progreso

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

• Las definiciones de destino

  Para simplificar, en este ejemplo solo se muestra un destino, pero puede haber cantidad de ellos. Además, los destinos se pueden definir en uno o varios archivos separados.

• Definiciones de los tipos de segmentación personalizada

  Orientaciones personalizadas, requieren un tipo de segmentación personalizada definición. Al igual que con los objetivos y las automatizaciones, definidos en el mismo archivo que la canalización de entrega o en un archivo separado.

• Definiciones de automatización

  Puedes crear cualquier automatización de implementación en el como tu canalización de entrega y destinos, o en uno o más archivos separados. Para simplificar, aquí se muestra solo un Automation, pero puedes crear como tantas como quieras.

Estos componentes se definen en el resto de este documento.

Definición y progreso de la canalización

Además de los metadatos de la canalización, como name, la definición de la canalización principal incluye una lista de referencias a objetivos en Deployment. Es decir, el primer objetivo de la lista es el primero de implementación. Después de realizar la implementación en ese destino, promocionar la versión implementa en el siguiente destino de la lista.

Las siguientes son las propiedades de configuración para una canalización de entrega, no incluidas las definiciones de objetivos.

metadata.name

El campo name incluye una cadena que debe ser única por proyecto y ubicación.

metadata.annotations y metadata.labels

La configuración de la canalización de entrega puede incluir anotaciones y etiquetas. Anotaciones y las etiquetas se almacenan con el recurso de canalización de entrega después de que esta Fue registrado.

Para obtener más información, consulta Usa etiquetas y anotaciones con Cloud Deploy.

description

Una cadena arbitraria que describe esta canalización de entrega. Se muestra esta descripción en los detalles de la canalización de entrega en la consola de Google Cloud.

suspended

Un valor booleano, que si true suspende la canalización de entrega de modo que no se puedan usar para crear, promover, revertir ni volver a implementar versiones. Además, si se suspende la canalización de entrega, no puedes aprobar ni rechazar lanzamiento creado a partir de esa canalización.

El valor predeterminado es false.

serialPipeline

El comienzo de la definición de una canalización de entrega de progreso en serie. Esta La estrofa es obligatoria.

stages

Una lista de todos los destinos en los que se puede implementar esta canalización de entrega.

La lista debe estar en el orden de la secuencia de publicación que desees. Por ejemplo: si tienes objetivos llamados dev, staging y production, enuméralos en ese en el mismo orden, para que la primera implementación sea en dev y la última está en production.

Propaga cada campo stages.targetId con el valor de metadata.name en la definición objetivo correspondiente. En targetId, incluye profiles:

serialPipeline:
 stages:
 - targetId:
   profiles: []
   strategy:
     standard:
       verify:

targetId

Identifica el destino específico que se usará para esta etapa de la canalización de entrega. El valor es la propiedad metadata.name de la definición objetivo.

strategy.standard.verify se estableció en true habilitaciones la verificación de la implementación en el destino. Si la respuesta es no se especifica la estrategia de implementación, se usa la estrategia de implementación standard con la verificación establecida en false.

profiles

Toma una lista de cero o más nombres de perfil de Skaffold, de skaffold.yaml. Cloud Deploy usa el perfil con skaffold render cuando crees el lanzamiento. Los perfiles de Skaffold te permiten variar la configuración entre mientras usan un único archivo de configuración.

strategy

Incluye propiedades para especificar una estrategia de implementación. Lo siguiente se admiten las siguientes estrategias:

• standard:

  La aplicación se implementa por completo en el destino especificado.

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

• canary:

  En una implementación de versiones canary, implementarás una versión nueva de tu aplicación de forma progresiva y reemplazará la a la versión en ejecución en incrementos basados en porcentajes (por ejemplo, 25%, luego 50%, luego un 75% y, luego, el total).

La estrategia de implementación se define por objetivo. Por ejemplo, puedes tener un una estrategia de versión canary para su objetivo de prod, pero una estrategia estándar (sin strategy especificada) para los demás destinos.

Para obtener más información, consulta Usa una estrategia de implementación.

Configuración strategy

En esta sección, se muestran los elementos de configuración de strategy para cada uno compatible tiempo de ejecución.

Estrategia de implementación estándar

La estrategia estándar incluye solo los siguientes elementos:

strategy:
  standard:
    verify: true|false

La propiedad verify es opcional. El valor predeterminado es false, lo que significa que habrá No debe haber una fase de verificación para los lanzamientos resultantes.

Puedes omitir el elemento strategy en una instancia estándar de implementación.

Estrategia de implementación de versiones canary

En las siguientes secciones, se describe la configuración de un de implementación de versiones canary, para cada entorno de ejecución compatible con Cloud Deploy.

Para los destinos de Cloud Run

strategy:
  canary:
    runtimeConfig:
      cloudRun:
        automaticTrafficControl: true | false
    canaryDeployment:
      percentages: [PERCENTAGES]
      verify: true | false

Para los destinos de GKE y GKE Enterprise

El siguiente YAML muestra cómo configurar una estrategia de implementación para una destino de GKE o GKE Enterprise, con Herramientas de redes basadas en servicios:

      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              disablePodOverprovisioning: true | false
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true | false

El siguiente YAML muestra cómo configurar una estrategia de implementación para una destino de GKE o GKE Enterprise, con API de Gateway:

      canary:
        runtimeConfig:
          kubernetes:
            gatewayServiceMesh:
              httpRoute: "HTTP_ROUTE_NAME"
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              routeUpdateWaitTime: "WAIT_TIME"
        canaryDeployment:
          percentages: ["PERCENTAGES"]
          verify: true | false

Observa que, en este ejemplo, routeUpdateWaitTime. Esta se incluye porque la API de puerta de enlace divide el tráfico con un recurso HTTPRoute, y, a veces, hay una demora en la propagación de los cambios realizados a HTTPRoute. En En esos casos, las solicitudes podrían descartarse porque el tráfico se envía a los recursos que no están disponibles. Puedes usar routeUpdateWaitTime para provocar Cloud Deploy espere después de aplicar los cambios de HTTPRoute, si notará este retraso.

En el siguiente YAML, se muestra cómo configurar un clúster personalizado o bien automáticamente personalizada de implementación de versiones canary. Configuración específica del entorno de ejecución, en sección runtimeConfig, se omite para las versiones canary personalizadas, pero se incluye en configuración de versiones canary, automatizada y personalizada.

strategy:
       canary:
         # Runtime configs are configured as shown in the
         # Canary Deployment Strategy section of this document.
         runtimeConfig:

         # Manual configuration for each canary phase
         customCanaryDeployment:
           - name: "PHASE1_NAME"
             percent: PERCENTAGE1
             profiles: [ "PROFILE1_NAME" ]
             verify: true | false
           - …
           - name: "stable"
             percent: 100
             profiles: [ "LAST_PROFILE_NAME" ]
             verify: true|false

verify

Booleano opcional que indica si se admite o no la verificación de la implementación para este objetivo. El valor predeterminado es false.

Habilitar la verificación de implementación también requiere una estrofa verify en el skaffold.yaml. Si no proporcionas esta propiedad, el trabajo de verificación fallan.

deployParameters

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 entrega usan etiquetas para hacer coincidir los destinos:

deployParameters:
- values:
    someKey: "value1"
  matchTargetLabels:
    label1: firstLabel
- values:
    someKey: "value2"
  matchTargetLabels:
    label2: secondLabel

En este ejemplo, se proporcionan dos valores para la clave, y para cada valor, hay una etiqueta. El valor se aplica al manifiesto para cualquier destino que tenga un etiqueta coincidente.

Trabajos 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]

Donde ACTION_NAME es el nombre configurado en skaffold.yaml para customActions.name.

Puedes configurar trabajos predeploy y postdeploy con cualquier estrategia. (por ejemplo, standard y canary).

Para obtener más información sobre la configuración y el uso de hooks previos y posteriores a la implementación, consulta Ejecuta hooks antes y después de la implementación.

Definiciones de los destinos

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

El siguiente YAML muestra cómo configurar un destino que Se implementa en un clúster de GKE:

     apiVersion: deploy.cloud.google.com/v1
     kind: Target
     metadata:
      name:
      annotations:
      labels:
     description:
     deployParameters:
     multiTarget:
      targetIds: []

     requireApproval:
     gke:
      cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
      internalIp:
      proxyUrl:

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

metadata.name

El nombre de este destino. Este nombre debe ser único a nivel global.

metadata.annotations y metadata.labels

La configuración de destino admite anotaciones y etiquetas de Kubernetes. pero Cloud Deploy no los requiere.

Las anotaciones y las etiquetas se almacenan con el recurso de destino. Para obtener más información, consulta Usa etiquetas y anotaciones con Cloud Deploy.

description

Este campo toma una cadena arbitraria que describe el uso de este objetivo.

deployParameters

Puedes incluir parámetros de implementación en cualquier destino, junto con los valores. Esos valores se asignan a las claves correspondientes en tu después de la renderización.

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

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

Si configuras parámetros de implementación múltiples objetivos, el valor se asigna a el manifiesto para todas las solicitudes de destinos secundarios.

multiTarget.targetIds: []

Esta propiedad es opcional y se usa para configurar una objetivo múltiple que se utilizará para implementación paralela.

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

requireApproval

Indica si la promoción a este destino requiere aprobación manual. Puede ser true o false

Esta propiedad es opcional. El valor predeterminado es false.

Cuando configuras la implementación paralela, puedes requerir aprobación solo en los destinos múltiples, no en los secundarios.

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, tal como aparece en tu lista de clústeres en 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 varios destinos. El clúster de GKE se configura en su lugar como destino secundario.

Consulta executionConfigs, en este artículo, para obtener descripciones de las propiedades del entorno de ejecución.

internalIp

Define si el clúster de GKE especificado usa o no un dirección IP pública. Esta propiedad es opcional. De forma predeterminada, Cloud Deploy usa la dirección IP disponible públicamente para el clúster. Si hay una 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

El siguiente YAML muestra cómo configurar un destino que implementa en un servicio de Cloud Run:

     apiVersion: deploy.cloud.google.com/v1
     kind: Target
     metadata:
      name:
      annotations:
      labels:
     description:
     multiTarget:
      targetIds: []

     requireApproval:
     run:
      location: projects/[project_name]/locations/[location]

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

metadata.name

El nombre de este destino. Este nombre debe ser único en cada región.

metadata.annotations y metadata.labels

La configuración de destino admite anotaciones y etiquetas, pero Cloud Deploy no los requiere.

Las anotaciones y 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 una objetivo múltiple que se utilizará para implementación paralela.

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

requireApproval

Indica si la promoción a este destino requiere aprobación manual. Puede ser true o false

Esta propiedad es opcional. El valor predeterminado es false.

Cuando configuras la implementación paralela, puedes requerir aprobación solo en los destinos múltiples, no en los secundarios.

run

Solo para los servicios de Cloud Run, la ubicación donde el servicio se crearán:

run:
  location: projects/[project_name]/locations/[location]

• project_name

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

• location

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

Omite la propiedad run cuando configures una opción [múltiples destinos]. La ubicación de la Cloud Run se configura en su lugar dentro del objetivo secundario correspondiente.

Consulta executionConfigs, en este artículo, para obtener descripciones de las propiedades del entorno de ejecución.

Para los destinos de GKE Enterprise

Configuración de destino para implementar en un clúster de GKE es similar a configurar un destino para un destino de GKE excepto que la propiedad es anthosCluster.membership, en lugar de gke.cluster, la ruta del recurso es diferente y internalIp no es aplicable.

anthosCluster:
  membership: projects/[project_name]/locations/global/memberships/[membership_name]

• project_name

  El proyecto de Google Cloud en el que reside el clúster de GKE Enterprise.

• /location/global/

  La ubicación en la que está registrado el clúster. global, en todos los casos.

• membership_name

  El nombre de la membresía del clúster de GKE Enterprise.

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 el clúster de GKE Enterprise se configura dentro del como destino secundario.

Para obtener más información sobre la implementación en clústeres de GKE, consulta Implementa en clústeres de usuario de Anthos.

Para destinos personalizados

La configuración de los destinos personalizados es similar a la siguiente: todos los demás tipos de objetivos, salvo que no incluye una estrofa gke ni una run ni anthosCluster.

En su lugar, los destinos personalizados incluyen una estrofa customTarget:

customTarget:
  customTargetType: [CUSTOM_TARGET_TYPE_NAME]

Donde CUSTOM_TARGET_TYPE_NAME es el nombre que usaste en el definición del tipo de segmentación personalizada.

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 objetivo.

Nota: Todas las propiedades de configuración en executionConfigs son opcionales. No es necesario que especificas un entorno de ejecución si puedes usar el grupo de trabajadores predeterminado, la cuenta de servicio y el bucket de almacenamiento.

• usages

  RENDER, DEPLOY o ambos, más PREDEPLOY, VERIFY o POSTDEPLOY si se trata de verificación o Los hooks de implementación están habilitados en el destino. Estas indican cuál de esas operaciones rendimiento para este objetivo usando entorno de ejecución. Para indicar que un entorno de ejecución personalizado debe usarse para hook previo a la implementación, renderización, implementación, hook posterior a la implementación y 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 estrofa usages, 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 y DEPLOY, debes especificar uno para VERIFY, PREDEPLOY o POSTDEPLOY si son configurados en la canalización de entrega.VERIFY, PREDEPLOY y POSTDEPLOY puede estar en el mismo usages que RENDER o DEPLOY, o en usages separados.

  No puedes especificar usages.VERIFY, usages.PREDEPLOY ni usages.POSTDEPLOY a menos que RENDER y DEPLOY 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 para RENDER y otro para DEPLOY). Cuando configuras el grupo predeterminado, puedes especificar un grupo alternativo cuenta de servicio, ubicación de almacenamiento o ambas.

• serviceAccount

  El nombre de la cuenta de servicio que se usará para esta operación (RENDER o DEPLOY) para este destino.

• artifactStorage

  El bucket de Cloud Storage que se usará para 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 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 en debug para los siguientes elementos: herramientas:

  • Skaffold --verbosity se estableció en debug. La configuración predeterminada de Skaffold es warn.

  • kubectl --v se establece en 4, que es depuración. El valor predeterminado de kubectl es 2.

  • Se configuró Google Cloud CLI --verbosity. a debug. El valor predeterminado es warning.

Nota: Si especificas una configuración para RENDER o DEPLOY, debes hazlo por el otro, incluso si uno usa valores predeterminados (solo el usages: propiedad).

Sintaxis alternativa admitida

La configuración de executionConfigs que se describe en este documento es nueva. El todavía se admite la sintaxis anterior:

executionConfigs:
- privatePool:
    workerPool:
    serviceAccount:
    artifactStorage:
  usages:
  - [RENDER | DEPLOY]
- defaultPool:
    serviceAccount:
    artifactStorage:
  usages:
  - [RENDER | DEPLOY]

Cuando configuras una estrofa executionConfigs para un múltiples destinos, cada objetivo secundario puede heredar ese entorno de ejecución a partir de esos destinos múltiples.

Definiciones de los tipos de segmentación personalizada

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

Al igual que con los objetivos y las automatizaciones estándar, las definiciones de CustomTargetType pueden incluidos en la definición de la canalización de entrega, o en uno o más archivos separados.

En el siguiente YAML, se muestra cómo configurar un tipo de destino personalizado:

apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
  name: [CUSTOM_TARGET_TYPE_NAME]
  annotations:
  labels:
description:
customActions:
  renderAction: [RENDER_ACTION_NAME]
  deployAction: [DEPLOY_ACTION_NAME]
  includeSkaffoldModules:
    - configs:
    # either:
    googleCloudStorage:
      source:
      path:
    # or:
    git:
      repo:
      path:
      ref:

Aquí:

• [CUSTOM_TARGET_TYPE_NAME]

  Es un nombre arbitrario que le asignas a la definición de este tipo de destino personalizado. Este nombre se hace referencia en la definición del destino para cualquier objetivo, que use el tipo de destino personalizado que estás definiendo.

• [RENDER_ACTION_NAME]

  Es el nombre de la acción de renderización personalizada. Este valor es el customAction.name definido 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 Usa la configuración remota de Skaffold.

Definiciones de automatización

En esta sección, se describen los campos que se usan para definir Cloud Deploy automation.

Al igual que con los objetivos, puedes incluir definiciones de Automation con tu publicación definición de la canalización, o en uno o varios archivos separados.

Para obtener más información sobre la automatización en Cloud Deploy, consulta el documentación de automatización.

En el siguiente YAML, se muestra cómo configurar una automatización. Ten en cuenta que los detalles de una regla de automatización son diferentes por 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 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 los que se crearon. Es decir, no puedes compartir una automatización de una canalización de entrega.

• [PURPOSE]

  Es cualquier nombre descriptivo adicional para esta automatización. Por lo general, la acción que está automatizada. Por ejemplo, my-app-pipeline/promote.

• labels y annotations son 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 establece en 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, este la cuenta de servicio realiza la promoción del lanzamiento y, por lo tanto, requiere el 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 o clouddeploy.rollouts.advance para adelantar un lanzamiento en 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 destino. 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 o advanceRolloutRule. Puedes incluir más de un regla de una automatización, lo que incluye más de una de las mismas RULE_TYPE. Para Por ejemplo, puedes tener más de una regla promoteReleaseRule en la misma con la automatización. Obtén más información.

  Nota: Los nombres de regla promoteRelease y advanceRollout siguen siendo compatibles.

• [RULE_NAME]

  Es un nombre para la regla. Este nombre debe ser único dentro de la canalización de entrega. Se requiere un valor para esta propiedad.

• [RULE-SPECIFIC_CONFIG]

  La configuración es diferente para cada tipo de automatización compatible. Los que de configuración se muestran en Usa reglas de automatización.

¿Qué sigue?

• Obtén más información sobre cómo funciona Cloud Deploy.

• Obtén información sobre cómo configurar una canalización de entrega para tu aplicación.

• Obtén información para administrar tus manifiestos.

• Para evitar discrepancias entre tu versión y la canalización de entrega sobre las instancias de canalización.