Continuous Delivery in Rancher

In deze blog beschrijf ik het deployen van applicaties in Rancher versie 2.5>. Maar dit keer via Continuous Delivery. In github heb ik een repository aangemaakt om een docker image op te halen met hierin een eenvoudige go-applicatie die m.b.v. een http-result een regel tekst laat zien. Via een Ingress kan de Service aangeroepen worden en wordt de regel getoond. Er zijn twee branches in git, één voor ‘production‘ en één voor ‘canary‘.

  • Production branch – laat versie 1.1 zien
  • Canary branch – laat versie 1.2 zien

GitOps

GitOps is het process dat automatisch een deployment kan uitvoeren vanuit een git-repository naar een kubernetes cluster. Voor updates aan de applicatie(s) hoeft alleen de git-repository ge-update te worden. In een Push methode zoals hieronder schematisch is weergegeven, zal een trigger in bv. GitLab een pipeline activeren en de deployment uitvoeren richting de gewenste environment..

Push-based Deployments
bron: gitops.tech

In een Pull methode zoals hieronder, zal de operator de repository ophalen en is er aan de kant van de Git(lab) omgeving alleen nog maar een trigger om de registry en/of de repository te updaten. In Rancher zorgt ‘fleet‘ voor het pull proces.

bron: gitops.tech

Fleet

De architectuur van Kubernetes Multi-Cluster Management is ondergebracht in Fleet. Fleet gebruikt zogenaamde ‘Bundles‘ om met ‘selectors‘ een groep clusters te selecteren waarin de deployments worden uitgevoerd en gebruikt daar o.a. Helm en Kustomize voor. Zodra de Bundles naar de clusters zijn ge-deployed wordt de status gemonitored voor ready- en update-status.

bron: rancher.com

In de Gitab branches staat een ‘fleet.yaml‘ welke aangeeft in welke namespace de deployment moet gaan komen en de manifest ‘workload.yaml‘ staat in een manifests directory. Hierin staan de deployment, de service en de ingress gedefinieerd. Er wordt een service aangemaakt die aangeroepen kan worden op poort 8080 met een Ingress die als host ‘http://app.digitalinfo.nl‘ heeft.

Het feit dat er een bestand aanwezig is met de naam ‘fleet.yaml‘ is een trigger voor de fleet-manager om een ‘bundle‘ aan te maken.

Cluster Explorer

Via het dashboard en de ‘hamburger’ optie verschijnen een aantal opties en onder ‘Global Apps‘ vind je ‘Continuous Delivery

Continuous Delivery

Hier zijn de Clusters zichtbaar, de Cluster Groups en de Git Repos. Via Advanced zijn er de Workspaces, Bundels en ClusterRegistrationTokens.

Workspaces

In de Advanced optie vind je ‘Workspaces‘ en in een standaard installatie zijn er twee workspaces aanwezig:

  • fleet-local
  • fleet-default

Fleet-local is voor de local (Rancher) cluster of indien het cluster een single-cluster-style is waarbij de Rancher en downstream cluster hetzelfde is.

Fleet-default is de workspace voor de multi-cluster-style en in mijn geval zijn er twee downstream-clusters, ‘production’ en ‘speeltuin’.

Er kunnen meer workspaces aangemaakt worden om clusters daaraan te ‘assignen’ waardoor deze apart beheerd kunnen worden. Als voorbeeld mijn Raspberry Pi cluster krijgt zijn eigen workspace:

Cluster Groups

Cluster groups kunnen aangemaakt worden om zodoende met fleet een groep clusters te kunnen selecteren waarop de deployment uitgevoerd dient te worden. De cluster dient dan voorzien te zijn van een label, bijvoorbeeld voor de environment:

Git Repos

Voor de deployment van de go-app ga ik het zo eenvoudig mogelijk houden, het doel wordt niet een cluster-groep maar ik ga simpelweg een downstream-cluster selecteren in de ‘fleet-default’ workspace, om een go-app in te deployen.

Via de menu-optie ‘git-repos’ kan met ‘Create’ een repo toegevoegd worden:

De URL voor de repo is https://github.com/NicoOosterwijk/user-bundles en daarin staat go-app dat als Paths ingevuld wordt. Bij ‘Deploy To’ wordt dus de ‘production’ cluster gekozen. Let er ook op dat de ‘Branch name‘ standaard ‘master‘ heet en dit moet nu gewijzigd worden in ‘production‘ voor de production-cluster en in ‘canary‘ voor de speeltuin-cluster.

We maken hier dus twee Git-Repos aan, een met de canary branch voor de speeltuin cluster en een met de production branch voor de production-cluster.

Kies voor ‘Create‘ om dit op te slaan en de Bundles aan te maken zodat fleet dit kan gaan installeren in de clusters. Na enkele minuten zullen de Git Repo’s ‘Active’ zijn.

Daardoor worden de Bundles aangemaakt voor de go-app:

waardoor Fleet zijn werk kan doen en de applicaties zal deployen in de clusters via een Job. Terug naar de ‘Cluster Explorer’ zien we deze inderdaad bij de Deployments staan.

Als test een browser naar ‘http://app.digitalinfo.nl’ en paar maal verversen zal beide versies laten zien.

Cluster Group deploy

Een ander voorbeeld is het automatisch installeren van de monitoring in een cluster aan de hand van een label. Hiervoor maak ik een cluster-group met een label ‘monitoring=enabled’

Op het moment van aanmaken van de cluster-group is er nog geen match met één van de clusters dus de volgende stap is het zetten van een label op één of meerdere clusters. Daar zijn twee manieren voor:

  1. ‘Assign to’ optie op een cluster
  2. Zet een label via de ‘Edit as Form’ op een cluster
optie 1
optie 2

Beide opties hebben hetzelfde effect, de cluster met het label ‘monitoring=enabled’ is toegekend aan de cluster-group ‘monitoring’.

Nu de ‘Git Repo‘ aanmaken waarin een helm-installatie voor monitoring is opgenomen. De git-repo wordt dan toegekend aan de cluster-group ‘monitoring’ en de fleet-agent zal vervolgens monitoring op de cluster instellen.

Let op de ‘Branch Name‘ die bij GitHub standaard ‘main‘ is. Er worden twee ‘Paths‘ toegevoegd, één voor de CRD’s en één voor de deployment.

Zodra de deployment gereed is zal ook deze Git-Repo status ‘Active‘ hebben

Terug in de ‘Cluster Explorer‘ zien we dat Monitoring als menu-item erbij gekomen is en kunnen we Prometheus of Grafana starten vanuit de apps.

Als nu hierna een nieuwe cluster wordt toegevoegd die het label ‘monitoring=enabled‘ heeft, zal monitoring automatisch geïnstalleerd worden op deze nieuwe cluster.