Referencia del esquema de configuración

El archivo o los archivos de configuración de Cloud Deploy definen la pipeline de entrega, los destinos en los que se va a implementar y la progresión de esos destinos.

El archivo de configuración de la canalización de entrega puede incluir definiciones de destino, o bien estas pueden estar en un archivo o archivos independientes. Por convención, un archivo que contiene tanto la configuración del flujo de procesamiento de entrega como las configuraciones de destino se denomina clouddeploy.yaml, y un archivo de configuración de flujo de procesamiento sin destinos se denomina delivery-pipeline.yaml. Pero puedes darles el nombre que quieras. Otras definiciones de recursos, como automatizaciones y políticas de implementación, también pueden estar en el mismo archivo que una definición de canalización de entrega o de destino.

Cada cosa en su lugar

Cloud Deploy usa dos archivos de configuración principales:

Pueden ser archivos independientes o se pueden configurar la canalización de entrega y los destinos en el mismo archivo.

Estructura de un archivo de configuración de flujo de procesamiento de entrega

A continuación, se muestra la estructura de una configuración de flujo de procesamiento de entrega, incluidas las propiedades de las definiciones de destino. Algunas propiedades de destino no se incluyen aquí. Consulta las definiciones de destino para ver todas las propiedades de configuració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:
 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:
  targets:
    -  id: [TARGET_ID]
       labels:
         [LABEL_KEY]:[LABEL_VALUE]
rules:
- [RULE_TYPE]:
  name:
  [RULE-SPECIFIC_CONFIG]

Este archivo YAML tiene tres componentes principales:

  • El flujo de procesamiento de entrega principal y la progresión

    El archivo de configuración puede incluir cualquier número de definiciones de canalizaciones.

  • Las definiciones de destino

    Para simplificar el ejemplo, solo se muestra un objetivo, pero puede haber tantos como quieras. Además, los destinos se pueden definir en uno o varios archivos independientes.

  • Definiciones de tipos de segmentación personalizada

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

  • Definiciones de automatización

    Puedes crear cualquier automatización de la implementación en el mismo archivo que tu canalización de entrega y tus destinos, o en uno o varios archivos independientes. 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 principal de la canalización 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. Una vez que hayas implementado la versión en ese destino, al promocionarla, se implementará en el siguiente destino de la lista.

A continuación, se muestran las propiedades de configuración de un flujo de procesamiento de entrega, sin incluir las definiciones de destino.

metadata.name

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

metadata.annotations y metadata.labels

La configuración del flujo de procesamiento de entrega puede incluir anotaciones y etiquetas. Las anotaciones y las etiquetas se almacenan con el recurso de la canalización de entrega después de que la canalización se haya registrado.

Para obtener más información, consulta el artículo Usar etiquetas y anotaciones con Cloud Deploy.

description

Cadena arbitraria que describe este flujo de procesamiento 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 es true, suspende la canalización de entrega para que no se pueda usar para crear, promocionar, restaurar ni volver a implementar lanzamientos. Además, si se suspende el flujo de procesamiento, no podrás aprobar ni rechazar un lanzamiento creado a partir de ese flujo.

El valor predeterminado es false.

serialPipeline

El inicio de la definición de una canalización de entrega de progresión en serie. Esta stanza es obligatoria.

stages

Lista de todos los destinos en los que se ha configurado este pipeline de lanzamiento.

La lista debe estar en el orden de la secuencia de entrega que quieras. Por ejemplo, si tienes los destinos dev, staging y production, inclúyelos en ese mismo orden para que la primera implementación sea en dev y la última en production.

Rellene cada campo stages.targetId con el valor del campo metadata.name de la definición de destino correspondiente. En targetId, incluya lo siguiente: profiles

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

targetId

Identifica el destino específico que se va a usar en esta fase de la canalización de entrega. El valor es la propiedad metadata.name de la definición de destino.

strategy.standard.verify se define como true para habilitar la verificación de la 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 definida como 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 al crear 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 omite strategy, Cloud Deploy utiliza la estrategia de despliegue standard.

  • canary:

    En un despliegue canario, se despliega una nueva versión de la aplicación de forma progresiva, sustituyendo la versión que ya está en ejecución por incrementos basados en porcentajes (por ejemplo, 25 %, 50 %, 75 % y, por último, el 100 %).

La estrategia de implementación se define por cada destino. Por ejemplo, puede tener una estrategia de lanzamiento de versiones de prueba para su prod objetivo, pero una estrategia estándar (sin strategy especificado) para los demás objetivos.

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

Configuración de strategy

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

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á ninguna fase de verificación en las implementaciones resultantes.

Puede omitir el elemento strategy en una estrategia de implementación estándar.

Estrategia de despliegue canary

En las siguientes secciones se describe la configuración de una estrategia de despliegue canario para cada tiempo 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

En el caso de los destinos de Cloud Run, AutomaticTrafficControl debe ser true, a menos que estés configurando un canario personalizado.

Para destinos de GKE y GKE Enterprise

El siguiente archivo YAML muestra cómo configurar una estrategia de despliegue para un destino de GKE o GKE Enterprise mediante la red basada en servicios:

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

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

Fíjate en este ejemplo:routeUpdateWaitTime. Se incluye porque la API Gateway divide el tráfico mediante un recurso HTTPRoute y, a veces, hay un retraso en la propagación de los cambios realizados en HTTPRoute. En estos casos, es posible que se rechacen 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 este retraso.

El siguiente archivo YAML muestra cómo configurar una estrategia de implementación canary personalizada (para redes de servicios, API de gateway o Cloud Run) o una estrategia de implementación canary personalizada y automatizada (para redes de servicios, API de gateway o Cloud Run). La configuración específica del tiempo de ejecución, en la sección runtimeConfig, se omite en la versión canary personalizada, pero se incluye en la configuración canary automatizada y personalizada automatizada.

Configuración de Canary 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

Valor booleano opcional que indica si se admite o no la verificación de la implementación en este destino. El valor predeterminado es false.

Para habilitar la verificación de la implementación, también se necesita una estrofa verify en el skaffold.yaml. Si no proporciona esta propiedad, el trabajo de verificación fallará.

deployParameters

Le permite especificar pares clave-valor para transferir valores a los manifiestos de los destinos que coincidan con la etiqueta cuando utilice parámetros de implementación.

También puedes incluirlo en targets.

Los parámetros de implementación definidos en una canalización de distribución usan etiquetas para buscar coincidencias con 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 de cualquier destino que tenga una etiqueta coincidente.

predeploy y postdeploy tareas

Te permiten hacer referencia a acciones personalizadas (definidas por separado en skaffold.yaml) que se ejecutan antes del trabajo de implementación (predeploy) y después del trabajo de verificación, si está presente (postdeploy). Si no hay ningún trabajo de verificación, el trabajo posterior a la implementación se ejecuta después del trabajo de implementación.

Los ganchos 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 de predeploy y postdeploy con cualquier estrategia (standard o 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 Ejecutar hooks antes y después de la implementación.

Definiciones de segmentación

El archivo de definición de la canalización de lanzamiento puede contener definiciones de destino, o bien puede especificar los destinos en un archivo independiente. Puedes repetir los nombres de los elementos de destino en un proyecto, pero deben ser únicos en una canalización de entrega.

Puedes reutilizar los destinos en varias canalizaciones de entrega. Sin embargo, solo puedes hacer referencia a un destino una vez en la progresión de una única canalización de entrega.

Consulte también Definiciones de tipos de segmentación personalizada.

Para destinos de GKE

En el siguiente archivo 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]
      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

Nombre de este objetivo. Este nombre debe ser único en todo el mundo.

metadata.annotations y metadata.labels

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

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

description

Este campo acepta una cadena arbitraria que describe el uso de este destino.

deployParameters

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

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

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

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

multiTarget.targetIds: []

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

El valor es una lista separada por comas de elementos secundarios. Los elementos de destino secundarios se configuran como elementos de destino 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.

Si configuras la implementación paralela, puedes requerir aprobación solo en el elemento de segmentación múltiple, no en los elementos de segmentación secundarios.

gke

Solo para clústeres de GKE, la ruta del recurso que identifica el clúster en el que se desplegará tu aplicación:

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

  • project_name

    El Google Cloud proyecto en el que se encuentra el clúster.

  • location

    Ubicación en la que se encuentra 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 la lista de clústeres de la consola deGoogle Cloud .

Veamos un ejemplo:

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

Omite la propiedad gke al configurar un multi-target. En su lugar, el clúster de GKE se configura en el elemento de destino secundario correspondiente.

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

dnsEndpoint

Si se define como true, Cloud Deploy se conectará al clúster de GKE mediante el endpoint de DNS en lugar del endpoint predeterminado, que puede ser una IP pública, una IP privada o el endpoint de DNS, en función de la configuración del clúster.

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

internalIp

Si se define como true, Cloud Deploy se conectará al clúster de GKE mediante la dirección IP privada en lugar del endpoint predeterminado, que puede ser una IP pública, una IP privada o el endpoint de DNS, en función de la configuración del clúster.

Esta opción no se puede usar al mismo tiempo que la opción dnsEndpoint. Como la configuración de red de dnsEndpoint es mucho más sencilla, te recomendamos que utilices esa opción.

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 transfiere a kubectl al conectarse al clúster.

Para los destinos de Cloud Run

En el siguiente archivo 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

Nombre de este objetivo. 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 el artículo Usar etiquetas y anotaciones con Cloud Deploy.

description

Este campo acepta 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 una implementación paralela.

El valor es una lista separada por comas de elementos secundarios. Los elementos de destino secundarios se configuran como elementos de destino 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.

Si configuras la implementación paralela, puedes requerir aprobación solo en el elemento de segmentación múltiple, no en los elementos de segmentación secundarios.

run

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

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

  • project_name

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

  • location

    Ubicación en la que se alojará el servicio. Por ejemplo, us-central1.

Omite la propiedad run al configurar un [multi-target]. En su lugar, la ubicación del servicio de Cloud Run se configura en el elemento secundario correspondiente.

Consulte 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 de un destino de GKE, excepto que la propiedad es anthosCluster.membership en lugar de gke.cluster, la ruta del recurso es diferente y no se pueden usar métodos de conexión específicos (dnsEndpoint o internalIp).

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

  • project_name

    El Google Cloud proyecto 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

    Nombre del grupo de miembros del clúster de GKE Enterprise.

Veamos un ejemplo:

anthosCluster:
  membership: projects/cd-demo-01/locations/global/memberships/prod

Omite la propiedad anthosCluster al configurar un [multi-target]. El clúster de GKE Enterprise se configura en el elemento de destino secundario correspondiente.

Para obtener más información sobre cómo implementar en clústeres de GKE, consulta el artículo Implementar en clústeres de usuarios de Anthos.

Para objetivos personalizados

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

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

customTarget:
  customTargetType: [CUSTOM_TARGET_TYPE_NAME]

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

Veamos un ejemplo:

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

executionConfigs

Conjunto de campos para especificar un entorno de ejecución no predeterminado para este elemento de destino.

  • usages

    RENDER o DEPLOY o ambos, además de PREDEPLOY, VERIFY o POSTDEPLOY si la verificación o los hooks de implementación están habilitados en el destino. Indican qué operaciones se van a realizar en este destino con este entorno de ejecución. Para indicar que se va a usar un entorno de ejecución personalizado para los hooks predeploy, render, deploy y postdeploy, así como para la verificación, se configuraría de la siguiente manera:

    usages:
- RENDER
- PREDEPLOY
- DEPLOY
- VERIFY
- POSTDEPLOY

    Si la verificación está habilitada en la fase de la canalización y no especificas VERIFY en una estrofa usages, Cloud Deploy usará el entorno de ejecución predeterminado para la verificación. Los hooks de predespliegue y postdespliegue funcionan de la misma forma.

    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 el flujo de procesamiento de entrega.VERIFY, PREDEPLOY y POSTDEPLOY pueden estar en el mismo usages que RENDER o DEPLOY, o 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 entornos diferentes.

  • workerPool

    Configuración del grupo de trabajadores que se va a usar. Se trata de una ruta de recurso que identifica el grupo de trabajadores de Cloud Build que se va a usar en este destino. Por ejemplo:

    projects/p123/locations/us-central1/workerPools/wp123.

    Para usar el grupo de Cloud Build predeterminado, omite esta propiedad.

    Un destino determinado puede tener dos workerPools (uno para RENDER y otro para DEPLOY). Al configurar 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 va a usar en esta operación (RENDER o DEPLOY) para este destino.

  • artifactStorage

    El segmento de Cloud Storage que se va a usar en esta operación (RENDER o DEPLOY) para este destino, en lugar del segmento predeterminado.

  • executionTimeout

    Opcional. Define el tiempo de espera, en segundos, de las operaciones que Cloud Build realiza para Cloud Deploy. De forma predeterminada, es de 3600 segundos (1 hora).
    Ejemplo: executionTimeout: "5000s"

  • verbose

    Opcional. Si el valor es true, los niveles de verbosidad se definen como debug para las siguientes herramientas:

    • Skaffold --verbosity tiene el valor debug. El valor predeterminado de Skaffold es warn.

    • kubectl --v tiene el valor 4, que es debug. El valor predeterminado de kubectl es 2.

    • Google Cloud CLI --verbosity se ha definido en debug. El valor predeterminado es warning.

Sintaxis alternativa admitida

La configuración executionConfigs descrita en este documento es nueva. La sintaxis anterior sigue siendo compatible:

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

Cuando configuras una estrofa executionConfigs para un multi-target, cada target secundario puede heredar ese entorno de ejecución del multi-target.

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 las automatizaciones y los objetivos estándar, las definiciones de CustomTargetType se pueden incluir en la definición de la canalización de entrega o en uno o varios archivos independientes.

En el siguiente archivo 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:

Donde:

  • [CUSTOM_TARGET_TYPE_NAME]

    Es un nombre arbitrario que asignas a esta definición de tipo de segmentación personalizada. Este nombre se menciona en la definición de segmentación de cualquier segmentación que use el tipo de segmentación personalizada 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 Usar 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 en la definición de la canalización de entrega o en uno o varios archivos independientes.

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

El siguiente archivo YAML muestra cómo configurar una automatización. Ten en cuenta que los detalles de una regla de automatización varían en función de la regla. (La configuración de los tipos de reglas de automatización disponibles se encuentra en el documento Usar 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]

Donde:

  • [PIPELINE_NAME]

    Es el mismo valor que el de metadata.name en la canalización de entrega que usa esta automatización. Todas las automatizaciones son exclusivas de las canalizaciones de lanzamiento para las que se crean. Es decir, no puedes compartir una automatización en más de un flujo de procesamiento de entrega.

  • [PURPOSE]

    Es un nombre descriptivo adicional para esta automatización. Normalmente, esta sería la acción que se automatiza. Por ejemplo, my-app-pipeline/promote.

  • labels y annotations son las etiquetas o anotaciones que quieras asociar a esta automatización.

  • [DESCRIPTION]

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

  • suspended

    true o false, que indica si la automatización está activa o suspendida. Si se le asigna el valor true, no se usa la automatización. Esto puede ser útil para probar una automatización sin afectar al flujo de procesamiento de la entrega.

  • [SERVICE_ACCOUNT_ID]

    Es el ID de la cuenta de servicio que se usa para llevar a cabo la automatización. Por ejemplo, si la automatización usa promoteReleaseRule, esta cuenta de servicio lleva a cabo la promoción de la versión y, por lo tanto, requiere los permisos necesarios para promocionar 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 representar la cuenta de servicio de ejecución.

    • permiso para realizar la operación que se va a automatizar; por ejemplo, clouddeploy.releases.promote para promocionar una versión 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. Aunque una automatización está vinculada a una canalización de entrega, solo se ejecuta en el objetivo o los objetivos especificados.

    Puede definir este valor como * para seleccionar todos los destinos de la canalización de entrega.

  • [LABEL_KEY]:[LABEL_VALUE]

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

  • [RULE_TYPE]

    Es el nombre de la regla de automatización que se usa en esta automatización. Puede ser promoteReleaseRule, timedPromoteReleaseRule, advanceRolloutRule o repairRolloutRule. Puedes incluir más de una regla en una automatización, incluido más de un RULE_TYPE del mismo tipo. Por ejemplo, puedes tener más de una regla promoteReleaseRule en la misma automatización. Más información

  • [RULE_NAME]

    Nombre de la regla. Este nombre debe ser único en la canalización de distribución. Se requiere un valor para esta propiedad.

  • [RULE-SPECIFIC_CONFIG]

    La configuración es diferente para cada tipo de automatización admitido. Esas configuraciones se muestran en la sección Usar reglas de automatización.

Implementar definiciones de políticas

En esta sección se describen los campos que se usan para definir 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 flujo de procesamiento de entrega o en un archivo independiente.

El siguiente archivo YAML 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]

Donde:

  • [DESCRIPTION]

    Es un texto opcional que describe esta política.

  • [POLICY_NAME]

    Nombre de la política. Este campo acepta una cadena que debe ser única por proyecto y ubicación. Debe estar formado por letras minúsculas, números y guiones. El primer carácter debe ser una letra, el último carácter debe ser una letra o un número, y la longitud máxima es de 63 caracteres. Este nombre se usa como nombre visible en la consolaGoogle Cloud .

  • [ANNOTATIONS] y [LABELS]

    Las políticas pueden incluir anotaciones y etiquetas, que forman parte del recurso de la política una vez que se ha creado. Para obtener más información, consulta el artículo sobre cómo usar anotaciones y etiquetas con Cloud Deploy.

  • suspended: [true | false]

    Si se asigna el valor true a suspended, esta política se desactivará.

  • [PIPELINE_ID]

    Es el ID de la canalización de entrega a la que quieres que afecte esta política. Puedes usar * para indicar todos los flujos de procesamiento. Este ID es el mismo que el de la propiedad metadata.name del flujo de procesamiento de entrega.

  • [TARGET_ID]

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

  • [LABEL_KEY]:[LABEL_VALUE]

    Es un par clave-valor que se compara con un par clave-valor definido en la canalización de entrega o en el destino. De esta forma, se seleccionan todas las canalizaciones o los objetivos que tengan la misma etiqueta y el mismo valor. Puede especificar labels en lugar de id o junto con id.

  • [RULE_TYPE]

    Es el tipo de regla de política específico que está configurando. El único valor válido es rolloutRestriction.

  • [CONFIGS]

    Es el conjunto de propiedades de configuración de la regla de política específica que estás creando. 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.

Desplegar reglas de política

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 determinadas operaciones en las implementaciones durante el periodo o los periodos especificados, en los flujos de procesamiento de entrega y los destinos indicados por selectors en la política de implementación.

En el siguiente archivo YAML se muestra cómo configurar una regla rolloutRestriction:

rules:
- rolloutRestriction:
    id: [RULE_ID]
    actions:
    - [ACTIONS]
    invokers:
    - [INVOKERS]
    timeWindows:
      timeZone: [TIMEZONE]
      oneTimeWindows:
      - start: [START_DATE_TIME]
        end: [END_DATE_TIME]
      weeklyWindows:
      - daysOfWeek:
        - [DAY_OF_WEEK]
        - [DAY_OF_WEEK]
        startTime: [START_TIME]
        endTime: [END_TIME]

Donde:

  • RULE_ID

    Identificador de esta regla. Este campo es obligatorio. Debe estar formado por letras minúsculas, números y guiones. El primer carácter debe ser una letra, el último carácter debe ser una letra o un número, y la longitud máxima es de 63 caracteres. Debe ser único en 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. Los valores válidos son estos:

    • ADVANCE

      Las fases de lanzamiento no se pueden avanzar.

    • APPROVE

      No se puede aprobar la promoción de lanzamiento.

    • CANCEL

      Los lanzamientos no se pueden cancelar.

    • CREATE

      No se pueden crear lanzamientos.

    • IGNORE_JOB

      Los trabajos no se pueden ignorar.

    • RETRY_JOB

      Los trabajos no se pueden volver a intentar.

    • ROLLBACK

      Los lanzamientos no se pueden revertir.

    • TERMINATE_JOBRUN

      Los trabajos no se pueden finalizar

  • INVOKERS

    Si especificas invocadores, se filtrará la aplicación de la política en función de si la acción restringida la ha invocado un usuario o una automatización de la implementación. Los valores válidos son:

    • USER

      La acción la inicia el usuario. Por ejemplo, crear un lanzamiento manualmente mediante un comando de la CLI de gcloud.

    • DEPLOY_AUTOMATION

      Una acción automatizada de Cloud Deploy.

    Puede especificar uno de los valores o ambos. Si no especificas nada, el valor predeterminado es "Ambos".

  • TIMEZONE

    La zona horaria, en formato IANA, en la que se expresa el periodo. Por ejemplo, America/New_York. Este campo es obligatorio.

  • START_DATE_TIME

    En el caso de oneTimeWindows, la fecha y la hora que marcan el inicio del periodo de restricción, con el formato "yyyy-mm-dd hh:mm". Para empezar el día, usa 00:00. Este campo es obligatorio.

  • END_DATE_TIME

    En el caso de oneTimeWindows, la fecha y la hora que marcan el final del periodo 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

    En weeklyWindows, el día de la semana, SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY o SATURDAY. Si lo dejas en blanco, se corresponderá con todos los días de la semana.

  • START_TIME

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

  • END_TIME

    En el caso de weeklyWindows, la hora de finalización del día de la semana especificado. Si incluyes una hora de inicio, debes incluir una hora de finalización. Para el final del día, usa 24:00.

Siguientes pasos