Un modo semplice e sicuro per automatizzare i deploy canary con Helm

Il deploy canary è un modo molto efficace per testare nuovo codice su un sottoinsieme di utenti. Riduce notevolmente il carico di traffico, evitando problemi durante il rilascio, poiché avviene solo all'interno di un sotto-gruppo specifico. Questo articolo è dedicato a come organizzare un simile deploy utilizzando Kubernetes e strumenti di automazione del rilascio. Si presume che tu abbia una certa familiarità con Helm e le risorse di Kubernetes..



Un semplice deploy canary in Kubernetes include due risorse chiave: il servizio stesso e lo strumento di rilascio. Il deploy canary funziona attraverso un'unica service che interagisce con due risorse differenti che gestiscono il traffico dell'aggiornamento. Una di queste risorse opererà con una versione «canary», mentre l'altra con quella stabile. In questa situazione possiamo regolare il numero di versioni canary per ridurre il volume del traffico da gestire. Se, ad esempio, preferisci utilizzare Yaml, questo si presenterà in Kubernetes nel seguente modo:

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 # Il selettore instraderà il traffico verso entrambe le distribuzioni.

È ancora più facile immaginare questa variante su kubectl, e in documentazione di Kubernetes c'è addirittura un tutorial completo su questo scenario. Ma la principale questione di questo post è come intendiamo automatizzare questo processo, utilizzando Helm.

Automatizzazione del deployment canary

Prima di tutto avremo bisogno di una mappa dei chart di Helm, in cui sono già inclusole risorse di cui abbiamo parlato sopra. Dovrebbe apparire all'incirca così:

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

La base del concetto di Helm è la gestione delle versioni multiple dei rilasci. La versione stabile è il nostro ramo principale di codice stabile del progetto. Ma con Helm possiamo implementare un rilascio canary con il nostro codice sperimentale. L'importante è mantenere lo scambio di traffico tra la versione stabile e il rilascio canary. Gestiremo tutto ciò tramite un selettore speciale:

selector:
  app.kubernetes.io/name: myapp

Le nostre risorse di deploy, sia "canary" che stable, indicheranno questa etichetta sui moduli. Se tutto è configurato correttamente, durante il deploy della versione canary della nostra mappa dei chart Helm, vedremo che il traffico verrà instradato verso i moduli appena distribuiti. La versione stabile di questo comando apparirà così:

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

Ora verifichiamo il nostro rilascio canary. Per distribuire la versione canary, dobbiamo ricordare due cose. Il nome del rilascio deve differire, in modo da non sovrascrivere l'aggiornamento sulla versione stable attuale. Anche la versione e il tag devono differire, così possiamo distribuire codice diverso e identificare le differenze tramite le etichette delle risorse.

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

Ecco fatto! Se pingi il servizio, puoi vedere che l'aggiornamento canary instrada il traffico solo parte del tempo.

Se stai cercando strumenti per l'automazione del deployment che includano la logica descritta, dai un'occhiata a Deliverybot e su strumenti di automazione Helm su GitHub. I chart Helm utilizzati per implementare il metodo descritto sopra si trovano su GitHub, qui. In generale, questo è stato un riepilogo teorico su come implementare l'automazione del deployment di versioni canary nella pratica, con concetti e esempi specifici.

Fonte: habr.com