Una forma sencilla y segura de automatizar despliegues canarios usando Helm

Una forma sencilla y segura de automatizar despliegues canarios usando Helm

El despliegue canario es una forma muy eficaz de probar nuevo código en un subconjunto de usuarios. Reduce significativamente la carga de tráfico, lo que puede generar problemas durante el despliegue, ya que ocurre solo dentro de un grupo específico. Esta nota se dedica a cómo organizar dicho despliegue utilizando Kubernetes y la automatización del despliegue. Se supone que sabes algo sobre Helm y los recursos de Kubernetes.

Una forma sencilla y segura de automatizar despliegues canarios usando Helm

Un despliegue canario simple en Kubernetes incluye dos recursos clave: el servicio y la herramienta de despliegue. El despliegue canario funciona a través de un servicio que interactúa con dos recursos diferentes que manejan el tráfico de actualización. Uno de estos recursos trabajará con la versión 'canaria', y el otro con la estable. En esta situación, podemos regular la cantidad de versiones canarias para reducir la carga de tráfico que se requiere atender. Si, por ejemplo, prefieres usar YAML, se verá de la siguiente manera en Kubernetes:

kind: Deployment
metadata:
  name: app-canary
  labels:
    app: app
spec:
  replicas: 1
  ...
    image: myapp:canary
---
kind: Deployment
metadata:
  name: app
  labels:
    app: app
spec:
  replicas: 5
  ...
    image: myapp:stable
---
kind: Service
selector:
  app: app # El selector dirigirá el tráfico a ambos despliegues.

Es aún más fácil visualizar esta opción en kubectl, y en la documentación de Kubernetes incluso hay un tutorial completo para este escenario. Pero la pregunta principal de este post es cómo planeamos automatizar este proceso utilizando Helm.

Automatización del despliegue canario

Primero, necesitaremos un gráfico de charts de Helm que ya incluya los recursos que discutimos arriba. Debería verse aproximadamente así:

~\/charts\/app
├── Chart.yaml
├── README.md
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   └── service.yaml
└── values.yaml

La base del concepto de Helm es la gestión de versiones múltiples de lanzamientos. La versión estable es nuestra rama principal y estable del código del proyecto. Pero con Helm podemos desplegar un lanzamiento canario con nuestro código experimental. Lo principal es mantener el intercambio de tráfico entre la versión estable y el lanzamiento canario. Gestionaremos todo esto con un selector especial:

selector:
  app.kubernetes.io\/name: myapp

Nuestros recursos de despliegue, tanto "canarios" como estables, indicarán esta etiqueta en los módulos. Si se configura todo correctamente, durante el despliegue de la versión canaria de nuestro gráfico Helm, veremos que el tráfico se dirige a los módulos recién desplegados. La versión estable de este comando será así:

helm upgrade
  --install myapp 
  --namespace default 
  --set app.name=myapp       # Se incluye en app.kubernetes.io/name
  --set app.version=v1       # Se incluye en app.kubernetes.io/version
  --set image.tag=stable 
  --set replicaCount=5

Ahora comprobamos nuestro lanzamiento canario. Para desplegar la versión canaria, debemos recordar dos cosas. El nombre del lanzamiento debe ser diferente, para que no actualicemos la versión estable actual. La versión y la etiqueta también deben ser diferentes, para que podamos desplegar otro código y determinar diferencias por etiquetas de recursos.

helm upgrade
  --install myapp-canary 
  --namespace default 
  --set app.name=myapp       # Se incluye en app.kubernetes.io/name
  --set app.version=v2       # Se incluye en app.kubernetes.io/version
  --set image.tag=canary 
  --set replicaCount=1

¡Y eso es todo! Si hacemos ping al servicio, veremos que la actualización canaria dirige el tráfico solo parte del tiempo.

Si estás buscando herramientas de automatización de despliegue que incluyan la lógica descrita, presta atención a Deliverybot y en herramientas de automatización de Helm en GitHub. Los gráficos de Helm utilizados para implementar el método descrito anteriormente se encuentran en Github, aquí. En general, esta fue una revisión teórica de cómo implementar la automatización del despliegue de versiones canarias en la práctica, con conceptos y ejemplos concretos.

Fuente: habr.com

Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS 🔥 Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS | ProHoster