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 realizará la implementación 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 uno o más archivos separados. Por convención, un archivo que contiene la configuración de la canalización de entrega y las configuraciones de destino se llama clouddeploy.yaml, y una configuración de canalización sin destinos se llama delivery-pipeline.yaml. Sin embargo, puedes asignarles el nombre que desees. Otras definiciones de recursos, como automatizaciones y políticas de implementación, también pueden estar en el mismo archivo que una canalización de entrega o una definición de destino.

Componentes

Cloud Deploy usa dos archivos de configuración principales:

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

A continuación, se muestra la estructura de una configuración de canalización de entrega, incluidas las propiedades para las definiciones de destino. Aquí no se incluyen algunas propiedades de destino. Consulta Definiciones de destino para ver todas las propiedades de configuración del 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:
 dnsEndpoint:
 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 archivo YAML tiene tres componentes principales:

  • La canalización principal de entrega y la progresión

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

  • Las definiciones de destino

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

  • Definiciones de tipos de segmentación personalizada

    Los destinos personalizados requieren una definición de tipo de destino personalizado. Al igual que con los destinos y las automatizaciones, los tipos de destino personalizados se pueden definir en el mismo archivo que la canalización de entrega o en un archivo separado.

  • Definiciones de automatización

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

Estos componentes se definen en el resto de este documento.

Definición y progresión 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 orden de secuencia de implementación. Es decir, el primer destino que aparece en la lista es el primer destino de implementación. Después de que realices la implementación en ese destino, la promoción de la versión se implementará en el siguiente destino de la lista.

A continuación, se indican las propiedades de configuración de una canalización de entrega, sin incluir 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 las etiquetas se almacenan con el recurso de canalización de entrega después de que se registra la canalización.

Para obtener más información, consulta Usa 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 entrega de modo que no se pueda usar para crear, promover, revertir ni volver a implementar versiones. Además, si se suspende la canalización de entrega, no podrás aprobar ni rechazar un lanzamiento creado a partir de esa canalización.

El valor predeterminado es false.

serialPipeline

Es el comienzo de la definición de una canalización de entrega de progresión serial. Esta sección es obligatoria.

stages

Es una lista de todos los destinos en los que se configuró esta canalización de entrega para realizar la implementación.

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

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

Si strategy.standard.verify se configura como true, se habilita la verificación de implementación en el destino. Si no se especifica ninguna 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, de skaffold.yaml. Cloud Deploy usa el perfil con skaffold render cuando crea la versión. Los perfiles de Skaffold te permiten variar la configuración entre los destinos mientras usas un solo archivo de configuración.

strategy

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

  • standard:

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

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

  • canary:

    En una implementación de versiones canary, implementas una nueva versión de tu aplicación de forma progresiva, reemplazando la versión que ya se está ejecutando con incrementos basados en porcentajes (por ejemplo, 25%, luego 50%, luego 75% y, por último, por completo).

La estrategia de implementación se define por objetivo. Por ejemplo, puedes tener una estrategia de lanzamiento gradual para tu objetivo prod, pero una estrategia estándar (sin especificar strategy) 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 entorno de ejecución compatible.

Estrategia de implementación estándar

La estrategia estándar solo incluye 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 las versiones 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 canary para cada entorno de ejecución que admite Cloud Deploy.

Para destinos de Cloud Run
strategy:
  canary:
    runtimeConfig:
      cloudRun:
        automaticTrafficControl: true | false
    canaryDeployment:
      percentages: [PERCENTAGES]
      verify: true | false
Para destinos de GKE y GKE Enterprise

El siguiente código YAML muestra cómo configurar una estrategia de implementación para un destino 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 código YAML muestra cómo configurar una estrategia de implementación para un destino de GKE o GKE Enterprise con la API de Gateway:

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

Observa routeUpdateWaitTime en este ejemplo. Esto 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 estos casos, es posible que se descarten las solicitudes, ya que el tráfico se envía a recursos que no están disponibles. Puedes usar routeUpdateWaitTime para que Cloud Deploy espere después de aplicar los cambios de HTTPRoute, si observas esta demora.

El siguiente código YAML muestra cómo configurar una estrategia de implementación de versiones canary personalizada (para Service Networking, Gateway API o Cloud Run) o una estrategia de implementación de versiones canary automatizada personalizada (para Service Networking, Gateway API o Cloud Run). La configuración específica del tiempo 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 automatizada. ## 

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 sección verify en el archivo skaffold.yaml. Si no proporcionas esta propiedad, fallará el trabajo de verificación.

deployParameters

Te permite especificar pares clave-valor para pasar valores a los manifiestos de los destinos que coinciden con la etiqueta cuando se usan parámetros de implementación.

También puedes incluirlo en targets.

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 una etiqueta coincidente.

Trabajos de predeploy y postdeploy

Estos te permiten hacer referencia a acciones personalizadas (definidas por separado, en skaffold.yaml) para que se ejecuten 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]

Aquí, ACTION_NAME es el nombre configurado en skaffold.yaml para customActions.name.

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

Para obtener más información sobre cómo configurar y usar los hooks previos y posteriores a la implementación, consulta Cómo ejecutar hooks antes y después de la implementación.

Definiciones de destino

El archivo de definición de la canalización de entrega puede contener definiciones de destino, o bien 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 destinos en varias canalizaciones de entrega. Sin embargo, solo puedes hacer referencia a un destino una vez dentro de la progresión de una sola canalización de entrega.

Consulta también Definiciones de tipos de segmentación personalizados.

Para destinos de GKE

El siguiente código 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]
      dnsEndpoint:
      internalIp:
      proxyUrl:

     associatedEntities:
       [KEY]:
         gkeClusters:
         - cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
           dnsEndpoint: [true|false]
           internalIp: [true|false]
           proxyUrl:

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

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 las etiquetas se almacenan con el recurso de destino. Para obtener más información, consulta Usa etiquetas y anotaciones con Cloud Deploy.

description

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

deployParameters

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

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

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

Si estableces parámetros de implementación en un destino múltiple, el valor se asigna al manifiesto de todos los destinos secundarios de ese destino múltiple.

multiTarget.targetIds: []

Esta propiedad es opcional y se usa para configurar un destino múltiple que se usará para la implementación paralela.

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

requireApproval

Indica 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 exigir la aprobación solo en el destino múltiple, no en los destinos secundarios.

gke

Solo para clústeres de GKE, es 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 Google Cloud proyecto 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

    Es el nombre del clúster, tal como aparece en la lista de clústeres en la consola deGoogle Cloud .

Por ejemplo:

gke:
  cluster: projects/cd-demo-01/locations/us-central1/clusters/prod

Omite la propiedad gke cuando configures un multi-target. En cambio, el clúster de GKE se configura dentro del destino secundario correspondiente.

Consulta executionConfigs en este documento para obtener descripciones de las propiedades del entorno de ejecución. Consulta Implementa una HTTPRoute en un clúster diferente para obtener información sobre cómo implementar la HTTPRoute en un clúster alternativo que no sea el de destino.

dnsEndpoint

Cuando se configura en true, Cloud Deploy se conectará al clúster de GKE con el extremo de DNS en lugar del extremo predeterminado, que puede ser una IP pública, una IP privada o el extremo de DNS, según la configuración del clúster.

Esta opción no se puede usar al mismo tiempo que la opción internalIp.

internalIp

Cuando se establece en true, Cloud Deploy se conectará al clúster de GKE con la dirección IP privada en lugar del extremo predeterminado, que puede ser una IP pública, una IP privada o el extremo de DNS, según la configuración del clúster.

Esta opción no se puede usar al mismo tiempo que la opción dnsEndpoint. Dado que la configuración de red para dnsEndpoint es mucho más simple, recomendamos usar esa opción en su lugar.

proxyUrl

Si accedes a los clústeres a través de un proxy HTTP, proporciona la propiedad proxyUrl aquí. El valor es la URL del proxy, que se pasa a kubectl cuando te conectas a tu clúster.

Para destinos de Cloud Run

En el siguiente código 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

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 las etiquetas se almacenan con el recurso de destino. Para obtener más información, consulta Usa etiquetas y anotaciones con Cloud Deploy.

description

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

multiTarget.targetIds: []

Esta propiedad es opcional y se usa para configurar un destino múltiple que se usará para la implementación paralela.

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

requireApproval

Indica 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 exigir la aprobación solo en el destino múltiple, no en los destinos secundarios.

run

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

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

  • project_name

    El Google Cloud proyecto en el que se ejecutará el servicio.

  • location

    Es la ubicación en la que se ejecutará el servicio. Por ejemplo, us-central1.

Omite la propiedad run cuando configures un [multi-target]. En cambio, la ubicación del servicio de Cloud Run se configura dentro del destino secundario correspondiente.

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

Para destinos de GKE Enterprise

La configuración de destino para implementar en un clúster de GKE es similar a la configuración de un destino para un destino de GKE, excepto que la propiedad es anthosCluster.membership, en lugar de gke.cluster, la ruta de acceso al recurso es diferente y no se aplican métodos de conexión específicos (dnsEndpoint o internalIp).

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

  • project_name

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

  • /location/global/

    Es la ubicación en la que se registró el clúster. global, en todos los casos

  • membership_name

    Es 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 cambio, 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 los objetivos personalizados

La configuración de los destinos personalizados es similar a la de todos los demás tipos de destinos, excepto que no incluye una sección gke, ni una sección run, ni una sección anthosCluster.

En cambio, los objetivos personalizados incluyen un párrafo customTarget:

customTarget:
  customTargetType: [CUSTOM_TARGET_TYPE_NAME]

Aquí, CUSTOM_TARGET_TYPE_NAME es el nombre que usaste en la definición del tipo de segmentación personalizado.

Por ejemplo:

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: sample-env
customTarget:
  customTargetType: basic-custom-target

executionConfigs

Es un conjunto de campos para especificar un entorno de ejecución no predeterminado para este destino.

  • usages

    RENDER o DEPLOY, o ambos, más PREDEPLOY, VERIFY o POSTDEPLOY si la verificación o los ganchos de implementación están habilitados en el destino. Indican cuáles de esas operaciones se deben realizar para este destino 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 la canalización y no especificas VERIFY en una sección usages, Cloud Deploy usa el entorno de ejecución predeterminado para la verificación. Los enlaces previos y 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 están configurados en la canalización de entrega.VERIFY, PREDEPLOY y POSTDEPLOY pueden 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 el mismo entorno de ejecución personalizado o en entornos separados.

  • workerPool

    Es la configuración del grupo de trabajadores que se usará. Toma una ruta de acceso al 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 (uno para RENDER y otro para DEPLOY). Cuando configures el grupo predeterminado, puedes especificar una cuenta de servicio o una ubicación de almacenamiento alternativas, o ambas.

  • serviceAccount

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

  • artifactStorage

    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 realiza para Cloud Deploy. De forma predeterminada, es de 3600 segundos (1 hora).
    Ejemplo: executionTimeout: "5000s"

  • verbose

    Opcional. Si es true, los niveles de verbosidad se establecen en debug para las siguientes herramientas:

    • Skaffold --verbosity se configura como debug. El valor predeterminado de Skaffold es warn.

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

    • Google Cloud CLI --verbosity está configurada como debug. El valor predeterminado es warning.

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 sección executionConfigs para un destino múltiple, cada destino secundario puede heredar ese entorno de ejecución del destino múltiple.

Definiciones de tipos de segmentación personalizada

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

Al igual que con los destinos y las automatizaciones estándar, las definiciones de CustomTargetType se pueden incluir 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 esta definición de tipo de objetivo personalizado. Se hace referencia a este nombre en la definición del objetivo de cualquier objetivo que use el tipo de objetivo 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 configuraciones remotas 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 destinos, las definiciones de Automation se pueden incluir con la definición de la canalización de entrega o en uno o más archivos separados.

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

El siguiente código YAML muestra cómo configurar una automatización. Ten en cuenta que los detalles específicos de una regla de automatización varían según la regla. (La configuración de los tipos de reglas de automatización disponibles se encuentra en el documento Cómo usar las 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 de metadata.name en la canalización de entrega que usa esta automatización. Todas las automatizaciones son exclusivas de los canales de entrega para los que se crearon. 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 que se automatiza. 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 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:

    • Permiso de actAs para suplantar la cuenta de servicio de ejecución.

    • Permiso para realizar la operación que se automatiza, por ejemplo, clouddeploy.releases.promote para promover un lanzamiento o clouddeploy.rollouts.advance para avanzar una fase de lanzamiento.

  • [TARGET_ID]

    Es el ID del objetivo para el que se usa esta automatización. Si bien una automatización está vinculada a una canalización de entrega, solo se ejecuta en el destino o los destinos especificados.

    Puedes establecer este parámetro en * para seleccionar todos los objetivos en la canalización de entrega.

  • [LABEL_KEY]:[LABEL_VALUE]

    Es un par clave-valor que se debe comparar con un par clave-valor definido en el destino. Selecciona todos los destinos asociados con la canalización de entrega que tienen la misma etiqueta y el mismo valor.

  • [RULE_TYPE]

    Es el nombre de la regla de automatización que se usa para esta automatización. Puede ser promoteReleaseRule, timedPromoteReleaseRule, advanceRolloutRule o repairRolloutRule. Puedes incluir más de una regla en una automatización, incluidas más de una del mismo RULE_TYPE. Por ejemplo, puedes tener más de una regla de 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 Cómo usar reglas de automatización.

Implementa definiciones de políticas

En esta sección, se describen los campos que se usan para definir las políticas de implementación.

Al igual que con otros recursos de Cloud Deploy, puedes incluir definiciones de DeployPolicy con la definición de tu canalización de entrega o en un archivo separado.

En el siguiente código 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]

    Nombre de la política Este campo toma una cadena que debe ser única por proyecto y ubicación. Debe contener letras minúsculas, números y guiones, con el primer carácter como una letra, el último carácter como una letra o un número, y un máximo de 63 caracteres. Este nombre se usa como nombre visible en la consola deGoogle Cloud .

  • [ANNOTATIONS] y [LABELS]

    Las políticas pueden incluir anotaciones y etiquetas, que forman parte del recurso de 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 configuras suspended como true, se desactivará esta política.

  • [PIPELINE_ID]

    Es el ID de la canalización de entrega que deseas que afecte esta política. Puedes usar * para indicar todas las canalizaciones. Este ID es el mismo que la propiedad metadata.name en la canalización de entrega.

  • [TARGET_ID]

    Es el ID del destino al que deseas que afecte esta política. Puedes usar * para indicar todos los destinos. Este ID es el mismo que la propiedad metadata.name del objetivo.

  • [LABEL_KEY]:[LABEL_VALUE]

    Es un par clave-valor que se debe comparar con un par clave-valor definido en la canalización de entrega o el destino. Esto selecciona todas las canalizaciones o los destinos que tienen la misma etiqueta y el mismo valor. Puedes especificar labels en lugar de id 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 para la regla de política específica que estás creando. La configuración de las reglas se describe más adelante en esta sección de esta referencia, para cada una 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 impide que Cloud Deploy realice ciertas operaciones en las versiones durante el período o los períodos especificados para las canalizaciones de entrega y los destinos indicados por selectors para la política de implementación.

En el siguiente código YAML, se muestra cómo configurar una regla de 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 constar de letras en minúscula, números y guiones, con el primer carácter como una letra, el último carácter como 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: Acciones de lanzamiento que se restringirán como parte de la política. Si está vacío, se restringen todas las acciones. Estos son los valores válidos:

    • ADVANCE

      No se pueden adelantar las fases de lanzamiento.

    • 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

      Los trabajos no se pueden ignorar.

    • RETRY_JOB

      Los trabajos no se pueden reintentar.

    • ROLLBACK

      Las versiones no se pueden revertir.

    • TERMINATE_JOBRUN

      No se pueden finalizar las ejecuciones de trabajos

  • INVOKERS

    Especificar invocadores filtrará la aplicación de la política según si la acción restringida fue invocada por un usuario o por una automatización de implementación. Los valores válidos son los siguientes:

    • USER

      La acción es impulsada por el usuario. Por ejemplo, crear un lanzamiento de forma manual con un comando de gcloud CLI

    • DEPLOY_AUTOMATION

      Es una acción automatizada de Cloud Deploy.

    Puedes especificar uno o ambos valores. Si no especificas nada, el valor predeterminado es ambos.

  • TIMEZONE

    Es la zona horaria, en formato IANA, en la que expresas el período. Por ejemplo, America/New_York Este campo es obligatorio.

  • START_DATE_TIME

    Para oneTimeWindows, la fecha y hora que marcan el inicio del período de restricción, en el formato "yyyy-mm-dd hh:mm". Para el comienzo del día, usa 00:00. Este campo es obligatorio.

  • END_DATE_TIME

    Para oneTimeWindows, la fecha y hora que marcan el final del período de restricción, en el formato "yyyy-mm-dd hh:mm". Para el final del día, usa 24:00. Este campo es obligatorio.

  • DAY_OF_WEEK

    Para weeklyWindows, el día de la semana, SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY o SATURDAY. Si dejas este campo en blanco, coincidirá con todos los días de la semana.

  • START_TIME

    Para weeklyWindows, la hora de inicio del día de la semana especificado. Si incluyes una hora de inicio, también debes incluir una hora de finalización. Para el comienzo del día, usa 00:00.

  • END_TIME

    Para weeklyWindows, es 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, usa 24:00.

¿Qué sigue?