Automatización del análisis de versiones canary en Google Kubernetes Engine con Spinnaker

En este instructivo, encontrarás los pasos para configurar la característica de análisis automatizado de versiones canary de Spinnaker en Google Kubernetes Engine (GKE).

Introducción

Spinnaker es un sistema de entrega continua de código abierto dirigido por Netflix y Google con el objetivo de administrar la implementación de aplicaciones en diferentes plataformas informáticas, entre las que se incluyen App Engine, GKE, Compute Engine, AWS y Azure. Mediante Spinnaker, puedes emplear métodos de implementación avanzados, que incluyen la implementación de versiones canary.

En una implementación de versiones canary, expones una nueva versión de tu app a una pequeña parte del tráfico de producción y analizas su comportamiento antes de realizar la implementación completa. Esto te permite reducir riesgos antes de implementar una versión nueva en todos los usuarios. Para usar implementaciones de versiones canary, debes comparar con precisión el comportamiento de las versiones anteriores respecto de las versiones nuevas de la app. Las diferencias pueden ser sutiles y tardar un tiempo en aparecer. Es posible que también tengas muchas métricas diferentes para examinar. Obtén más información sobre el patrón de versión canary en Implementación de aplicaciones y estrategias de prueba.

Para resolver esos problemas, Spinnaker tiene una característica de análisis automatizado de versiones canary. Esta característica lee las métricas de ambas versiones del sistema de supervisión y ejecuta un análisis estadístico para automatizar la comparación. En este instructivo se muestra cómo realizar un análisis automatizado de versiones canary en una app implementada en GKE y supervisada por Cloud Monitoring.

Spinnaker es una plataforma avanzada de implementación y administración de apps para organizaciones con situaciones de implementación complejas, que por lo general incluyen una función dedicada de ingeniería de versiones. Puedes realizar este instructivo aun si no tienes experiencia previa con Spinnaker. Sin embargo, la implementación del análisis automatizado de versiones canary en producción suele estar a cargo de equipos con experiencia previa en Spinnaker, que cuentan con un sistema de supervisión sólido y con conocimientos para determinar si una versión es segura.

Acerca de este instructivo

La app de este instructivo es una simple versión de “Hello World” cuya tasa de error se configura con una variable de entorno. Para esta app se proporciona una imagen de Docker precompilada. Como se ilustra en la siguiente imagen, la app expone métricas en el formato Prometheus, un sistema de supervisión de código abierto popular en la comunidad de Kubernetes y compatible con Cloud Monitoring.

Arquitectura de la app

Objetivos

  • Instalar Spinnaker para Google Cloud.
  • Implementar una app en GKE sin una implementación de versiones canary.
  • Configurar y ejecutar una implementación de versiones canary de la aplicación.
  • Configurar el análisis automatizado de versiones canary.
  • Evaluar el análisis automatizado de versiones canary.

Costos

Antes de comenzar

  1. Selecciona o crea un proyecto de Google Cloud.

    Ir a la página Administrar recursos

  2. Habilita la facturación en tu proyecto.

    Habilitar la facturación

  3. Crea un lugar de trabajo.

    Ir a la documentación de Monitoring

Cuando completes el instructivo puedes borrar los recursos que hayas creado para evitar que se te sigan facturando. Para obtener más detalles consulta la sección Limpieza.

Implementa Spinnaker para Google Cloud mediante Cloud Shell

En esta sección, vas a configurar la infraestructura necesaria para completar el instructivo. Ejecuta todos los comandos de terminal de este instructivo desde Cloud Shell.

Spinnaker para Google Cloud te ofrece una manera de configurar y administrar Spinnaker en un entorno listo para la producción, optimizado para Google Cloud. Spinnaker para Google Cloud configura muchos recursos (GKE, Memorystore, depósitos de Cloud Storage y cuentas de servicio) necesarios para ejecutar Spinnaker en Google Cloud, integra Spinnaker en servicios relacionados, como Cloud Build, y proporciona un entorno de administración basado en Cloud Shell para las instalaciones de Spinnaker, con asistentes y herramientas comunes como spin y hal.

  1. En Cloud Shell, abre Spinnaker para Google Cloud. De este modo, se clona el Spinnaker para el repositorio de Google Cloud en el entorno de Cloud Shell y, luego, se inician las instrucciones de instalación detalladas.

    Ir a Cloud Shell

  2. Instala Spinnaker para Google Cloud:

    PROJECT_ID=${DEVSHELL_PROJECT_ID} ~/cloudshell_open/spinnaker-for-gcp/scripts/install/setup_properties.sh
    ~/cloudshell_open/spinnaker-for-gcp/scripts/install/setup.sh
    
  3. Instala el complemento de integración Monitoring-Prometheus:

    export KUBE_NAMESPACE=prometheus
    export GCP_PROJECT=$DEVSHELL_PROJECT_ID
    export DATA_DIR=/prometheus/
    export DATA_VOLUME=prometheus-storage-volume
    export SIDECAR_IMAGE_TAG=0.7.0
    export GCP_REGION=us-east1-c
    export KUBE_CLUSTER=spinnaker-1
    
    kubectl create namespace ${KUBE_NAMESPACE}
    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-stackdriver-gke/master/prometheus-service-account.yaml
    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-stackdriver-gke/master/prometheus-configmap.yaml
    curl -sS https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-stackdriver-gke/master/gke-prometheus-deployment.yaml | \
      envsubst | \
      kubectl apply -f -
    
  4. Reinicia Cloud Shell para cargar la configuración del entorno nuevo.

    Opción de reinicio del menú de Cloud Shell.

  5. Conéctate a Spinnaker:

    ~/cloudshell_open/spinnaker-for-gcp/scripts/manage/connect_unsecured.sh
    
  6. En Cloud Shell, selecciona el ícono de Vista previa en la Web y, luego, selecciona Preview on port 8080.

    Opción de reinicio de Cloud Shell en el menú

Implementa una app con Spinnaker

En esta sección aprenderás a configurar Spinnaker para implementar una aplicación en el clúster de GKE.

Crea una app de Spinnaker

Antes de la implementación, debes crear la app de Spinnaker.

  1. En Spinnaker, selecciona Actions y, luego, Create Application.

    Menú desplegable Create Application

  2. En el diálogo New Application, ingresa los siguientes valores:

    • Name: sampleapp
    • Owner Email: [example@example.com]

  3. Selecciona Create.

Ahora te encuentras en la sampleapp de Spinnaker. Todavía no está configurada, de modo que la mayoría de las pestañas están vacías.

Crea y ejecuta una canalización de implementación

En esta sección, primero implementarás la app con una canalización simple de Spinnaker que tome un parámetro successRate para crear un Deployment de GKE con cuatro pods. Los pods generan errores al azar a una tasa correspondiente al parámetro successRate. En este instructivo, generan 500 errores a una tasa de 100 - successRate.

  1. En Cloud Shell, crea la canalización con el archivo JSON proporcionado. El siguiente comando publica la definición de JSON de la canalización directamente en la API de Spinnaker.

    cd ~
    wget https://raw.githubusercontent.com/spinnaker/spinnaker/master/solutions/kayenta/pipelines/simple-deploy.json
    sed "s/my-kubernetes-account/spinnaker-install-account/g" simple-deploy.json > updated-simple-deploy.json
    spin pipeline save --file updated-simple-deploy.json
    
  2. En la sección Pipelines de Spinnaker, aparece una canalización llamada Simple deploy. Si no la ves, vuelve a cargar la página. Selecciona Start Manual Execution.

    Comienza la ejecución manual de la canalización de implementación simple

  3. En la ventana Confirm execution, selecciona una Success Rate de 70 y, luego, selecciona Run. Luego de unos segundos, la canalización implementa con éxito la configuración de la app y los cuatro pods.

  4. En Cloud Shell, crea un pod que realice solicitudes a la nueva aplicación hasta que termine el instructivo.

    kubectl -n default run injector --generator=run-pod/v1 --image=alpine:3.10 -- \
        /bin/sh -c "apk add --no-cache curl; \
        while true; do curl -sS --max-time 3 \
        http://sampleapp:8080/; done"
    

Verifica los registros del inyector

  1. Para ver el comportamiento de la app, verifica los registros del inyector.

    kubectl -n default logs -f \
        $(kubectl -n default get pods -l run=injector \
        -o=jsonpath='{.items[0].metadata.name}')
    
  2. Una gran cantidad de mensajes de error interno del servidor aparecen en el registro. Para dejar de seguir los registros del inyector, presiona Ctrl+C.

Cómo verificar el estado de la aplicación

Ahora que la aplicación está implementada y procesa tráfico, comprueba que se esté comportando correctamente. Claro que ya sabes que, en este instructivo, no funciona de forma correcta, ya que la implementaste con solo el 70% de tasa de éxito.

La app expone un extremo /metrics con métricas en el formato Prometheus que son transferidas por Monitoring. En esta sección visualizarás esas métricas en Monitoring.

  1. En Google Cloud Console, ve a Monitoring.

    Ir a Monitoring

  2. Si el Explorador de métricas aparece en el panel de navegación, selecciona Explorador de métricas. De lo contrario, selecciona Recursos y, luego, Explorador de métricas.

  3. Asegúrate de que esté seleccionada la pestaña Métrica.

  4. Selecciona la casilla con la etiqueta Find resource type and metric y, luego, ingresa external.googleapis.com/prometheus/requests.

  5. Para definir mejor el gráfico, en el campo Group by, ingresa http_code.

    En el siguiente gráfico, las tasas de solicitudes HTTP que respondió la app se agrupan según el código de estado HTTP:

    Gráfico de solicitudes HTTP que respondió la app.

    Si no tienes datos en Monitoring o no puedes encontrar la métrica external.googleapis.com/prometheus/requests, espera unos minutos para que Monitoring transfiera los datos antes de volver a cargar el Explorador de métricas.

    Como puedes ver en el gráfico, en este momento la app tiene una tasa de error inaceptable: alrededor del 30%, según lo esperado. En el resto del instructivo, te guiaremos en la configuración de una canalización de una implementación de versiones canary y un análisis automático para evitar futuras implementaciones de una app con una tasa de error tan alta.

Creación de una implementación de versiones canary

En esta sección crearás una canalización de implementación de versiones canary, sin análisis automatizado, para probar la versión nueva de la aplicación antes de implementarla por completo en producción. Para simplificar, la canalización que creas en esta sección se basa en el balanceo de cargas de Kubernetes a fin de enviar tráfico a la versión canary. Como consecuencia, no puedes elegir qué parte del tráfico se enruta a la versión canary. Para implementar políticas de enrutamiento de tráfico avanzadas, puedes usar Istio.

En la siguiente imagen se muestran las diferentes etapas de la canalización:

Ilustración de las etapas de una canalización de implementación de versiones canary

  • Paso 0: Al igual que en la canalización Simple Deploy (Implementación simple), la canalización toma un parámetro de Tasa de éxito como entrada. Esta canalización nueva, utiliza este parámetro para simular diferentes tasas de éxito. Esta es la Configuration de la canalización.

  • Paso 1: La etapa Find Baseline Version (Buscar versión de línea base) recupera la versión actual de la aplicación que se está ejecutando en producción de la última ejecución de la canalización Simple Deploy (Implementación simple). En este instructivo, recupera la tasa de éxito de la aplicación implementada en la actualidad.

    En paralelo con la etapa Find Baseline Version, la etapa Deploy Canary Config implementa la configuración de tasa de éxito nueva para la versión canary de la aplicación.

  • Paso 2: La etapa Deploy Canary (Implementar detección de fallos) y la etapa Deploy Baseline (Implementar línea base) implementan las dos versiones para realizar una comparación, la versión de detección de fallos nueva y una versión de línea base. La versión canary usa la configuración que se creó en Deploy Canary Config, mientras que la versión del modelo de referencia usa la configuración de la versión de producción.

  • Paso 3: La etapa Manual Judgment (Criterio manual) detiene la canalización hasta que continuas. Durante esta etapa, puedes verificar si la versión canary se comporta correctamente.

  • Paso 4: Cuando pasas la etapa Manual Judgment (Criterio manual), tanto la etapa Delete Canary (Borrar detección de fallos) como la etapa Delete Baseline (Borrar línea base) limpian la infraestructura.

    En paralelo a la limpieza, se lanza la etapa Deploy to Production (Implementar en producción) y esta activa la canalización Simple Deploy (Implementación simple) con el mismo parámetro de Tasa de éxito que configuraste al inicio. La misma versión de la app que probaste en la versión canary se implementa en producción.

    La etapa implementación a producción solo se activa si decides continuar durante la etapa orden manual.

  • Paso 5: Finalmente, la etapa Successful Deployment (Implementación correcta) valida que toda la canalización sea correcta. Verifica que hayas dado la autorización en la etapa Orden manual y se ejecuta solo si las etapasImplementación en producción, Borrar versión canary y Borrar modelo de referencia se ejecutaron de forma correcta.

Ahora puedes crear y ejecutar la canalización Canary Deploy (Implementación de detección de fallos).

  1. Para crear la canalización implementación de versión canary, ejecuta el siguiente comando con el fin de recuperar el ID de la canalización Implementación simple y, luego, inyéctalo en la canalización implementación de versión canary:

    cd ~
    wget https://raw.githubusercontent.com/spinnaker/spinnaker/master/solutions/kayenta/pipelines/canary-deploy.json
    export PIPELINE_ID=$(spin pipeline get -a sampleapp -n 'Simple deploy' | jq -r '.id')
    jq '(.stages[] | select(.refId == "9") | .pipeline) |= env.PIPELINE_ID | (.stages[] | select(.refId == "8") | .pipeline) |= env.PIPELINE_ID' canary-deploy.json | \
        sed "s/my-kubernetes-account/spinnaker-install-account/g" > updated-canary-deploy.json
        spin pipeline save --file updated-canary-deploy.json
    
  2. Si no ves la canalización implementación de versión canary en Spinnaker, vuelve a cargar la página de sampleapp, y selecciona Canalizaciones.

  3. Para iniciar la canalización Canary Deploy (Implementación de detección de fallos):

    1. Selecciona Start Manual Execution.
    2. Selecciona una Success Rate de 80.
    3. Selecciona Run.
  4. Cuando la canalización alcance la etapa Manual Judgment, no selecciones Continue porque primero debes comparar la versión canary con la versión del modelo de referencia.

    Etapa de orden manual de la canalización canary

  5. En Cloud Shell, ejecuta el comando kubectl -n default get pods para ver los pods nuevos con las etiquetas canary y baseline:

    NAME                                READY STATUS  RESTARTS  AGE
    injector-66bd655ffd-9ntwx           1/1   Running 0         30m
    sampleapp-5cdf8f55dd-995rz          1/1   Running 0         28m
    sampleapp-5cdf8f55dd-dqq8n          1/1   Running 0         28m
    sampleapp-5cdf8f55dd-ntq57          1/1   Running 0         28m
    sampleapp-5cdf8f55dd-rlpzp          1/1   Running 0         28m
    sampleapp-baseline-567b8d6849-gsgqr 1/1   Running 0          4m
    sampleapp-canary-54b9759dd6-gmjhc   1/1   Running 0          4m
    
  6. En Google Cloud Console, ve a Monitoring.

    Ir a Monitoring

  7. Si el Explorador de métricas aparece en el panel de navegación, selecciona Explorador de métricas. De lo contrario, selecciona Recursos y, luego, Explorador de métricas.

  8. Asegúrate de que esté seleccionada la pestaña Métrica.

  9. Para mostrar la tasa de error del modelo de referencia y la versión canary, especifica los siguientes parámetros:

    1. Metric: external.googleapis.com/prometheus/requests
    2. Filters:
      1. http_code igual a 500
      2. version diferente (!=) de prod

    Si faltan datos en Monitoring, espera unos minutos hasta que aparezcan.

  10. Compara la versión canary (de color violeta en el siguiente gráfico) con la versión del modelo de referencia (de color azul en el siguiente gráfico). Es posible que los colores varíen en tu gráfico. En este instructivo, la versión canary tiene una tasa de error más baja que la versión del modelo de referencia. Por lo tanto, es seguro implementar por completo la versión canary en producción. Si la versión canary no tuvo una tasa de error más baja, quizás desees detener la implementación en esta etapa y hacer algunas correcciones en la app.

    Gráfico que compara la tasa de error de la versión canary con la versión del modelo de referencia

  11. En Spinnaker, en el diálogo orden manual, selecciona Continuar.

  12. Cuando finalice la implementación, regresa a Monitoring.

    Ir a Monitoring

  13. Si el Explorador de métricas aparece en el panel de navegación, selecciona Explorador de métricas. De lo contrario, selecciona Recursos y, luego, Explorador de métricas.

  14. Asegúrate de que esté seleccionada la pestaña Métrica.

  15. Selecciona el cuadro que tiene la etiqueta Find resource type and metric y, a continuación, selecciona estos elementos en el menú o ingresa sus nombres. Usa la siguiente información para completar los campos de este cuadro de texto:

    1. En Metric, selecciona o ingresa external.googleapis.com/prometheus/requests.
    2. En el campo Group By, ingresa http_code.

    En el siguiente gráfico, la tasa de solicitudes HTTP que respondió la app se divide según el código de estado HTTP:

    Gráfico que compara la tasa de solicitudes HTTP.

    En este gráfico, se muestra la tasa de códigos HTTP, 200 y 500, para todos los pods: producción, modelo de referencia y versión canary. Debido a que la versión canary tenía una tasa de error más baja, la implementaste en producción. Luego de un período corto durante la implementación, en el que la cantidad total de solicitudes es ligeramente más baja, puedes ver que la tasa de error general disminuye: la versión canary se implementó correctamente en producción.

Automatización del análisis de versiones canary

Una implementación de versión canary es útil, pero la forma en que está configurada en este momento, indica que es un proceso manual. Debes verificar manualmente que la versión canary se comporte como deseas antes de realizar la implementación completa; y la diferencia entre la versión canary y la del modelo de referencia no siempre es clara.

La automatización del análisis de versiones canary es una buena idea: evitas ocuparte de esa tarea y el análisis estadístico automatizado es más adecuado que el manual para detectar problemas en un conjunto de métricas. En esta sección, la etapa orden manual se reemplaza por un análisis automatizado de versión canary.

Habilita la compatibilidad con versiones canary

Primero configura la característica de análisis automatizado de versiones canary en Spinnaker, que se llama Kayenta. Para configurar Kayenta, usa Halyard, la misma herramienta que se usa en la configuración y la implementación de Spinnaker.

  1. Configura Kayenta para usar Monitoring como backend:

    hal config canary google enable
    hal config canary google account add kayenta-tutorial --project $DEVSHELL_PROJECT_ID
    hal config canary google edit --stackdriver-enabled=true
    
  2. Aplica la configuración nueva:

    ~/cloudshell_open/spinnaker-for-gcp/scripts/manage/push_and_apply.sh
    

    La implementación demora unos minutos.

Configura la característica de análisis automatizado de versión canary

Una vez que Kayenta está habilitado, configúralo para sampleapp.

  1. En Spinnaker, selecciona Config (Configuración).

  2. En la sección Features, selecciona Canary y, luego, Save Changes.

    Captura de pantalla de las características de la canalización

Crea una configuración de versión canary

En Spinnaker, el análisis automatizado de versiones canary ejecuta una prueba estadística en diferentes métricas y arroja una puntuación como resultado. Esta puntuación oscila entre 0 y 100 y representa la cantidad de métricas que aprueban o reprueban en la comparación entre el modelo de referencia y la versión canary. Puedes modificar la puntuación ubicando las métricas en diferentes grupos, con diferentes ponderaciones en cada grupo. Según la puntuación del análisis, es posible que quieras seguir adelante con la implementación o no. Si utilizas una métrica única, como en este instructivo, la puntuación solo puede ser 0 (reprobado) o 100 (aprobado).

Es posible que una aplicación tenga varias configuraciones de versiones canary que se pueden compartir entre distintas aplicaciones. Una configuración de versión canary consta de dos elementos principales:

  • Un conjunto de métricas para analizar (posiblemente en diferentes grupos)
  • Umbrales marginal y de aprobación para la puntuación

En una canalización de implementación, se utiliza una configuración de versión canary en la etapa Canary Analysis. Esta etapa puede incluir varias ejecuciones de versiones canary. Si la puntuación de cualquiera de las ejecuciones está por debajo del umbral marginal, se detiene la etapa y no se realizan las otras ejecuciones. Para que toda la etapa se considere exitosa, la puntuación de la última ejecución debe estar por encima del umbral de aprobación.

Para crear una configuración de versión canary, sigue estos pasos:

  1. Ahora que la versión canary está habilitada, la sección Pipelines se reemplaza por Delivery (si no ves la sección Delivery, vuelve a cargar Spinnaker). En la sección Delivery, ve a Canary Configs.
  2. Selecciona Add Configuration.
  3. En Configuration Name, ingresa kayenta-test.
  4. En la sección Metrics, selecciona Add Metric.
  5. En el cuadro de diálogo Add Metric, ingresa los siguientes valores y, luego, selecciona OK:

    • Name: error_rate
    • Fail on: increase
    • Resource Type: k8s_container
    • Metric type: external.googleapis.com/prometheus/requests
    • Aligner: ALIGN_RATE
    • Filter Template: Elige Create new.

      • Para Name de la plantilla del filtro nueva, ingresa: http_code
      • Para Template de la plantilla del filtro nueva, ingresa: metric.labels.http_code = "500" AND resource.label.pod_name = starts_with("${scope}")
      • Selecciona Save.
  6. En la sección Scoring, establece Group 1 en 100.

  7. Selecciona Save changes.

Agrega una etapa de análisis de versiones canary a la canalización

Ahora que ya tienes una configuración de versión canary, modifica la canalización de implementación existente para reemplazar la etapa Manual Judgment por una etapa Canary Analysis que use esta configuración.

  1. Ve a Entrega > Canalizaciones, y para la canalización Canary Deploy (Implementación de versión canary), selecciona Configure (Configurar).

    Captura de pantalla del botón de configuración para la implementación de versiones canary

  2. Selecciona Add stage.

  3. En Type, selecciona Canary Analysis.

  4. En la sección Depends On, modifica la etapa nueva para que dependa de las siguientes selecciones:

    • Deploy Canary
    • Deploy Baseline
  5. Completa la sección Canary Analysis Configuration con los siguientes valores:

    Nombre del parámetro Valor Definición
    Analysis Type Real Time (Manual) El modo automático, en el que la versión canary y la del modelo de referencia se crean para ti, aún no está disponible en Kubernetes.
    Config Name kayenta-test Nombre de la configuración de versión canary que creaste antes.
    Lifetime 0 hours 5 minutes Tiempo que debería durar el análisis de versiones canary.
    Retraso 0 Tiempo que le damos a la aplicación para arrancar antes de realizar el análisis.
    Interval 5 Ventana de tiempo que debería usar Kayenta para ejecutar un análisis estadístico único.
    Baseline sampleapp-baseline Implementación en GKE que debería usar Kayenta como modelo de referencia.
    Baseline Location default Espacio de nombres en GKE en el que reside el modelo de referencia.
    Canary sampleapp-canary Implementación en GKE que Kayenta debería usar como versión canary.
    Canary Location default Espacio de nombres en GKE en el que reside la versión canary.
    Marginal 75 Puntuación límite para una versión canary marginal aprobada.
    Pass 95 Puntuación límite para una versión canary general aprobada.
  6. En la sección Execution Options, selecciona Ignore the failure. Ignoras la falla de modo que puedas destruir el modelo de referencia y la versión canary, aunque el análisis de versiones canary haya fallado. Más adelante en el instructivo, modificarás las etapas para tener en cuenta una potencial falla de la versión canary.

  7. En el esquema de la canalización, selecciona Deploy to Production.

    Captura de pantalla del botón Deploy to Production para la canalización

  8. Cambia la sección Depend On, a los siguientes parámetros:

    1. Agrega Canary Analysis.
    2. Quita Manual Judgment.
  9. Para asegurarte de que solo implementarás en producción si el análisis de versiones canary es exitoso, cambia el parámetro Conditional on Expression.

    ${ #stage('Canary Analysis')['status'].toString() == 'SUCCEEDED'}
    
  10. En el esquema de canalización, selecciona Delete Canary y cambia la sección Depends On a los siguientes parámetros:

    1. Agrega Canary Analysis.
    2. Quita Manual Judgment.
  11. En el esquema de canalización, selecciona Delete Baseline y cambia la sección Depends On.

    1. Agrega Canary Analysis.
    2. Quita Manual Judgment.
  12. Para garantizar que toda la canalización falle si falla el análisis de versiones canary, en el esquema de la canalización, selecciona Successful deployment y, luego, el ícono de editar.

    Edita la condición previa existente de la implementación exitosa

    1. Cambia la Expresión por lo siguiente:

      ${ #stage('Canary Analysis')['status'].toString() == 'SUCCEEDED'}
      
    2. Seleccione Update.

  13. Para finalizar, reemplaza la etapa orden manual por la etapa análisis de versiones canary que creaste recientemente.

    1. En el esquema de la canalización, selecciona Manual Judgment.
    2. Selecciona Remove stage.
  14. Selecciona Save changes.

    Ahora la canalización se ve como la siguiente imagen:

    Visualización de la canalización del análisis de versiones canary

Prueba tu nueva canalización

Ahora que el análisis automatizado de versiones canary está configurado, prueba la canalización para asegurarte de que funcione como se espera.

  1. Ve a Entrega > Canalizaciones y, para la canalización implementación de versiones canary, o implementación de versiones canary automatizada si usaste la CLI, selecciona Comenzar ejecución manual.

  2. Selecciona una Success Rate de 60 y, luego, Run.

  3. Para verificar el progreso actual del análisis de versiones canary, selecciona Canary Analysis y, luego, Task Status. Luego de unos minutos, la etapa Canary Analysis falla porque la tasa de éxito actual en producción es de 80. Cuando falle la etapa Canary Analysis, ve al informe de este análisis de versiones canary.

    1. Selecciona Canary Analysis.
    2. Selecciona Canary Summary.
    3. Selecciona el ícono de informe.

      En la página del informe, la tasa de error es más alta para la versión canary que para la versión del modelo de referencia.

      Ícono de informe del resumen de análisis de versiones canary.

  4. Repite los pasos de esta sección, pero selecciona una Success Rate de 90 para lograr un análisis de versiones canary exitoso.

Limpieza

Sigue estos pasos para evitar que se apliquen cargos a tu cuenta de Google Cloud Platform por los recursos que usaste en el instructivo:

  1. En Cloud Console, ve a la página Administrar recursos.

    Ir a la página Administrar recursos

  2. En la lista de proyectos, selecciona el proyecto que deseas borrar y haz clic en Borrar .
  3. En el cuadro de diálogo, escribe el ID del proyecto y haz clic en Cerrar para borrar el proyecto.

Borra recursos

Si deseas conservar el proyecto de Google Cloud que usaste en este instructivo, borra los recursos individuales:

  1. Borra el clúster de GKE.

    gcloud container clusters delete spinnaker-1
    
  2. Cuando se te pida confirmación, escribe Y.

Próximos pasos