Uma maneira simples e segura de automatizar implantações canárias usando Helm

A implantação canária é uma maneira muito eficaz de testar novo código em um subconjunto de usuários. Ela reduz significativamente a carga de tráfego, que poderia causar problemas durante a implantação, já que ocorre apenas dentro de um grupo específico. Esta nota se dedica a como organizar tal implantação usando ferramentas do Kubernetes e automação de implantações. Suponha que você saiba um pouco sobre Helm e recursos do Kubernetes.



Uma implantação canária simples no Kubernetes envolve dois recursos principais: o próprio serviço e a ferramenta de implantação. A implantação canária funciona através de um serviço que interage com dois recursos diferentes, gerenciando o tráfego de atualização. Um desses recursos irá operar com a versão 'canária', enquanto o outro com a versão estável. Nesse cenário, podemos ajustar a quantidade de versões canárias para reduzir o tráfego necessário. Por exemplo, se você preferir usar Yaml, isso seria configurado no Kubernetes da seguinte forma:

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 # O seletor vai direcionar o tráfego para ambas as implantações.

Uma maneira ainda mais simples de visualizar isso é usando kubectl, e na documentação do Kubernetes há até um tutorial completo sobre esse cenário. Mas a questão principal deste post é como vamos automatizar esse processo usando Helm.

Automação da implantação canária

Primeiro, precisaremos de um mapa dos gráficos do Helm, que já inclui os recursos discutidos acima. Ele deve ter a seguinte aparência:

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

A base do conceito do Helm é a gestão de versões múltiplas de releases. A versão estável é nosso ramo principal de código estável do projeto. Mas, com o Helm, podemos implantar uma versão canária com nosso código experimental. O importante é manter a troca de tráfego entre a versão estável e a versão canária. Vamos gerenciar tudo isso com um seletor especial:

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

Nossos recursos de deployment, tanto os 'canário' quanto os estáveis, indicarão esse rótulo nos módulos. Se tudo estiver configurado corretamente, durante o deployment da versão canária do nosso gráfico Helm, veremos que o tráfego será direcionado para os módulos recém-implantados. A versão estável deste comando será assim:

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

Agora vamos verificar nosso release canário. Para fazer o deployment da versão canária, precisamos ter em mente duas coisas. O nome do release deve ser diferente, para que não façamos uma atualização na versão estável atual. A versão e a tag também devem ser diferentes, para que possamos implantar um código distinto e identificar as diferenças pelos rótulos dos recursos.

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

É isso! Se você pingar o serviço, verá que a atualização canária direciona o tráfego apenas parte do tempo.

Se você está procurando ferramentas de automação de deployment que incluam a lógica descrita, considere Deliverybot e no ferramentas de automação Helm no GitHub. Os gráficos Helm usados para implementar o método descrito acima estão no Github, aqui. Na verdade, este foi um panorama teórico de como implementar a automação do deployment de versões canárias na prática, com conceitos e exemplos concretos.

Fonte: habr.com