Usa una estrategia de implementación Canary

En este documento, se describe cómo configurar y usar una estrategia de implementación de versiones canary.

¿Qué es una implementación de versiones canary?

Una implementación canary es un lanzamiento progresivo de una aplicación que divide el tráfico entre una versión ya implementada y una nueva, y la lanza a un subconjunto de usuarios antes de lanzarla por completo.

Tipos de objetivos admitidos

La implementación de versiones canary en Cloud Deploy admite todos los tipos de destinos, incluidos los siguientes:

Canary también funciona con varios objetivos.

¿Por qué usar una estrategia de implementación de versiones canary?

Una implementación Canary te permite lanzar tu aplicación de forma parcial. De esta manera, puedes asegurarte de que la nueva versión de tu aplicación sea confiable antes de enviarla a todos los usuarios.

Por ejemplo, si realizas la implementación en GKE o GKE Enterprise, implementarías la versión nueva de tu aplicación en una cantidad limitada de pods. La versión anterior seguiría ejecutándose, pero con más tráfico que se enviaría a los pods nuevos.

Si realizas la implementación en Cloud Run, esta divida el tráfico entre las revisiones anteriores y nuevas, según los porcentajes que configures.

Tipos de versiones canary

Cloud Deploy te permite configurar los siguientes tipos de versiones canary Deployment:

  • Automático

    Con un canary automatizadas Deployment, debes configurar Cloud Deploy con una serie de porcentajes que expresan una implementación progresiva. Cloud Deploy realiza operaciones adicionales en tu nombre para distribuir los porcentajes de tráfico entre las versiones anterior y nueva.

  • Personalización personalizada

    Para una versión canary automatizada personalizada, puedes proporcionar lo siguiente:

    • El nombre de la fase
    • El objetivo de porcentaje
    • El perfil de Skaffold que se usará para la fase
    • Si se debe incluir o no un trabajo de verificación
    • Incluir o no un trabajo previo o posterior a la implementación, o ambos

    Sin embargo, no necesitas proporcionar información de balanceo de tráfico. Cloud Deploy crea los recursos necesarios.

  • Personalizado

    Con un canary personalizado, configuras cada fase de la versión canary por separado incluidos los siguientes:

    • El nombre de la fase
    • El objetivo de porcentaje
    • El perfil de Skaffold que se usará para la fase
    • Si se debe incluir o no un trabajo de verificación
    • Si se incluye o no una tarea de preimplementación o posimplementación, o ambas

    Además, en el caso de una versión canary completamente personalizada, se proporcionan del balanceo de tráfico, como se describe aquí.

Fases de una implementación de versiones canary

Cuando creas una versión para una implementación de versiones canary, este se crea una fase para cada incremento de versión canary, más una fase final de stable para el 100%.

Por ejemplo, si configuras una versión canary para incrementos de 25%, 50% y 75%, la lanzamiento tendrá las siguientes fases:

  • canary-25
  • canary-50
  • canary-75
  • stable

Puedes obtener más información sobre las fases de lanzamiento, los trabajos y las ejecuciones de trabajos en Administra lanzamientos.

Qué sucede durante una implementación de versiones canary automatizada o personalizada

Para admitir tu implementación Canary, Cloud Deploy incluye pasos de procesamiento especiales cuando se renderiza el manifiesto de Kubernetes o la configuración del servicio de Cloud Run:

GKE/Enterprise

A continuación, se muestra cómo Cloud Deploy ejecuta una implementación canary en GKE y GKE Enterprise basados en la red:

  1. Proporciona el nombre del recurso de implementación y del recurso de servicio.

  2. Cloud Deploy crea un recurso de implementación adicional, con el nombre de tu implementación actual más -canary.

  3. Cloud Deploy modifica el servicio para ajustar el selector de modo que seleccione los pods de la implementación actual y los pods canary.

    Cloud Deploy calcula la cantidad de Pods que se usarán para el una versión canary basada en el cálculo descrito aquí. Ese cálculo difiere según si habilitas o inhabilitas el sobreaprovisionamiento de pods.

    Si pasamos a la fase stable Cloud Deploy agrega las etiquetas que se usarán para hacer coincidir los Pods, por lo que están disponibles para ejecuciones de versiones canary posteriores.

    Cloud Deploy crea una implementación que incluye el porcentaje de pods específico de la fase y lo actualiza para cada fase. Para ello, se calcula la cantidad de pods como un porcentaje de la cantidad original de pods. Esto puede generar una división del tráfico inexacta. Si necesitas una división exacta del tráfico, puedes lograrlo con la API de Gateway.

    Además, los Secrets y los ConfigMaps también se copian y se les cambia el nombre con -canary.

  4. Durante la fase stable, la implementación de -canary se reduce a cero y la implementación original se reemplaza por la nueva.

    Cloud Deploy no modifica el objeto Deployment original hasta que Fase stable:

Cloud Deploy aprovisiona pods para lograr el porcentaje de Canary solicitado lo más cerca posible. Se basa en la cantidad de Pods, no en el tráfico a los Pods. Si deseas que tu canario se base en el tráfico, debes usar la API de Gateway.

En el caso de Canary basado en la red de GKE, puedes habilitar o inhabilitar el sobreaprovisionamiento de pods. En las siguientes secciones, se describe cómo Cloud Deploy calcula la cantidad de pods que se aprovisionarán para la implementación Canary para cada fase de Canary.

Aprovisionamiento de pods con el sobreaprovisionamiento habilitado

Habilitando el aprovisionamiento en exceso (disablePodOverprovisioning: false) permite que Cloud Deploy cree suficientes Pods adicionales para ejecutar el porcentaje de versiones canary que deseas, según la cantidad de Pods que ejecuten tu implementación existente. En la siguiente fórmula, se muestra cómo Cloud Deploy calcula la cantidad de pods que se aprovisionarán para la implementación Canary de cada fase Canary cuando el sobreaprovisionamiento de pods está habilitado:

math.Ceil( percentage * ReplicaCountOfDeploymentOnCluster / (100-percentage))

Con esta fórmula, el recuento de réplicas actual (la cantidad de pods que ya tienes antes de esta canaria) se multiplica por el porcentaje de canaria de la fase y el resultado se divide por (100 menos el porcentaje).

Por ejemplo, si ya tienes 4 Pods y la fase de versiones canary es del 50%, entonces el número de Pods de versión canary es de 4. (El resultado de 100-percentage se usa como un porcentaje: 100-50=50, que se trata como .50).

El aprovisionamiento en exceso de Pods es el comportamiento predeterminado.

Aprovisionamiento de Pods con aprovisionamiento en exceso inhabilitado

Puedes inhabilitar el sobreaprovisionamiento (disablePodOverprovisioning: true) para asegurarte de que Cloud Deploy no aumente el recuento de réplicas.

En la siguiente fórmula, se muestra cómo Cloud Deploy calcula el aprovisionamiento de pods para la implementación Canary de cada fase Canary, cuando el sobreaprovisionamiento de pods está inhabilitado:

math.Ceil( (ReplicaCountOfDeploymentOnCluster + ReplicaCountOfCanaryDeploymentOnCluster) * percentage)

En esta fórmula, ReplicaCountOfCanaryDeploymentOnCluster solo existe si ya había una fase de versión canary. Si esta es la primera fase canary, no hay ReplicaCountOfCanaryDeploymentOnCluster.

Si comienzas con 4 pods, esa cantidad se multiplica por el porcentaje de Canary (por ejemplo, 50% o .5) para obtener 2. Por lo tanto, la implementación original ahora se reduce a 2, y se crean 2 pods nuevos para la implementación Canary. Si Luego, tienes una etapa de versión canary del 75%, 2 (implementación original) +2 (primera etapa de la versión canary), *.75, para obtener 3 Pods de Canary y 1 Pod que ejecutan el implementación original.

Puerta de enlace de GKE/Enterprise

Aquí te mostramos cómo Cloud Deploy ejecuta una implementación de versiones canary en GKE y GKE Enterprise con la API de puerta de enlace:

  1. Además de las referencias de Deployment y Service, proporciona un Recurso HTTPRoute, con una regla backendRefs que hace referencia al Service.

  2. Cloud Deploy crea un nuevo objeto Deployment con el nombre de tu objeto Deployment original más -canary y un Service nuevo con el objeto Deployment original Nombre del servicio más -canary.

    Además, se copian Secrets, ConfigMaps y Horizontal Pod Autoscaler. y se le cambió el nombre con -canary.

  3. Para cada fase de la versión canary, Cloud Deploy modifica la HTTPRoute para actualizar la ponderación entre los Pods del objeto Deployment original y los Pods del Deployment canary, según el porcentaje para esa fase.

    Porque puede haber una demora para propagar los cambios a HTTPRoute recursos, puedes incluye la propiedad routeUpdateWaitTime en tu de la configuración, por lo que el sistema espera un período específico de los datos.

  4. Durante la fase stable, la implementación de -canary se reduce a cero y la implementación original se actualiza para usar la implementación de la nueva versión.

    Además, la HTTPRoute se revierte a la original que proporcionaste.

    Cloud Deploy no modifica la implementación ni el servicio originales hasta la fase stable.

Cloud Run

A continuación, se muestra cómo Cloud Deploy ejecuta una implementación Canary para Cloud Run:

  • Para una implementación Canary en Cloud Run, no proporciones una estrofa traffic en el archivo YAML de tu servicio.

  • Cuando se crea un lanzamiento nuevo para canary, Cloud Deploy divide el tráfico entre la revisión anterior que Cloud Deploy implementó correctamente y una revisión nueva.

Si quieres ver las diferencias entre las fases de una implementación de versiones canary, pueden ver los cambios en el manifiesto renderizado por fase disponible en el Inspector de versiones. Puedes hacerlo incluso antes de que comience el lanzamiento. Además, si usas la implementación en paralelo, también puedes inspeccionar el manifiesto renderizado de cada elemento secundario.

Configurar una implementación de versiones canary

En esta sección, se describe cómo configurar tu canalización de publicación y tus objetivos para una implementación Canary.

En estas instrucciones, solo se incluye lo específico de la configuración de versiones canary. El En el documento Implementa tu aplicación, se muestra instrucciones generales para configurar y ejecutar tu canalización de implementación.

Asegúrate de tener los permisos necesarios

Además de otros permisos de Identity and Access Management que necesitas para usar Cloud Deploy, necesitas los siguientes permisos para hacer lo siguiente: realizar las acciones adicionales que podrían ser necesarias para una implementación de versiones canary:

  • clouddeploy.rollouts.advance
  • clouddeploy.rollouts.ignoreJob
  • clouddeploy.rollouts.cancel
  • clouddeploy.rollouts.retryJob
  • clouddeploy.jobRuns.get
  • clouddeploy.jobRuns.list
  • clouddeploy.jobRuns.terminate

Consulta Roles y permisos de IAM para obtener más información sobre qué roles disponibles incluyen estos permisos.

Prepara tu skaffold.yaml

Al igual que con una implementación estándar, tu versión canary necesita un archivo skaffold.yaml, define cómo se procesan y se implementan los manifiestos y las definiciones de servicios.

El skaffold.yaml que creas para una implementación Canary no tiene ningún requisito especial más allá de lo que se necesita para la implementación estándar.

Prepara tu manifiesto o definición de servicio

Como ocurre con una implementación estándar, tu versión canary necesita un manifiesto de Kubernetes o Definición del servicio de Cloud Run.

GKE y GKE Enterprise

En el caso de la versión canary, tu manifiesto debe tener lo siguiente:

  • Una implementación y un servicio.

  • El Service debe definir un selector que, a su vez, debe elegir los Pods del objeto Deployment especificado. El valor predeterminado es app.

  • Si usas un canario basado en la API de la puerta de enlace, el manifiesto también debe tener una HTTPRoute.

Cloud Run

Para Canary en Cloud Run, tu archivo de definición de servicio normal de Cloud Run es suficiente, pero sin una estrofa traffic. Cloud Deploy administra la división entre la última revisión exitosa y la nueva.

Configura una versión canary automatizada

Las siguientes instrucciones son para Cloud Run y los objetivos de redes basados en servicios de GKE y GKE Enterprise. Si usas la API de Kubernetes Gateway con GKE o GKE Enterprise, consulta esta documentación.

Configura la versión canary automatizada en la definición de tu canalización de entrega:

GKE y GKE Enterprise

En la etapa de canalización, incluye una propiedad strategy, de la siguiente manera:

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              podSelectorLabel: "LABEL"
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

En esta configuración...

  • SERVICE_NAME es el nombre del servicio de Kubernetes, que se define en tu manifiesto.

  • DEPLOYMENT_NAME es el nombre de tu instancia de Kubernetes. de Deployment, que se define en tu manifiesto.

  • LABEL es una etiqueta del selector de Pods. Debe coincidir con la etiqueta en el Service de Kubernetes definido en tu manifiesto. Esto es opcional. El valor predeterminado es app.

  • PERCENTAGES es una lista separada por comas de valores porcentuales que representan tus incrementos Canary, por ejemplo, [5, 25, 50].

    Además, no incluye 100, ya que se supone que la implementación del 100% se realiza en Canary y la controla la fase stable.

  • Puedes habilitar la verificación de implementación (verify: true). Si lo haces, se habilitará un trabajo de verify en cada fase.

  • PREDEPLOY_ACTION

    Es la misma que la ACTION_NAME que usaste en tu skaffold.yaml para definir la acción personalizada que deseas ejecutar antes de la implementación.

  • POSTDEPLOY_ACTION

    Es la misma que la ACTION_NAME que usaste en tu skaffold.yaml para definir la acción personalizada que quieres ejecutar después de la implementación.

Cloud Run

En la etapa de canalización, incluye una propiedad strategy, de la siguiente manera:

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          cloudRun:
            automaticTrafficControl: true
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

En esta configuración...

  • PERCENTAGES es una lista de porcentajes separada por comas valores que representan tus incrementos de versiones canary, por ejemplo, [25, 50, 75]. Nota que esto no incluye 100, porque el 100% de la implementación está asume en la versión canary y es manejado por el Fase stable.

  • Puedes habilitar la verificación de implementación (verify: true). Si lo haces, se agregará un trabajo verify a cada en la fase de versiones canary.

  • PREDEPLOY_ACTION

    Es igual que el ACTION_NAME que usaste en tu skaffold.yaml para definir la acción personalizada que deseas ejecutar antes de la implementación.

  • POSTDEPLOY_ACTION

    Es la misma que la ACTION_NAME que usaste en tu skaffold.yaml para definir la acción personalizada que quieres ejecutar después de la implementación.

Configura una versión canary personalizada

Puedes configurar tu canario de forma manual en lugar de depender por completo de la automatización que proporciona Cloud Deploy. Con versiones canary personalizadas debes especificar lo siguiente en la definición de tu canalización de entrega:

  • Nombres de las fases de lanzamiento

    En un canario completamente automatizado, Cloud Deploy asigna nombres a las fases por ti (canary-25, canary-75, stable, por ejemplo). Con un Canary personalizado, sin embargo, puedes darle cualquier nombre a cada fase, siempre y cuando sea única fases de esta etapa de las versiones canary y honra restricciones de nombres de recursos. Pero la última El nombre de la fase (100%) debe ser stable.

  • Objetivos porcentuales para cada fase

    Especifica los porcentajes por separado, por fase.

  • Perfiles de Skaffold que se usarán para la fase

    Puedes usar un perfil de Skaffold independiente para cada fase, el mismo perfil o cualquier combinación. Y cada perfil puede usar un manifiesto de Kubernetes diferente o la definición del servicio de Cloud Run. También puedes usar más de un perfil para una fase determinada. Cloud Deploy los combina.

  • Si hay un trabajo de verificación para la fase

    Recuerda que, si habilitas la verificación, debes configura tu skaffold.yaml para la verificación.

  • Si hay trabajos previos o posteriores a la implementación para la fase

    Si habilitas trabajos previos o posteriores a la implementación, debes configurar tu skaffold.yaml para esos trabajos.

Todos los tipos de segmentación son compatibles con Canary personalizado.

Elementos de configuración de versiones canary personalizados

En el siguiente YAML, se muestra la configuración de las fases de la implementación canary completamente personalizada:

strategy:
  canary:
    # Custom configuration for each canary phase
    customCanaryDeployment:
      phaseConfigs:
      - phaseId: "PHASE1_NAME"
        percentage: PERCENTAGE1
        profiles: [ "PROFILE_NAME" ]
        verify: true | false
        predeploy:
          actions: "PREDEPLOY_ACTION"
        postdeploy:
          actions: "POSTDEPLOY_ACTION"
      - …
      - phaseId: "stable"
        percentage: 100
        profiles: [ "LAST_PROFILE_NAME" ]
        verify: true|false
        predeploy:
          actions: "PREDEPLOY_ACTION"
        postdeploy:
          actions: "POSTDEPLOY_ACTION"

En este archivo YAML

  • PHASE1_NAME

    Es el nombre de la fase. Cada nombre de fase debe ser único.

  • [ "PROFILE_NAME" ]

    Es el nombre del perfil que se usará para la fase. Puedes usar el mismo perfil para cada fase, una diferente para cada fase o cualquier combinación. Además, puedes especificar más de un perfil. Cloud Deploy usa todos los que especifiques, más el perfil o manifiesto utilizado por el grupo etapa.

  • stable

    La fase final debe llamarse stable.

  • PERCENTAGE1

    Es el porcentaje que se implementará para la primera fase. Cada fase debe tener un valor de porcentaje único, y ese valor debe ser un porcentaje entero (no 10.5, por ejemplo), y las fases deben estar en orden ascendente.

  • verify: true|false

    Le indica a Cloud Deploy si debe incluir un trabajo de verificación para la fase. Ten en cuenta que, para cada fase, Skaffold usa el mismo perfil para verificar que se especifique para la renderización y la implementación de esa fase.

  • PREDEPLOY_ACTION

    Es la misma que la ACTION_NAME que usaste en tu skaffold.yaml para definir la acción personalizada que deseas ejecutar antes de la implementación.

  • POSTDEPLOY_ACTION

    Es el mismo que el ACTION_NAME que usaste en tu skaffold.yaml para definir la acción personalizada que deseas ejecutar después de la implementación.

El porcentaje de la última fase debe ser 100. Las fases se ejecutan según el orden en que las configuras en esta estrofa ​customCanaryDeployment, pero si los valores de porcentaje no están en orden ascendente, el comando para registrar la canalización de publicación falla con un error.

Ten en cuenta que la configuración de una versión canary personalizada no incluye un Estrofa runtimeConfig. Si incluyes runtimeConfig, se considera un las versiones canary automatizadas y personalizadas.

Configura una versión canary automatizada personalizada

Una versión canary personalizada y automatizada es similar a una canary personalizada porque especificas las fases de la versión canary separadas, con nombres de las fases personalizadas valores porcentuales, perfiles de Skaffold, tareas de verificación y la implementación previa y posterior de seguridad en la nube. Sin embargo, con un canario personalizado, no proporcionas las configuraciones que definen la distribución del tráfico. Cloud Deploy lo hace por ti, pero debes proporcionar los perfiles de Skaffold que se usarán para cada etapa.

Para configurar una versión canary automatizada personalizada, incluye una estrofa runtimeConfig, como como se muestra aquí e incluir la estrofa customCanaryDeployment, como se muestra aquí.

Configura una implementación Canary con la malla de servicios de la API de Kubernetes Gateway

Si bien puedes usar una implementación Canary de Cloud Deploy para implementar tu aplicación en las herramientas de redes basadas en servicios de Kubernetes, una alternativa es usar la malla de servicios de la API de la puerta de enlace de Kubernetes. En esta sección, se describe cómo hacerlo.

Puedes usar la API de Gateway con Istio o cualquier implementación compatible.

  1. Configura tus recursos de la API de puerta de enlace:

    Estos son solo ejemplos.

  2. En tu manifiesto de Kubernetes, que se proporciona a Cloud Deploy cuando creó la versión, se incluyen los siguientes:

    • Un objeto HTTPRoute que haga referencia a tu recurso Gateway

    • Un objeto Deployment

    • Un servicio

  3. Configura tu canalización de entrega y el destino en el que implementarás las versiones canary a:

    • La configuración del objetivo es la misma que la de cualquier otro objetivo.

    • La configuración de la canalización de entrega, en la secuencia de progreso de la objetivo específico; incluye una estrofa gatewayServiceMesh para hacer referencia a tu Configuración de HTTPRoute de la API de Kubernetes Gateway junto con tu Deployment y servicio.

      strategy:
 canary:
   runtimeConfig:
     kubernetes:
       gatewayServiceMesh:
         httpRoute: "ROUTE"
         service: "SERVICE"
         deployment: "DEPLOYMENT"
         routeUpdateWaitTime: "WAIT_TIME"
         podSelectorLabel: "LABEL"
   canaryDeployment:
     percentages:
     - 50

      En el ejemplo anterior, se ilustra lo siguiente:

      • ROUTE es tu configuración de httpRoute que define el comportamiento de enrutamiento que deseas.

      • SERVICE es la configuración de tu servicio, que Cloud Deploy requiere para las implementaciones Canary en GKE y GKE Enterprise.

      • DEPLOYMENT es la configuración de implementación que Cloud Deploy requiere para las implementaciones Canary en GKE y GKE Enterprise.

      • WAIT_TIME es la cantidad de tiempo que Cloud Deploy tarda en esperar a que los cambios en el recurso HTTPRoute terminen de propagarse, para y evitar la pérdida de solicitudes. Por ejemplo: routeUpdateWaitTime: 60s.

        Si ejecutas Canary con la API de Gateway sin Istio, y la API de Gateway está conectada a un balanceador de cargas de Google Cloud, es posible que se pierda una pequeña cantidad de tráfico cuando se reduzca la escala de la instancia de Canary. Puedes puedes ajustar esta configuración si observas este comportamiento.

      • LABEL es una etiqueta del selector de Pods. Debe coincidir con el selector de etiquetas en el servicio y la implementación de Kubernetes definidos en tu manifiesto. Esto es opcional. El valor predeterminado es app.

Usa la implementación en paralelo con una estrategia de implementación Canary

Puedes ejecutar una implementación de versiones canary con una implementación paralela. Esto significa que el objetivo al que implementas de forma progresiva puede incluir dos o más objetivos secundarios. Por ejemplo, puedes implementar progresivamente en clústeres en clústeres regiones, al mismo tiempo.

¿En qué se diferencian las versiones canary paralelas de las de destino único?

  • Al igual que con la implementación Canary de un solo objetivo, si realizas implementaciones en objetivos de GKE, necesitas una configuración de implementación de Kubernetes y una configuración de servicio de Kubernetes en tu manifiesto.

  • Al igual que con la implementación de canary de un solo objetivo, la configuración de la canalización de entrega debe incluir una estrofa strategy.canary dentro de la definición de la etapa aplicable.

  • Además, debes configurar un destino múltiple y tienes que configura los destinos secundarios a la que hace referencia con varios destinos.

  • Cuando creas una versión, se realiza un lanzamiento del control y se crean los lanzamientos secundarios.

    Ambos tipos de lanzamientos (controlador y secundario) tienen fases separadas para todos los porcentajes de Canary configurados y una fase stable para el 100% de Canary.

  • No puedes avanzar un lanzamiento secundario.

    Solo puedes avanzar los lanzamientos de controladores. Cuando avanzas el lanzamiento del controlador a la siguiente etapa, Cloud Deploy también avanza los lanzamientos secundarios.

  • No puedes reintentar trabajos fallidos en la implementación del controlador.

    Solo puedes reintentar una tarea en los lanzamientos secundarios.

  • No puedes ignorar trabajos con errores en el lanzamiento del controlador.

    Solo puedes ignorar los trabajos con errores en los lanzamientos secundarios.

  • Puedes cancelar un lanzamiento de controlador, pero no puedes cancelar los lanzamientos secundarios.

  • Puedes finalizar ejecuciones de trabajos solo en un lanzamiento secundario, no en un lanzamiento de controlador.

Qué hacer si un lanzamiento paralelo falla en la versión canary

Cuando falla un lanzamiento secundario, el lanzamiento del controlador puede pasar a diferentes estados, según lo que suceda con los lanzamientos secundarios:

  • Si uno o más lanzamientos secundarios fallan, pero al menos un lanzamiento secundario sigue IN_PROGRESS, el lanzamiento del controlador sigue siendo IN_PROGRESS.

  • Si uno o más lanzamientos secundarios fallan, pero al menos uno se realiza correctamente, el lanzamiento del controlador es HALTED si hay más fases después de la actual.

    Si esta es la fase stable, el lanzamiento del controlador será FAILED.

    HALTED te permite ignorar, volver a intentar los trabajos fallidos dentro del lanzamiento secundario con errores o cancelar el lanzamiento del controlador y evitar más acciones en los lanzamientos secundarios.

  • Si el lanzamiento del control está en estado HALTED debido a un elemento secundario con errores lanzamiento e ignoras el trabajo con errores en el lanzamiento secundario, el lanzamiento vuelve a un estado IN_PROGRESS.

Ejecuta la versión canary configurada

Para ejecutar la implementación de versiones canary, haz lo siguiente:

  1. Registra la canalización de entrega y los destinos configurados.

    gcloud deploy apply --file=PIPELINE

    La canalización de publicación incluye la configuración de Canary automatizada o personalizada para el entorno de ejecución que elijas.

    Este comando supone que tus objetivos se definen en el mismo archivo o que ya se registraron. Si no es así, asegúrate de registrar tus destinos también.

  2. Crea una versión:

    gcloud deploy releases create RELEASE_NAME \
                              --delivery-pipeline=PIPELINE_NAME \
                              --region=REGION

    La canalización de entrega identificada por PIPELINE_NAME contiene la configuración de versiones canary automatizada o personalizada que se describe en este .

  3. Avanza la versión canary:

    gcloud CLI 

    gcloud deploy rollouts advance ROLLOUT_NAME \
                            --release=RELEASE_NAME \
                            --delivery-pipeline=PIPELINE_NAME \
                            --region=REGION

    Aquí:

    ROLLOUT_NAME es el nombre del lanzamiento actual al que avanzas a la siguiente fase.

    RELEASE_NAME es el nombre de la versión que este lanzamiento es parte.

    PIPELINE_NAME es el nombre de la publicación que usas para administrar la implementación de esta versión.

    REGION es el nombre de la región en la que versión, por ejemplo, us-central1. Este campo es obligatorio.

    Consulta la referencia del SDK de Google Cloud para obtener más información sobre el comando gcloud deploy rollouts advance.

    Consola de Google Cloud

    1. Abre la página Canalizaciones de entrega.

    2. Haz clic en la canalización que aparece en la lista de canalizaciones de entrega.

      La página Detalles de la canalización de entrega muestra una representación gráfica del progreso de tu canalización de entrega.

    3. En la pestaña Lanzamientos, en Detalles de la canalización de entrega, haz clic en el nombre del lanzamiento.

      Se muestra la página de detalles del lanzamiento para ese lanzamiento.

      detalles del lanzamiento en la consola de Google Cloud

      Observa que, en este ejemplo, el lanzamiento tiene una fase canary-50 y una fase stable. Tu lanzamiento puede tener más fases o diferentes fases.

    4. Haz clic en Adelantar lanzamiento.

      El lanzamiento avanza a la siguiente fase.

Fases omitidas

Si implementas una versión canary y tu aplicación no se implementó en ese entorno de ejecución, Cloud Deploy omite la fase de versión canary y ejecuta la versión en la fase de desarrollo. Consulta Cómo omitir fases la primera vez para descubrir por qué sucede esto.

¿Qué sigue?