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 implementar métodos de implementación avanzados, inclusive implementaciones de detección de fallos.
En una implementación de detección de fallos, expones una nueva versión de tu aplicación a una pequeña parte del tráfico de la 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 tus usuarios. Para utilizar la implementación de detección de fallos, debes comparar con precisión el comportamiento de las versiones nueva y anterior de tu aplicación. La diferencia puede ser sutil y demorar cierto tiempo en manifestarse. Es posible que también tengas muchas métricas diferentes para examinar.
Para resolver esos problemas, Spinnaker tiene una característica de análisis automatizado de detección de fallos. 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. Este instructivo te muestra cómo realizar un análisis automatizado de detección de fallos en una aplicación implementada en GKE y supervisada por Stackdriver.
Spinnaker es una plataforma avanzada de implementación y administración de aplicaciones para organizaciones con situaciones de implementación complejas, que por lo general presenta una función de ingeniería de versión dedicada. Puedes realizar este instructivo aun si no tienes experiencia previa con Spinnaker. Sin embargo, por lo general, los que se encargan de realizar la implementación del análisis automatizado de detección de fallos en producción son equipos con experiencia previa en Spinnaker, con un sistema de supervisión sólido y con conocimiento para determinar si una versión es segura.
Acerca de este instructivo
La aplicación en este instructivo es una simple aplicación “Hola, mundo” cuya tasa de error se configura con una variable de entorno. Para esta aplicación se proporciona una imagen de Docker precompilada. Como se muestra en la imagen siguiente, la aplicación expone las métricas en formato Prometheus, un sistema de supervisión de código abierto popular en la comunidad Kubernetes y compatible con Stackdriver.
Objetivos
- Crear un clúster de GKE.
- Instalar Spinnaker.
- Implementar una aplicación en GKE sin una implementación de detección de fallos.
- Configurar y ejecutar una implementación de detección de fallos de la aplicación.
- Configurar el análisis automatizado de detección de fallos.
- Evaluar el análisis automatizado de detección de fallos.
Costos
- GKE
- Stackdriver
Antes de comenzar
Selecciona o crea un proyecto de GCP.
Habilita la facturación para tu proyecto.
Crea una cuenta de Stackdriver.
Cuando finalices este instructivo, puedes evitar que continúe la facturación borrando los recursos que creaste. Consulta la sección Limpieza para obtener más detalles.
Cómo configurar tu entorno
En esta sección vas a configurar la infraestructura necesaria para completar el instructivo. Ejecuta todos los comandos terminales en este instructivo desde Cloud Shell.
Abre Cloud Shell.
Exporta el ID del proyecto como una variable.
export GOOGLE_CLOUD_PROJECT=[PROJECT_ID]
donde:
[PROJECT_ID]
representa el ID del proyecto que estás utilizando.
Crea un clúster de GKE.
gcloud config set project $GOOGLE_CLOUD_PROJECT gcloud config set compute/zone us-central1-f gcloud services enable container.googleapis.com gcloud beta container clusters create kayenta-tutorial \ --machine-type=n1-standard-2 --enable-stackdriver-kubernetes \ --scopes=gke-default,compute-ro
Instala el complemento de integración para Stackdriver-Prometheus.
kubectl apply --as=admin --as-group=system:masters -f \ https://storage.googleapis.com/stackdriver-prometheus-documentation/rbac-setup.yml curl -sS "https://storage.googleapis.com/stackdriver-prometheus-documentation/prometheus-service.yml" | \ sed "s/_stackdriver_project_id:.*/_stackdriver_project_id: $GOOGLE_CLOUD_PROJECT/" | \ sed "s/_kubernetes_cluster_name:.*/_kubernetes_cluster_name: kayenta-tutorial/" | \ sed "s/_kubernetes_location:.*/_kubernetes_location: us-central1-f/" | \ kubectl apply -f -
Implementa Spinnaker en tu clúster de GKE nuevo.
curl -sSL "https://spinnaker.io/downloads/kubernetes/quick-install.yml" | \ sed 's/version:.*/version: 1.10.5/g' | kubectl apply -f -
La implementación toma unos minutos en completarse. Para verificar el progreso, ejecuta el comando
watch kubectl -n spinnaker get pods
. Para detener el comandowatch
, presiona Ctrl+C. Una vez finalizada la implementación, este comando muestra todos los pods comoReady 1/1
.NAME READY STATUS RESTARTS AGE minio-deployment-7c665c4b57-jx7px 1/1 Running 0 5m spin-clouddriver-789c6fff77-rjtc6 1/1 Running 0 4m spin-deck-68b5968f7f-trmkn 1/1 Running 0 4m spin-echo-57dbff9fb8-rq5qc 1/1 Running 0 4m spin-front50-67965475b8-l24db 1/1 Running 0 4m spin-gate-6d8bbf8c45-m9pzn 1/1 Running 0 4m spin-halyard-59fd54bd69-xns49 1/1 Running 0 5m spin-kayenta-99b97b85f-4gvsv 1/1 Running 0 4m spin-orca-5748974888-cph9g 1/1 Running 0 4m spin-redis-6d49c9c5b9-q2hzm 1/1 Running 0 4m spin-rosco-6b4ddbcb94-mjrht 1/1 Running 0 4m
Para acceder a Spinnaker, redirecciona un puerto local al componente deck de Spinnaker.
DECK_POD=$(kubectl -n spinnaker get pods -l \ cluster=spin-deck,app=spin \ -o=jsonpath='{.items[0].metadata.name}') kubectl -n spinnaker port-forward $DECK_POD 8080:9000 >/dev/null &
En Cloud Shell, haz clic en el ícono Vista previa web y selecciona Preview on port 8080 (Vista previa en puerto 8080).
Cómo implementar una aplicación con Spinnaker
En esta sección, aprendes a configurar Spinnaker para implementar una aplicación en el clúster de GKE.
Cómo crear una aplicación de Spinnaker
Antes de la implementación, debes crear una aplicación de Spinnaker.
En Spinnaker, haz clic en Actions (Acciones) > Create Application (Crear aplicación).
En el diálogo Aplicación nueva, ingresa los siguientes valores:
- Nombre:
sampleapp
Correo electrónico del propietario:
[example@example.com]
- Nombre:
Haz clic en Crear.
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.
Cómo crear y ejecutar una canalización de implementación
En esta sección, primero implementas la aplicación con una simple canalización de Spinnaker que toma un parámetro successRate
para crear una implementación en GKE con cuatro pods. Esos pods arrojan errores al azar a una tasa que corresponde con el parámetro successRate
. En este instructivo, arrojan 500 errores a una tasa de 100 - successRate
.
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.
wget https://raw.githubusercontent.com/spinnaker/spinnaker/master/solutions/kayenta/pipelines/simple-deploy.json curl -d@simple-deploy.json -X POST \ -H "Content-Type: application/json" -H "Accept: */*" \ http://localhost:8080/gate/pipelines
En la sección Canalizaciones de Spinnaker, aparece una canalización llamada Simple deploy (Implementación simple). Si no la ves, vuelve a cargar la página. Haz clic en Start Manual Execution (Comenzar ejecución manual).
En la ventana Confirmar ejecución, selecciona una Tasa de éxito de 70, y luego haz clic en Ejecutar. Luego de unos segundos, la canalización implementa correctamente la configuración de la aplicación y los cuatro pods.
En Cloud Shell, crea un pod que realice solicitudes a tu aplicación nueva hasta que termine el instructivo.
kubectl -n default run injector --image=alpine -- \ /bin/sh -c "apk add --no-cache --yes curl; \ while true; do curl -sS --max-time 3 \ http://sampleapp:8080/; done"
Cómo verificar los registros del inyector
Para ver el comportamiento de la aplicación, verifica los registros del inyector.
kubectl -n default logs -f \ $(kubectl -n default get pods -l run=injector \ -o=jsonpath='{.items[0].metadata.name}')
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 en este instructivo ya sabes que no funciona correctamente ya que la implementaste con solo el 70% de tasa de éxito.
La aplicación expone un extremo de /metrics
con métricas en el formato Prometheus que son transferidas por Stackdriver. En esta sección, podrás visualizar esas métricas en Stackdriver.
En Stackdriver, ve a Explorador de métricas.
En el campo Encontrar tipo de recurso y métrica, ingresa el siguiente comando:
external.googleapis.com/prometheus/requests
Para definir mejor el gráfico, ingresa
http_code
en el campo Agrupar según. En el siguiente gráfico, las tasas de solicitudes HTTP que respondió la aplicación se agrupan según el código de estado HTTP:
Como puedes ver en el gráfico, la aplicación tiene actualmente una tasa de error inaceptable; alrededor del 30%, según lo esperado. El resto del instructivo te guía por los pasos de la configuración de una canalización de implementación de detección de fallos y un análisis automático para evitar futuras implementaciones de una aplicación con una tasa de error tan alta.
Cómo crear una implementación de detección de fallos
En esta sección, crearás una canalización de implementación de detección de fallos, sin análisis automatizado, para probar la versión nueva de la aplicación antes de implementarla por completo en producción. En la siguiente imagen, se muestran las diferentes etapas de esta canalización:
- 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 Configuración 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 (Buscar versión de línea base), la etapa Deploy Canary Config (Configurar implementación de detección de fallos) implementa la configuración de tasa de éxito nueva para la versión de detección de fallos 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 de detección de fallos utiliza la configuración que se creó en Deploy Canary Config (Configurar implementación de detección de fallos), mientras que la versión de línea base utiliza 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 de detección de fallos 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 aplicación que probaste en la detección de fallos se implementa en producción.
La etapa Deploy to Production (Implementar en producción) solo se activa si decides continuar durante la etapa Manual Judgment (Criterio manual).
Paso 5: Finalmente, la etapa Successful Deployment (Implementación correcta) valida que toda la canalización sea correcta. Verifica que hayas dado la instrucción en la etapa Manual Judgment (Criterio manual) y solo se ejecuta si las etapas Deploy to Production (Implementar en producción), Delete Canary (Borrar detección de fallos) y Delete Baseline (Borrar línea base) se ejecutaron correctamente.
Ahora puedes crear y ejecutar la canalización Canary Deploy (Implementación de detección de fallos).
Para crear la canalización Canary Deploy (Implementación de detección de fallos), ejecuta el siguiente comando con el fin de buscar el ID de la canalización Simple deploy (Implementación simple) y, luego, inyéctalo en la canalización Canary Deploy (Implementación de detección de fallos):
wget https://raw.githubusercontent.com/spinnaker/spinnaker/master/solutions/kayenta/pipelines/canary-deploy.json export PIPELINE_ID=$(curl \ localhost:8080/gate/applications/sampleapp/pipelineConfigs/Simple%20deploy \ | jq -r '.id') jq '(.stages[] | select(.refId == "9") | .pipeline) |= env.PIPELINE_ID | (.stages[] | select(.refId == "8") | .pipeline) |= env.PIPELINE_ID' canary-deploy.json | \ curl -d@- -X POST \ -H "Content-Type: application/json" -H "Accept: */*" \ http://localhost:8080/gate/pipelines
Si no ves la canalización Canary Deploy (Implementación de detección de fallos) en Spinnaker, vuelve a cargar la página de sampleapp, y haz clic en Canalizaciones.
Para iniciar la canalización Canary Deploy (Implementación de detección de fallos):
- Haz clic en Start Manual Execution (Comenzar ejecución manual).
- Selecciona una Tasa de éxito de 80.
- Haz clic en Ejecutar.
Cuando la canalización llegue a la etapa Manual Judgment (Criterio manual), todavía no hagas clic en Continue (Continuar) ya que debes comparar la versión de detección de fallos con la versión de línea base.
En Cloud Shell, ejecuta el comando
kubectl -n default get pods
para ver los pods nuevos etiquetados como detección de fallos y línea base: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
En Stackdriver, ve a Explorador de métricas.
Si ya existen métricas configuradas en Explorador de métricas, quita todas las configuraciones existentes de la forma.
Selecciona los datos de detección de fallos como primera métrica, y especifica los siguientes parámetros:
- Métrica:
external.googleapis.com/prometheus/requests
Filtros:
http_code
es500
pod_name
essampleapp-canary-*
- Métrica:
Para seleccionar los datos de línea base como segunda métrica, haz clic en + Agregar métrica, y completa los siguientes campos:
- Métrica:
external.googleapis.com/prometheus/requests
Filtros:
http_code
es500
pod_name
essampleapp-baseline-*
- Métrica:
Compara la versión de detección de fallos (de color violeta en el siguiente gráfico) con la versión de línea base (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 de detección de fallos tiene una tasa de error más baja que la versión de línea base. Por lo tanto, es seguro implementar por completo la versión de detección de fallos en producción. Si la versión de detección de fallos 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 aplicación.
En Spinnaker, en el diálogo Manual Judgement (Criterio manual), haz clic en Continue (Continuar).
Cuando se finalice la implementación, vuelve a Explorador de métricas en Stackdriver.
Si ya existen métricas configuradas en Explorador de métricas, quita todas las configuraciones existentes de la forma.
En el campo Encontrar tipo de recurso y métrica, ingresa el siguiente comando:
external.googleapis.com/prometheus/requests
En el campo Agrupar según, ingresa
http_code
. En el siguiente gráfico, la tasa de solicitudes HTTP que respondió la aplicación se divide según el código de estado HTTP:Este gráfico muestra la tasa de códigos HTTP, 200 y 500, para todos los pods: producción, línea base y detección de fallos. Debido a que la versión de detección de fallos tenía una tasa de error más baja, implementaste esta versión 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 general de errores disminuye: la versión de detección de fallos se implementó correctamente en producción.
Cómo automatizar el análisis de detección de fallos
Una implementación de detección de fallos es útil, pero en la implementación actual es un proceso manual. Debes verificar manualmente que la detección de fallos se comporte como deseas antes de realizar la implementación completa; y la diferencia entre la detección de fallos y la línea base no siempre es clara.
La automatización del análisis de detección de fallos es una buena idea; no debes hacerlo tú mismo y un análisis estadístico automatizado es más adecuado que un análisis humano para detectar problemas en un conjunto de métricas. En esta sección, la etapa Manual Judgement (Criterio manual) se reemplaza con un análisis automatizado de detección de fallos.
Cómo habilitar la asistencia de detección de fallos
Primero, configura la característica de análisis automatizado de detección de fallos en Spinnaker, que se llama Kayenta. Para configurar Kayenta, utiliza Halyard, la misma herramienta que se utiliza en la configuración y la implementación de Spinnaker.
En Cloud Shell, obtén el ID de tu proyecto.
echo $GOOGLE_CLOUD_PROJECT
Obtén un shell en el pod de Halyard.
export HALYARD_POD=$(kubectl -n spinnaker get pods -l \ stack=halyard,app=spin \ -o=jsonpath='{.items[0].metadata.name}') kubectl -n spinnaker exec -it $HALYARD_POD -- bash
Configura Kayenta para utilizar Stackdriver como backend.
hal config canary google enable hal config canary google account add kayenta-tutorial --project [PROJECT_ID] hal config canary google edit --stackdriver-enabled=true
donde:
[PROJECT_ID]
representa el ID del proyecto que recuperas.
Aplica la configuración nueva y sal del pod de Halyard.
hal deploy apply exit
La implementación toma unos minutos en completarse. Para verificar el progreso, ejecuta los comandos
watch kubectl -n spinnaker get pods
. Cuando se completa la implementación, este comando muestra todos los pods comoReady 1/1
. Para detener el comandowatch
, presiona Ctrl+C.NAME READY STATUS RESTARTS AGE minio-deployment-7c665c4b57-prl6d 1/1 Running 0 1h spin-clouddriver-6c4f954667-8769c 1/1 Running 0 1h spin-deck-7d44499f9b-hkqz4 1/1 Running 0 1h spin-echo-6cf4bbbbfc-vxzlr 1/1 Running 0 1h spin-front50-7666c894c6-fm7sz 1/1 Running 0 1h spin-gate-76f789696d-vsn98 1/1 Running 0 1h spin-halyard-59fd54bd69-vb99h 1/1 Running 0 1h spin-kayenta-84f6b9b697-5krhh 1/1 Running 0 1m spin-orca-78f5c74c6f-srl4f 1/1 Running 0 1h spin-redis-6d49c9c5b9-gddgv 1/1 Running 0 1h spin-rosco-699cb484f7-grthh 1/1 Running 0 1h
Cómo configurar la característica de análisis automatizado de detección de fallos
Ahora que Kayenta está habilitado, configúralo para sampleapp
.
En Spinnaker, haz clic en Config (Configuración).
En la sección Features (Características), selecciona Canary (Detección de fallos) y, luego, haz clic en Save Changes (Guardar cambios).
Cómo crear una configuración de detección de fallos
En Spinnaker, un análisis automatizado de detección de fallos 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 aprobaron o fallaron la comparación entre la línea base y la detección de fallos. 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).
Una aplicación puede tener varias configuraciones de detección de fallos que se pueden compartir en varias aplicaciones. Una configuración de detección de fallos consta de dos elementos principales:
- Un conjunto de métricas para analizar (posiblemente en diferentes grupos)
- Umbrales marginal y aprobado para la puntuación
En una canalización de implementación, se utiliza una configuración de detección de fallos en la etapa Canary Analysis (Análisis de detección de fallos). Esta etapa puede incluir varias ejecuciones de detección de fallos. 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 aprobado.
Para crear una configuración de detección de fallos, sigue estos pasos:
Ahora que la detección de fallos está habilitada, vuelve a cargar Spinnaker. La sección Canalizaciones se reemplaza por Entrega. En la sección Entrega, ve a Configuración de detección de fallos.
Haz clic en Agregar configuración.
En Nombre de configuración, ingresa
kayenta-test
.En la sección Plantillas de filtro, haz clic en Agregar plantilla.
En el diálogo Agregar plantilla, agrega los siguientes valores y, luego, haz clic en Aceptar:
- Nombre:
http_code
- Plantilla:
metric.labels.http_code = "500" AND resource.label.pod_name = starts_with("${scope}")
La variable
scope
se propaga en el entorno de ejecución con el nombre de la Implementación en GKE para la que Kayenta debería estar verificando las métricas. Para la línea base essampleapp-baseline
y en el caso de la detección de fallos essampleapp-canary
.- Nombre:
En la sección Métricas, haz clic en Agregar métricas.
En el diálogo Agregar métricas, ingresa los siguientes valores y, luego, haz clic en Aceptar:
- Nombre:
error_rate
- Falló en:
increase
- Plantilla del filtro:
http_code
- Tipo de recurso:
k8s_container
- Tipo de métrica:
external.googleapis.com/prometheus/requests
- Alineador:
ALIGN_RATE
- Nombre:
En la sección Puntuación, selecciona los siguientes valores:
- Marginal: 75
- Aprobado: 95
- Grupo 1: 100
Haz clic en Guardar cambios.
Cómo agregar una etapa de análisis de detección de fallos a la canalización
Ahora que ya tienes una configuración de detección de fallos, modifica tu canalización de implementación existente para reemplazar la etapa Manual Judgment (Criterio manual) por una etapa Canary Analysis (Análisis de detección de fallos) que utilice esta configuración.
Ve a Entrega > Canalizaciones, y para la canalización Canary Deploy (Implementación de detección de fallos), haz clic en Configure (Configurar).
Haz clic en Agregar etapa.
En Tipo, selecciona Análisis de detección de fallos.
En la sección Depende de, modifica la etapa nueva para que dependa de las siguientes selecciones:
- Deploy Canary (Implementar detección de fallos)
- Deploy Baseline (Implementar línea base)
Completa la sección Canary Analysis Configuration (Configuración de análisis de detección de fallos) con los siguientes valores:
Nombre del parámetro Valor Definición Tipo de análisis Tiempo real (manual) El modo automático, en el que la detección de fallos y la línea base se crean para ti aún no está disponible en Kubernetes. Nombre de configuración kayenta-test El nombre de la configuración de detección de fallos que creaste antes. Siempre 0 horas 5 minutos El tiempo que debería durar el análisis de detección de fallos. Retraso 0 El tiempo que le damos a la aplicación para arrancar antes de realizar el análisis. Intervalo 5 La ventana de tiempo que debería usar Kayenta para ejecutar un análisis estadístico único. Punto de referencia sampleapp-baseline La Implementación en GKE que debería usar Kayenta como línea base. Ubicación de línea base Predeterminado El espacio de nombres en GKE en el que reside la línea base. Detección de fallos sampleapp-canary La Implementación en GKE que Kayenta debería usar como detección de fallos. Ubicación de detección de fallos Predeterminado El espacio de nombres en GKE en el que reside la detección de fallos. En la sección Opciones de ejecución, selecciona Ignorar la falla. Ignoras la falla de modo que puedas destruir la línea base y la detección de fallos, aunque el análisis de detección de fallos haya fallado. Más adelante en el instructivo, modificarás las etapas para tener en cuenta una potencial falla de detección de fallos.
En el esquema de canalización, haz clic en Deploy to Production (Implementar en producción).
Cambia la sección Depende de, a los siguientes parámetros:
- Agrega Canary Analysis (Análisis de detección de fallos).
- Quita Manual Judgment (Criterio manual).
Para asegurarte de que solo implementarás en producción si el análisis de detección de fallos es exitoso, cambia el parámetro Condicional según expresión.
${ #stage('Canary Analysis')['status'].toString() == 'SUCCEEDED'}
En el esquema de canalización, haz clic en Borrar detección de fallos, y cambia la sección Depende de a los siguientes parámetros:
- Agrega Canary Analysis (Análisis de detección de fallos).
- Quita Manual Judgment (Criterio manual).
En el esquema de canalización, haz clic en Borrar línea base, y cambia la sección Depende de.
- Agrega Canary Analysis (Análisis de detección de fallos).
- Quita Manual Judgment (Criterio manual).
Para asegurarse de que toda la canalización falla si falla el análisis de detección de fallos, haz clic en Successful deployment (Implementación exitosa) en el esquema de canalización y, luego, haz clic en el ícono Editar para la precondición existente.
Cambia la Expresión por lo siguiente:
${ #stage('Canary Analysis')['status'].toString() == 'SUCCEEDED'}
Haz clic en Actualizar.
Para finalizar, reemplaza la etapa Manual Judgement (Criterio manual) por la etapa Canary Analysis (Análisis de detección de fallos) que creaste recientemente.
- En el esquema de canalización, haz clic en Manual Judgment (Criterio manual).
- Haz clic en Quitar etapa.
Haz clic en Guardar cambios. Ahora la canalización luce como la siguiente imagen:
Cómo probar la canalización nueva
Ahora que el análisis automatizado de detección de fallos está configurado, prueba la canalización para asegurarte de que funciona como se espera.
Ve a Entrega > Canalizaciones, y para la canalización Canary Deploy (Implementación de detección de fallos), o Implementación automatizada de detección de datos si utilizas CLI, haz clic en Comenzar ejecución manual.
Selecciona una Tasa de éxito de 60, y luego haz clic en Ejecutar.
Para verificar el progreso actual del análisis de detección de fallos, haz clic en Canary Analysis (Análisis de detección de fallos), y luego haz clic en Task Status (Estado de la tarea). Luego de unos minutos, la etapa Canary Analysis (Análisis de detección de fallos) falla porque la tasa de éxito actual en producción es de
80
. Cuando falla la etapa Canary Analysis (Análisis de detección de fallos), ve al informe de este análisis de detección de fallos.- Haz clic en Canary Analysis (Análisis de detección de fallos).
- Haz clic en Canary Summary (Resumen de detección de fallos).
Haz clic en el ícono de Informe. En la página del informe, la tasa de error es más alta en el caso de la versión de detección de fallos que para la versión de línea base.
Repite los pasos en esta sección, pero selecciona una Tasa de éxito de 90 para lograr un análisis de detección de fallos exitoso.
Limpieza
Sigue estos pasos para evitar que se apliquen cargos a tu cuenta de Google Cloud Platform por los recursos que usaste en este instructivo:
- En la GCP Console, dirígete a la página Proyectos.
- En la lista de proyectos, selecciona el proyecto que deseas borrar y haz clic en Borrar.
- En el cuadro de diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.
Cómo borrar los recursos
Si deseas conservar el proyecto de GCP que utilizaste para este instructivo, borra los recursos individuales:
Desinstala Spinnaker.
kubectl delete -f https://spinnaker.io/downloads/kubernetes/quick-install.yml
Borra el clúster de GKE.
gcloud container clusters delete kayenta-tutorial
Cuando se te pida confirmación, escribe
Y
.
Próximos pasos
- Lee más información sobre Spinnaker.
- Mira cómo Waze y Netflix utilizan Spinnaker y Kayenta.
- Mira todos los recursos sobre la Entrega continua.
- Aprende a usar Spinnaker con Cloud Build y Cloud Source Repositories.
- Revisa un codelab que abarca la Entrega continua en GKE utilizando Spinnaker.
- Consulta spin, una herramienta de CLI para administrar las aplicaciones y canalizaciones de Spinnaker.
- Prueba otras características de Google Cloud Platform tú mismo. Revisa nuestros instructivos.