Skip to content
Snippets Groups Projects
Code owners
Assign users and groups as approvers for specific file changes. Learn more.

Progressive Delivery met Flagger

flagger-icon

Luc Melleé, oktober 2022 · 5 min read


Progressive delivery is een concept uit de DevOps wereld waarbij je een applicatie geleidelijk uitrold naar de productie omgeving. Deze blogpost gaat over Flagger, een tool voor het implementeren van progressive delivery in een Kubernetes cluster. Want wat kunnen Flagger en/of progressive delivery betekenen voor de deployment van een applicatie in een Kubernetes omgeving?

Om dat te kunnen beantwoorden wordt in de post kort uitgelegd wat progressive delivery is. Daarna wordt Flagger, een tool ontwikkelt door WeaveWorks, uitgelegd en hoe dit zich positioneerd in een Kubernetes omgeving. Daarbij wordt ook uitgezocht wat Canary deployments zijn. Flagger gebruikt dit voor het deployen van nieuwe versies van een applicatie. De tool wordt onderzocht aan de hand van de bieb en lab strategieën uit de HBO-ICT Research Method Pack (Bonestroo et al., 2018).

Maak kennis met Progressive Delivery

Progressive delivery is een deployment strategie voor microservice architecturen. Zowel Sanchez (2019) als DeLaney (2022) zeggen over progressive delivery dat het een geschikte strategie is voor het langzaam uitrollen van nieuwe functionaliteiten en/of wijziginen aan een bestaand systeem.

De manier waarop het werkt is door gebruikers geleidelijk om te leiden naar de nieuwe versie van de software, maar ondertussen de oude versie nog beschikbaar te houden todat iedereen wordt omgeleid naar de nieuwe versie (DeLaney, 2022). Dit kan gedaan worden doormiddel van beta versies of het re-routen van HTTP verkeer.

Hierdoor heeft Progressive Delivery het voordeel dat het makkelijk is om nieuwe features te testen op de productie omgeving zonder dat alle gebruikers hier hinder van kunnen ervaren. Ontwikkelaars kunnen zo gegevens verzamelen over de stabiliteit en bruikbaarheid van de nieuwe feature in een live omgeving (Flagger, z.d.) (Sato, 2014).

Een voorbeeld van progressive delivery zijn de beta versies van WhatsApp. Als je de beta versie installeert, krijg je de nieuwe features eerder dan de andere gebruikers, maar je zit op het zelfde systeem als andere WhatsApp gebruikers waardoor je nog steeds kunt communiceren (Verma, 2022).

De Flagger Architectuur

Flagger is een tool die het mogelijk maakt voor de ontwikkelaar om progressive delivery te implementeren in een microservice architectuur. Dit doet het doormiddel van Canary deployments (Piau, 2021) die later in de blog nog zullen worden behandeld.

Er zijn een aantal alternatieven voor Flagger beschikbaar, zoals bijvoorbeeld Argo Rollouts (Concepts - Argo Rollouts - Kubernetes Progressive Delivery Controller, z.d.). Voor deze blogpost ligt de focus Flagger en zal er verder geen aandacht worden besteed aan Agro Rollouts of dergelijke tools.

In in figuur 1 is te zien hoe Flagger zich positioneert in een Kubernetes omgeving. Flagger beheert het uitrollen van nieuwe deployments op het Kubernetes cluster door een nieuwe pod aan te maken met daarin de nieuwe versie van de software. Daarna vertelt het aan de Ingres Controller om een deel (ongeveer 10%) van het verkeer naar de nieuwe pod te sturen (Flagger, z.d.).

flagger-architecture Figuur 1 - Flagger Overview (Flagger, z.d.)

Ondertussen maakt Flagger gebruik van Prometheus om de metrics van de applicatie te verzamelen. Hiermee wordt het voor ontwikkelaars overzichtelijk hoe de (door Flagger uitgerolde) applicatie zich gedraagt.

GitOps Structuur

Naast de architectuur van Flagger binnen een Kubernetes omgeving, hebben ze het ook mogelijk gemaakt om Flagger te integreren in een GitOps structuur. In figuur 2 is te zien hoe dit eruit ziet. Daarbij moet gebruik worden gemaakt van de GitOps tool Flux, zoals dat gedocumenteerd staat in de GitOps beschrijving van WeaveWorks (z.d.).

In het onderstaande figuur is te zien hoe Flagger zich positioneert in een GitOps structuur.

flagger-gitops Figuur 2 - Flagger GitOps (Flagger, z.d.)

Canary Deployments

Flagger gebruikt onderwater Canary Deployments voor het geleidelijk uitrollen van nieuwe versies van een applicatie (Piau, 2021). Canary is een implementatie van de progressive delivery strategie. De deployments zorgen er, zoals eerder benoemd, voor dat nieuwe versies van het systeem alleen beschikbaar worden gesteld voor een klein deel van de gebruikers (Fernandez, 2020).

De techniek van het geleidelijk beschikbaar stellen van de applicatie wordt ook wel Rolling Deployments genoemd. Canary kent twee verschillende vormen, namelijk canary releases en canary deployments. In het geval van Canary Releases wordt nieuwe software geinstalleerd op een computer van de gebruiker, maar bij Canary Deployment wordt de nieuwe versie van de software geinstalleerd op een server (Fernandez, 2020).

Rolling Deployments

In figuur 3 is te zien hoe het Canary Deployment proces eruit ziet. Dit proces is te vergelijken met wat terug te zien is in de architectuur van Flagger. De applicatie wordt eerst beschikbaar gesteld aan een klein deel van de gebruikers. Daarna wordt er geanalyseerd hoe de applicatie zich gedraagt en of die stabiel genoeg is voor een full-release. Als de applicatie stabiel genoeg is, wordt de applicatie beschikbaar gesteld aan de rest van de gebruikers. In het geval dat dit niet het geval is, wordt de canary deployment teruggedraait.

canary-rolling-deployments Figuur 3 - Canary Deployment Process (Sahoo, 2022)

Deze strategie maakt het voor ontwikkelaars makkelijker om informatie te verzamelen over de stabiliteit van de applicatie. Wanneer het systeem fouten vertoont is het gemakkelijk terug te draaien en breekt de stabiele versie van de applicatie niet voor alle gebruikers (Sahoo, 2022).

Flagger in de praktijk

Om te demonsteren wat Flagger, en daarmee Canary Deployments, in de praktijk kunnen betekenen, zal er een demonstatie worden gegeven. Om dit te kunnen doen zijn er een aantal vereisten nodig (Flagger, z.d.).

Installeren van Flagger op een Kubernetes cluster

Een van de eerste stappen die ondernomen moet worden voor het gebruiken van Flagger is het installeren van een ingress service op het Kubernetes cluster. Dat kan gedaan worden met het volgende commandos:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx

kubectl create ns ingress-nginx

helm upgrade -i ingress-nginx ingress-nginx/ingress-nginx \
--namespace ingress-nginx \
--set controller.metrics.enabled=true \
--set controller.podAnnotations."prometheus\.io/scrape"=true \
--set controller.podAnnotations."prometheus\.io/port"=10254

Met het eerste commando voeg je de nginx ingress image (die gekozen is voor deze demo) toe aan een helm repository. Daarna wordt er een namespace aangemaakt met behulp van het kubectl commando. Het helm upgrade commando (dat overigens uitgevoerd moet worden op één regel) genereerd vervolgens een Kubernetes pod voor de nginx ingress controller. De deployde pod is vervolgens terug te vinden in het Kubernetes cluster.

ingress-pods Figuur 4 - Ingress Controller Pod

Vervolgens moeten Flagger en de Prometheus add-on geinstalleerd worden om applicaties uit te kunnen rollen en om de Canary Deployments te kunnen monitoren. De installatie van Flagger kan gedaan worden met de volgende commandos:

helm repo add flagger https://flagger.app

helm upgrade -i flagger flagger/flagger \
--namespace ingress-nginx \
--set prometheus.install=true \
--set meshProvider=nginx

Na het uitvoeren van deze commandos is ook flagger terug te vinden op het Kubernetes cluster. Zie figuur 5.

flagger-installation Figuur 5 - Flagger pods

De implementatie van een Canary Deployment

Na het installeren van de ingress controller en Flagger op het Kubernetes cluster moet de ingress controller eenmalig gebootstrapped worden (Piau, 2021). Paui (2021) beschrijft in zijn blog ook hoe dit moet en wat het resultaat daar vervolgens van is. Verder heeft ook Flagger een tutorial over het opzetten van hun tool met een NGINX Ingress Controller (NGINX Canary Deployments - Flagger, z.d.). In de blog wordt deze tutorial gevolgt voor het begrijpen hoe Flagger werkt.

Het is nu mogelijk om een nieuwe image te deployen op het cluster met behulp van het Flagger door het volgende commando te gebruiken: kubectl -n <namespace> set image <target_pod> podinfod=<image>.

Wanneer dit commando is uitgevoerd is in de logs van de pod terug te vinden dat flagger heeft gezorgd voor de deployment. De logs van de Canary Deployment zijn op te vragen met behulp van het volgende commando kubectl -n <namespace> describe canary/podinfo. Dit heeft voor deze demo het volgende resultaat terug:

resultaat-pod-watch Figuur 6 - Het resultaat van het pod describe commando.

De geleidelijke rollout van Canary

canary-steps Figuur 7 - De canary rollout stappen in Flagger. (NGINX Canary Deployments - Flagger, z.d.)

In figuur 7 is terug te zien hoe Flagger met behulp van Canary aan de slag gaat met het langzaam uitfaseren van de oude app versie. Daarbij wordt steeds meer traffic omgeleid naar de nieuwe versie van de applicatie, zoals Sahoo (2022) ook verteld dat Canary Deployments werken.

SlackOps met Flagger

Verder heeft Flagger in hun documentatie nog een stuk staan over het implementeren van SlackOps voor de monitoring van de deployment op het cluster. Het is mogelijk om een Slack alerting provider toe te voegen aan de Flagger installatie om zo notifcaties te krijgen in een eigen Slack omgeving. Dit kunnen meldingen zijn over of de deployment geslaagd of geannuleerd is (Alerting - Flagger, z.d.).

Conclusie

Wellicht dat men zich nu afvraagd, wat kan ik nou met Flagger en waarom zou ik het moeten gebruiken? Flagger biedt ontwikkelaars de mogelijkheid om nieuwe versies geleidelijk aan beschikbaar te stellen voor gebruikers. Dit doet het doormiddel van Canary Deployments waarbij men continu de stabiliteit van de nieuwe versie van monitoren. Wanneer een versie al stabiel wordt gemarkeerd kan Flagger ervoor zorgen dat de nieuwe versie van de applicatie beschikbaar wordt gesteld voor alle gebruikers.

Het toepassen van progressive delivery in een deployment omgeving maakt het mogelijk voor ontwikkelaars en bedrijven om software te testen in een zo reëel mogelijke situatie. Daarnaast biedt het de mogelijkheid om geleidelijk versies uit te rollen zonder downtime voor het hele systeem. Daarmee kan de availability van een systeem worden verhoogd.

Bronnen