De laatste stap van de stage is begonnen. Nu elke applicatie op Kubernetes draait, zou de vertaling naar Helm charts de volgende stap zijn. Ik zal proberen de noodzaak van het gebruik van Helm charts uit te leggen. Helm charts zijn in principe een oplossing om al je Kubernetes onderdelen te vertalen naar templates. Door deze conversie krijg je de mogelijkheid om alle templates te groeperen en te implementeren als een volledige applicatie met een enkele handeling. De templates stellen je ook in staat om meerdere iteraties van een applicatie te implementeren met behulp van variabele bestanden.
In dit voorbeeld kun je zien hoe elke applicatie is opgesplitst in Kubernetes-componenten en gegroepeerd tot een enkele chart. De aanpak van de use case van mijn stage verschilt in het feit dat ik voor elke interne applicatie één Helm chart maak.
Door gebruik te maken van Helm charts is er ook de mogelijkheid om deze te integreren met Jenkins pipelines. De toekomstige configuratie zou kunnen leiden tot nieuw gebouwde applicaties die dan gebruikt worden om automatisch nieuwere versies van de applicaties te deployen op Kubernetes. Deze opzet zou dan gebruikt kunnen worden voor test- en ontwikkelingsdoeleinden. Nu je een klein beetje meer informatie hebt van Helm, zal ik het eigenlijke traject van dit proces uitleggen.
Hoewel ik geen voorkennis had van Helm, was ik wel geïnteresseerd om “het onder de knie te krijgen” zoals we in België zeggen. Helm charts zouden het leven een stuk makkelijker maken, omdat je geen massa aan bestanden in een specifieke volgorde hoeft te implementeren om een werkende versie van je applicatie op Kubernetes te krijgen. Toen ik Helm begon te bestuderen, merkte ik op dat de structuur lijkt op deze van een standaard Kubernetes-deployment, afgezien van het gebruik van variabelen en templates. Het was vrij gemakkelijk en eenvoudig om de Helm-logica te begrijpen. Ik ben begonnen met het omzetten van de rekruteringstool naar een Helm chart. Het eerste probleem dat me opviel was het feit dat de Metabase-component van de rekruteringstool ook gebaseerd is op een Helm chart. Dit zou betekenen dat ik een manier zou moeten bedenken om een Helm chart in een andere Helm chart in te voegen. Gelukkig ondersteunen Helm charts een geneste methode door gebruik te maken van subcharts. Op deze manier zou ik globale variabelen kunnen definiëren die ook door alle andere componenten en de Metabase chart kunnen worden gebruikt. Tot zover goed, nietwaar? Helaas waren sommige details zoals het definiëren van ConfigMaps die gemaakt zijn uit bestanden, niet zo simpel. Standaard worden ze gemaakt via een enkel commando, maar omdat Helm werkt door middel van templating is het noodzakelijk om elke ConfigMap op voorhand te definiëren. Diezelfde ConfigMaps moeten variabelen bevatten wat het niet zo gemakkelijk maakt omdat het Helm values.yaml bestand geen vreemde karakters accepteert. Dit probleem is opgelost door een template te definiëren voor de ConfigMaps die variabelen moeten bevatten. Daarna is het mogelijk om een ConfigMap te definiëren die naar de template verwijst.
Het oplossen van alle kleine problemen leidde uiteindelijk tot een werkende Helm chart voor de rekruteringstool. Met de opgedane ervaring kon ik het grootste deel van het proces herhalen voor de andere applicaties. Uiteindelijk heb ik alle Helm charts afgemaakt terwijl ik wat kleine problemen tegenkwam, maar gelukkig niets serieus. Helaas kan ik de resultaten van de Helm charts niet echt laten zien omdat ze dezelfde applicatie implementeren als de vorige Kubernetes-applicaties.
Met dit alles in het achterhoofd kan ik concluderen dat ik de hoofdtaak van mijn stage heb volbracht. De enige stap die overblijft is het aanpassen van de Jenkins-pipeline om Helm charts op de Kubernetes-cluster in te zetten. Ik sluit mijn blog af met deze laatste prestatie. Deze hele ervaring was echt geweldig en leerzaam. Persoonlijk heb ik veel geleerd van de Kubernetes-wereld en wil ik graag nog meer leren. De voordelen van technologieën zoals Kubernetes en Helm laten zien dat de toekomst van de containertoepassingen hier ligt. Dit alles zou niet mogelijk zijn zonder de hulp van Jan en Bjorn. Mijn beide mentoren stonden altijd klaar om vragen te beantwoorden en te helpen waar nodig. Zelfs de domste vraag zou altijd met een glimlach worden beantwoord. Ik heb ook veel geleerd over hoe je niet alleen in een DevOps-omgeving moet werken, maar ook werk moet leveren dat aan bepaalde kwaliteitsnormen voldoet. Enkele eervolle vermeldingen zijn Paula en Maarten. Ik kon altijd op Paula rekenen voor het proeflezen en corrigeren van mijn rommelige documentatie. Maarten was ook een luisterend oor voor de vele dwaze probleempjes die ik tijdens deze reis tegenkwam, waarvoor ik erg dankbaar ben. Uiteindelijk kan ik alleen maar zeggen dat de mensen achter JIDOKA geweldig zijn en als je toevallig op zoek bent naar een nieuwe uitdaging in je carrière, moet je zeker overwegen om hier te werken.
De laatste onbeantwoorde vraag: ben ik een Kubernetes Hero geworden? Ik weet het niet, dat laat ik aan jou over. Voorlopig denk ik wel dat ik veel over Kubernetes weet, but the sky is still the limit.