Vallen en opstaan

Voor degenen die zich afvragen, de Kubernetes-toepassing is niet gecrasht. Er is geen vooruitgang verloren gegaan met het schrijven van deze blogpost. Deze blog loopt tot nu toe geen gevaar om te sterven, dus ik denk dat het verhaal verder kan gaan.

Vorige week ben ik gestopt met de applicatie die eindelijk vorm begon te krijgen, deze week ga ik aan de slag met enkele laatste stukjes van de puzzel. Een van die stukjes is het dashboard dat je verwelkomt als je de applicatie opstart. Het dashboard wordt aangedreven door Metabase, dit stukje software stelt je in staat om de applicatiegegevens te gebruiken voor het maken van mooie grafieken, meestal gebruikt voor bedrijfsgerelateerde analyses.

Na wat proberen om een eigen Metabase te maken, vond ik een handige kleine tool genaamd Helm. Met Helm kun je gebruik maken van kant-en-klare implementaties genaamd “charts” om je toepassing naar keuze op je Kubernetes-cluster te deployen. In tegenstelling tot mijn implementaties zijn deze charts getest en bewezen te werken door vele professionals en gebruikers van de community. Ik vond al snel een Metabase-chart in de officiële documentatie van Metabase. Hiermee kwam ik tot besef dat ik misschien de officiële documentatie van de software die ik gebruik wel vaker zou moeten bezoeken. 

Het uitproberen van oplossingen die je op het internet vindt, voelt als het bouwen van een Death Star en hopen dat het niet de gebreken van een Death Star bevat.

Na het wijzigen van de standaardconfiguratie die bij de chart werd geleverd, kwam een glorieuze, volledig functionerende implementatie van Metabase tot leven. 

Ik werd een beetje zenuwachtig om het te bekijken. Toch werd ik helaas begroet met een leeg dashboard op de homepage. Ik vloog erin en probeerde wat grafieken te maken, maar toen ik me realiseerde dat ik hier geen ervaring mee heb, kwam mijn zenuwachtigheid al snel tot stilstand. 

Gelukkig kon ik Jordy raadplegen. Jordy is de oorspronkelijke maker van de applicatie die ik probeer te integreren in Kubernetes. In dit verhaal zal hij Bilbo Baggins zijn die de ring aan mij, Frodo Baggins, overhandigt. Alleen zal ik deze keer proberen hem niet te vernietigen.

Met zijn hulp is het ons gelukt om een leuk uitziend dashboard te maken met grafieken en cirkeldiagrammen.. Ik zou graag een foto van dit dashboard laten zien, maar op het moment van het schrijven van deze blog heb ik het misschien wel of niet een beetje verknald.

Maar, ik beloof je nog steeds een cool uitziend dashboard te overhandigen, dus hier is het.

Dit is niet het dashboard van de applicatie zelf, maar het is nog steeds een hele gave, toch? Dit dashboard monitort eigenlijk de Kubernetes-cluster dat we op AWS hebben draaien.

Op dit dashboard kun je het brongebruik van de pods zien, je kunt afwijkingen in het systeem detecteren en het bevat een eventlog om voorkomende fouten op te lossen. Alle credits van dit dashboard gaan naar mijn mentor Bjorn. Met Rancher heeft hij het mogelijk gemaakt om de cluster te monitoren en wat handige informatie te krijgen die makkelijker te begrijpen is voor de gebruikers.

Iets wat ik ben vergeten te vermelden is dat mijn stage voornamelijk uit 2 delen bestaat. Het eerste en belangrijkste deel is het hoofdproject die bestaat uit interne applicaties in Kubernetes te integreren. Het tweede deel bestaat uit een onderzoeksproject waarbij ik moet uitzoeken welke container repository tool ze allemaal zal beheren of welke tool het beste past bij de behoeften van JIDOKA. Een container repository-tool wordt gebruikt om Docker-images op te slaan en te beheren. Voor een bedrijf als JIDOKA is het een belangrijk onderdeel van hun DevOps levenscyclus. Ik heb dus de opdracht gekregen om de beste container repository-tools te vergelijken en uit te zoeken welke tool het meest bruikbaar is voor JIDOKA. Deze week besteed ik wat meer tijd aan deze taak.

De aanpak die ik koos was het creëren van een proof of concept dat een kleine pipeline zou nabootsen waar ik Docker-images kon bouwen en deployen op verschillende container repository tools.

Ik zal je niet lastig vallen met de saaie details, maar om het kort te houden, heb ik een Jenkins pipeline gemaakt die een eenvoudige Spring boot applicatie uit een GitLab repository haalt. Deze applicatie is gebouwd en verpakt in een Docker-image en wordt naar een paar container repository tools gestuurd. Ik ga deze tools gebruiken om alle functies die ze te bieden hebben te vergelijken. De tools die ik ga vergelijken zijn: Nexus, Artifactory, Harbor, Docker Hub, Amazon ECR. De laatste twee zijn meer cloud-gebaseerde tools, maar ze bieden nog steeds een Docker-register oplossing.

Na enige tijd te hebben besteed aan het bouwen van een proof of concept, kon ik eindelijk beginnen met het documenteren van de eerste verschillen en kenmerken tussen de tools. Eerlijk gezegd had ik niet verwacht dat een aantal eenvoudige tools die voornamelijk worden gebruikt voor het opslaan van Docker images, zo’n verscheidenheid aan functies zouden bevatten. Sommigen hebben zelfs een ingebouwde kwetsbaarheidsscan, dit benadrukt nogmaals het belang van security in applicaties. Hopelijk kan ik in de volgende week(en) van dit project zelf wat security gerelateerde taken uitvoeren. Blijf deze bijna interessante blog volgen en misschien kom je erachter of ik dat ook doe.