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 de versiones canary es un lanzamiento progresivo de una aplicación que divide de tráfico entre una versión implementada y una versión nueva, a un subconjunto de usuarios antes del lanzamiento completo.
Tipos de objetivos admitidos
La implementación de versiones canary en Cloud Deploy admite todos los tipos de destinos, incluidos los siguientes:
- Google Kubernetes Engine
- Cloud Run (solo servicios, no jobs.)
- GKE Enterprise
Canary también funciona con múltiples destinos.
¿Por qué usar una estrategia de implementación de versiones canary?
Una implementación de versiones canary te brinda la oportunidad de lanzar tu aplicación de forma parcial. En Así, podrás asegurarte de que la nueva versión de tu aplicación sea confiable se la entregues a todos los usuarios.
Si realizas la implementación en GKE o GKE Enterprise, ejemplo, implementarías la versión nueva de tu aplicación en un cantidad 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 implementas en Cloud Run, divide el tráfico entre la revisión anterior y la nueva, según porcentajes que configuras.
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
En el caso de las versiones canary custom-automated, puedes proporcionar la lo siguiente:
- El nombre de la fase
- El objetivo porcentual
- El perfil de Skaffold que se usará para la fase
- Indica 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
Sin embargo, no es necesario proporcionar información de balanceo de tráfico. Implementación en la nube crea la 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 porcentual
- El perfil de Skaffold que se usará para la fase
- Indica 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
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 leer más sobre fases de lanzamiento, trabajos y ejecuciones de trabajos en Administra los lanzamientos.
Qué sucede durante una implementación de versiones canary automatizada o personalizada
Para admitir la implementación de versiones canary, Cloud Deploy incluye de procesamiento cuando renderizas tu manifiesto de Kubernetes Configuración del servicio de Cloud Run:
GKE/Enterprise
Aquí te mostramos cómo Cloud Deploy ejecuta una implementación de versiones canary en GKE basado en la red y GKE Enterprise:
Proporcionas el nombre del recurso de Deployment y del recurso Service.
Cloud Deploy crea un recurso Deployment adicional con el nombre de tu Deployment actual más
-canary
Cloud Deploy modifica el servicio para ajustar el selector a seleccionar los Pods en el objeto Deployment actual y los Pods de la versión 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 un objeto Deployment que incluye porcentaje de Pods específico de la fase y los actualiza para cada fase. Este es calculando la cantidad de Pods como un porcentaje de la cantidad 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
.Durante la fase
stable
, el Deployment-canary
se reduce verticalmente a cero, y el objeto Deployment original se reemplaza por el nuevo.Cloud Deploy no modifica el objeto Deployment original hasta que Fase
stable
:
Cloud Deploy aprovisiona Pods para lograr la versión canary solicitada con la mayor precisión posible. Se basa en la cantidad de Pods, no en el tráfico a los Pods. Si quieres que tu versión canary se base en el tráfico, debes usar la API de Gateway.
Para la versión canary basada en la red de GKE, puedes Habilita o inhabilita el sobreaprovisionamiento de Pods. En las siguientes secciones, se describe cómo Cloud Deploy calcula la la cantidad de Pods que se aprovisionarán para la implementación de versiones canary en cada fase.
Aprovisionamiento de Pods con el aprovisionamiento en exceso 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. La siguiente fórmula muestra cómo
Cloud Deploy calcula la cantidad de Pods que se aprovisionarán para el
implementación de versiones canary para cada fase, cuando el aprovisionamiento
habilitado:
math.Ceil( percentage * ReplicaCountOfDeploymentOnCluster / (100-percentage))
Con esta fórmula, el recuento actual de réplicas (la cantidad de Pods que tener, antes de esta versión canary) se multiplica por el porcentaje de versiones canary para el 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 sobreaprovisionamiento de pods es el comportamiento predeterminado.
Aprovisionamiento de Pods con aprovisionamiento en exceso inhabilitado
Puedes inhabilitar el aprovisionamiento en exceso (disablePodOverprovisioning: true
).
para garantizar que Cloud Deploy no aumente el recuento de réplicas.
La siguiente fórmula muestra cómo Cloud Deploy calcula los Pods para la implementación de versiones canary en cada fase, cuando los Pods el aprovisionamiento en exceso 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 versiones 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:
Además de las referencias de Deployment y Service, proporciona un Recurso HTTPRoute, con una regla
backendRefs
que hace referencia al Service.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
.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 propiedadrouteUpdateWaitTime
en tu de la configuración predeterminada, por lo que el sistema espera un período específico de los datos.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 el objeto Deployment original ni Servicio hasta la fase
stable
.
Cloud Run
Aquí te mostramos cómo Cloud Deploy ejecuta una implementación de versiones 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 hacer esto incluso antes de que comenzó el lanzamiento. Además, si utilizas implementación paralela, también puedes inspeccionar manifiesto renderizado.
Configurar una implementación de versiones canary
En esta sección, se describe cómo configurar tu canalización de entrega y destinos para una implementación de versiones 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 incluye 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 los roles y los permisos de IAM para obtener más información sobre los roles disponibles que incluyen estos permisos.
Prepara tu skaffold.yaml
Al igual que con una implementación estándar, tu canario necesita un archivo skaffold.yaml
, que define cómo se renderizan y se implementan los manifiestos y las definiciones de servicio.
El skaffold.yaml
que creas para una implementación de versiones canary no tiene ningún valor
más allá de los necesarios para las
de Google Workspace.
Prepara el manifiesto o la definición del servicio
Al igual que con una implementación estándar, tu canario necesita un manifiesto de Kubernetes o una definición de servicio de Cloud Run.
GKE y GKE Enterprise
En el caso de la versión canary, tu manifiesto debe tener lo siguiente:
Un objeto Deployment y un Service.
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 una versión canary basada en la API de puerta de enlace, el manifiesto también debe tener 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 objeto Service de Kubernetes. definido en tu manifiesto.
DEPLOYMENT_NAME es el nombre de tu implementación de Kubernetes, definido 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 de porcentajes separada por comas valores que representan tus incrementos de versiones 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 fasestable
.Puedes habilitar la verificación de implementación (
verify: true
). Si lo haces, se habilitará un trabajo deverify
en cada fase.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
Sea el mismo que el 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 incluye100
, porque el 100% de la implementación está asume en la versión canary y es manejado por el Fasestable
.Puedes habilitar la verificación de implementación (
verify: true
). Si lo haces, se agregará un trabajoverify
a cada fase canaria.PREDEPLOY_ACTION
Sea el mismo 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 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.
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 serstable
.Objetivos porcentuales para cada fase
Especifica los porcentajes por separado, por fase.
Perfiles de Skaffold para usar en la fase
Puedes usar un perfil de Skaffold distinto para cada fase o el mismo perfil o cualquier combinación. Además, cada perfil puede usar un manifiesto de Kubernetes diferente o una definición de 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 a la implementación o posteriores a la implementación para la fase
Si quieres habilitar trabajos previos o posteriores a la implementación, debes configura tu
skaffold.yaml
para esos trabajos.
Todos los tipos de destinos son compatibles con las versiones canary personalizadas.
Elementos de configuración de versiones canary personalizados
En el siguiente YAML, se muestra la configuración de las fases de la versión canary completamente personalizada Deployment:
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 perfiles que especifiques, además del perfil o manifiesto que usa la etapa general.
stable
La fase final debe llamarse
stable
.PERCENTAGE1
Es el porcentaje que se debe implementar en la primera fase. Cada fase debe tener un valor porcentual y este debe ser un porcentaje entero (no
10.5
, para 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
Sea el mismo 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 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
en el orden en que los configuras en esta estrofa customCanaryDeployment
, pero si
los valores de porcentaje no están en orden ascendente, el comando para
registra la canalización de entrega
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
Un canario personalizado automatizado es similar a un canario personalizado porque especificas las fases de canario separadas, con nombres de fase personalizados, valores de porcentaje, perfiles de Skaffold, trabajos de verificación y trabajos de preimplementación y postimplementación. Pero con un Canary personalizado, no proporcionas el configuraciones que definen la distribución del tráfico: Cloud Deploy lo hace pero aun así proporcionas la Perfiles de Skaffold que se usarán en 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í.
Configurar una implementación de versiones canary con la malla de servicios de la API de Kubernetes Gateway
Aunque puedes usar una implementación de versiones canary de Cloud Deploy para implementar tu aplicación en redes basadas en servicios de Kubernetes, Una alternativa es usar la malla de servicios de la API de Gateway de Kubernetes. En esta sección, se describe cómo hacerlo.
Puedes usar la API de Gateway con Istio o cualquier otra implementación admitida.
Configura tus recursos de la API de puerta de enlace:
Estos son solo ejemplos.
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 GatewayUn objeto Deployment
Un servicio
Configura tu canalización de entrega y el destino en el que implementarás las versiones canary a:
La configuración del destino es la misma que la de cualquier destino.
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 deHTTPRoute
de la API de Kubernetes Gateway y 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 la configuración de httpRoute que define el enrutamiento el comportamiento de los usuarios que deseas.
SERVICE es tu configuración del Service, que Cloud Deploy requiere que las implementaciones de versiones canary realicen lo siguiente: GKE y GKE Enterprise.
DEPLOYMENT es la configuración del objeto Deployment, que Cloud Deploy requiere que las implementaciones de versiones canary realicen lo siguiente: GKE y GKE Enterprise.
WAIT_TIME es la cantidad de tiempo que Cloud Deploy debe esperar a que se propaguen los cambios en el recurso
HTTPRoute
para evitar que se descarten las solicitudes. Por ejemplo:routeUpdateWaitTime: 60s
.Si ejecutas una versión canary con la API de puerta de enlace sin Istio, y la API de puerta de enlace a un balanceador de cargas de Google Cloud, una pequeña cantidad de el tráfico podría perderse cuando se reduzca la escala de la instancia canary. Puedes puedes ajustar esta configuración si observas este comportamiento.
LABEL es una etiqueta del selector de Pods. Debe coincidir con la etiqueta en la Deployment y el servicio de Kubernetes definidos en tu manifiesto. Esto es opcional. El valor predeterminado es
app
.
Usa la implementación paralela con una estrategia de implementación de versiones canary
Puedes ejecutar una implementación canary con la implementación en paralelo. Esto significa que el objetivo para el que implementas de forma progresiva puede incluir dos a destinos secundarios. Por ejemplo, puedes implementar progresivamente en clústeres en clústeres regiones, al mismo tiempo.
¿En qué se diferencia una versión canary paralela de una canary de un solo objetivo?
Al igual que con la implementación de versiones canaryy de un solo destino, destinos de GKE, necesitas una configuración de Deployment una configuración del Service 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 configurar los destinos secundarios a los que hace referencia ese destino múltiple.
Cuando creas una versión, se crean un lanzamiento del controlador y los lanzamientos secundarios.
Ambos tipos de lanzamiento (de controlador y secundario) tienen fases separadas para todos los porcentajes de versiones canary configurados y una fase
stable
para el canary al 100%.No puedes avanzar un lanzamiento secundario.
Solo puedes adelantar los lanzamientos de controles. Cuando avances en el control el lanzamiento a la siguiente etapa, los lanzamientos secundarios también están Cloud Deploy.
No puedes reintentar trabajos con errores en el lanzamiento del controlador.
Solo puedes reintentar un trabajo en lanzamientos secundarios.
No puedes ignorar trabajos con errores en el lanzamiento del controlador.
Solo puedes ignorar trabajos con errores en 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 cambiar estados, según lo que ocurra 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 siendoIN_PROGRESS
.Si uno o más lanzamientos secundarios fallan, pero al menos uno tiene éxito, el lanzamiento del controlador será
HALTED
si hay más fases después de la uno.Si esta es la fase
stable
, el lanzamiento del controlador seráFAILED
.HALTED
te da la oportunidad de ignorar, reintentar trabajos con errores en el lanzamiento secundario con errores cancelar el lanzamiento del controlador y prevenir acciones adicionales sobre los lanzamientos secundarios.Si el lanzamiento del controlador está en un estado
HALTED
debido a un lanzamiento secundario que falló y ignoras el trabajo con errores en el lanzamiento secundario, el lanzamiento del controlador vuelve a un estadoIN_PROGRESS
.
Ejecuta la versión canary configurada
Para ejecutar la implementación de versiones canary, sigue estos pasos:
Registra la canalización de entrega y los destinos configurados.
gcloud deploy apply --file=PIPELINE
La canalización de entrega incluye la configuración automatizada o personalizada de versiones canary, 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. De lo contrario, asegúrate de registrar tus objetivos también.
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 .Avance de las versiones 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 el cual pasarás 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
Haz clic en la canalización que se muestra en la lista de canalizaciones de entrega.
En la página Detalles de la canalización de entrega, se muestra una representación gráfica de el progreso de tu canalización de entrega.
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.
Observa que, en este ejemplo, el lanzamiento tiene una fase
canary-50
y una Fasestable
: Es posible que el lanzamiento tenga más fases o fases diferentes.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 y la fase de desarrollo. Consulta Cómo omitir fases la primera vez para descubrir por qué sucede esto.
¿Qué sigue?
Prueba la guía de inicio rápido para la implementación de versiones canary.
Descubre cómo administrar el ciclo de vida de los lanzamientos de la versión canary.
Obtén más información sobre la implementación en paralelo.