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 de versiones 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 segmentación 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 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. De esta manera, puedes asegurarte de que la nueva versión de tu aplicación sea confiable antes de distribuirla a todos los usuarios.

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

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

Tipos de versiones canary

Cloud Deploy te permite configurar los siguientes tipos de implementación canaria:

  • Automático

    Con una implementación de versiones canary automatizada (para red de servicios, API de puerta de enlace o Cloud Run), configuras Cloud Deploy con una serie de porcentajes que expresan una implementación progresiva. Cloud Deploy realiza operaciones adicionales en tu nombre para asignar porcentajes de tráfico entre las versiones anterior y nueva.

  • Personalizada y automatizada

    Para una versión canary personalizada y automatizada (para redes de servicios, API de puerta de enlace o Cloud Run), puedes proporcionar lo siguiente:

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

    Sin embargo, no es necesario que proporciones información sobre el balanceo de tráfico, ya que Cloud Deploy crea los recursos necesarios (para las herramientas de redes de servicio, la API de puerta de enlace o Cloud Run).

  • Personalizado

    Con una versión canary personalizada (para herramientas de redes de servicio, API de puerta de enlace o Cloud Run), configuras cada fase de la versión canary por separado, lo que incluye lo siguiente:

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

    Además, para una versión canary completamente personalizada, debes proporcionar toda la configuración de equilibrio del tráfico.

Fases de una implementación de versiones canary

Cuando creas una versión para una implementación de versiones canary, el lanzamiento se crea con una fase para cada incremento de la prueba y una fase final stable para el 100%.

Por ejemplo, si configuras una versión canary para incrementos del 25%, el 50% y el 75%, el 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.

Usa la implementación paralela con una estrategia de implementación de versiones canary

Puedes ejecutar una implementación de versiones canary con la implementación paralela. Esto significa que el destino al que realizas la implementación progresiva puede incluir dos o más destinos secundarios. Por ejemplo, puedes realizar implementaciones progresivas en clústeres de regiones separadas al mismo tiempo.

¿En qué se diferencia una versión canary paralela de las versiones canary de un solo destino?

  • Al igual que con la implementación de versiones canary de un solo destino, si implementas en destinos de GKE, necesitas una configuración de Deployment de Kubernetes y una configuración de Service de Kubernetes en tu manifiesto.

  • Al igual que con la implementación de versiones canary en un solo destino, la configuración de tu canalización de entrega debe incluir una sección 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 de controlador y los lanzamientos secundarios.

    Ambos tipos de lanzamiento (controlador y secundario) tienen fases separadas para todos los porcentajes de versiones canary configurados y una fase stable para el 100% de la versión canary.

  • No puedes avanzar un lanzamiento secundario.

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

  • No puedes reintentar los trabajos con errores en la implementación del controlador.

    Solo puedes reintentar un trabajo en lanzamientos secundarios.

  • No puedes ignorar los trabajos con errores en la implementación del controlador.

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

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

  • Solo puedes finalizar ejecuciones de trabajos en un lanzamiento secundario, no en un lanzamiento del controlador.

Qué hacer si falla un lanzamiento paralelo en 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 falla uno o más lanzamientos secundarios, pero al menos uno sigue siendo IN_PROGRESS, el lanzamiento del controlador sigue siendo IN_PROGRESS.

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

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

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

  • Si el lanzamiento del controlador está en estado HALTED debido a un lanzamiento secundario fallido y, luego, ignoras el trabajo fallido en el lanzamiento secundario, el lanzamiento del controlador volverá al estado IN_PROGRESS.

¿Qué sigue?