Continuous Delivery in Rancher 2.5

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 go http-result een regel tekst laat zien. Via een Ingress kan de Service aangeroepen worden en wordt de regel getoond. Er zijn twee branches, één voor ‘production‘ en één ‘canary‘ versie.

  • Production branch – laat versie 1.0 zien
  • Canary branch – laat versie 2.0 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 2.5 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.

Cluster Explorer

Het nieuwe Rancher dashboard in versie 2.5 heet ‘Cluster Explorer‘ en gebruikers kunnen deze als hun primaire landing-page instellen.

De ‘Cluster Explorer’ ziet er moderner uit dan de ‘Cluster Manager’. Een fraai dashboard met een duidelijk overzicht en één van de standaard menu-opties is ‘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. In mijn geval zijn dat twee clusters, ‘production’ en ‘speeltuin’.

Voor de deployment van de go-app ga ik het zo eeenvoudig mogelijk houden, het doel wordt niet een cluster-groep maar ik ga simpelweg een cluster selecteren om de 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. 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 Groups

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.