Door de eerste applicatie af te ronden had ik er nog twee te gaan. De laatste keer ben ik gestopt met het bijna afmaken van de tweede applicatie. Op het moment van het schrijven van deze blog kan ik bevestigen dat de tweede en de derde applicatie op de Kubernetes Cluster zijn geïmplementeerd en klaar zijn voor gebruik. Dit is dus het einde van de blog. We zijn aan onze laatste loodjes gekomen en hebben er een leuke tijd van gemaakt. Klaar. Het verhaal kan natuurlijk niet zo eindigen, toch? Wees gerust, ik heb nog wat leesvoer voor deze blog.
Ik ben begonnen met het bouwen van een Kubernetes Job voor de MongoDB database die de database zou voeden met wat basislogin-gegevens zodat de app toegankelijk zou zijn na elke clean deployment. Het eerste probleem dat ik had, was het feit dat de MongoDB-dump die gebruikt wordt voor de database nogal groot was. Dit betekende dat ik hem niet zomaar kon koppelen met de Kubernetes Job. Het was zelfs zo groot dat de enige haalbare oplossing voor de Kubernetes Job was om de dump file iedere keer te downloaden alvorens deze te importeren in de MongoDB-database.
Met dit probleem begon mijn zoektocht naar een cloudoplossing die de MongoDB-dump veilig zou kunnen hosten. Na vele pogingen besloten mijn mentor en ik om de Nexus-repository te misbruiken. Maak je geen zorgen, er werden geen binaire repositories beschadigd bij het maken van deze blog.
We hebben besloten om de Nexus Repository te configureren voor het hosten van de dump file die we daarna met een curl-command konden benaderen. Dit lijkt misschien niet de meest optimale oplossing, maar het werkt perfect en soms heb je niet meer nodig dan dat.
De migratie van deze applicatie verliep zonder grote problemen. Ik neem aan dat dit te maken heeft met het feit dat ik al klaar was met de implementatie van de rekruteringstool die de grootste toepassing was van de drie. De kennis die ik had opgedaan met die migratie ging vlot over naar deze. Ik denk dat het tijd is om de tweede applicatie te demonstreren.
Voordat je je afvraagt waarom de velden leeg zijn, ze bevatten persoonsgegevens waarvan ik dacht dat ze niet zonder toestemming gedeeld mochten worden. De werknemersgegevens werden verzameld uit de cv’s die in de applicatie zijn opgeslagen, want dat is het hele punt van de applicatie. Het is een tool die gebruikt wordt om cv’s van medewerkers te verzamelen zodat ze in de toekomst gebruikt kunnen worden om de juiste consultant voor elk project te vinden. De naam van deze applicatie is “cv-app”. Het leuke is dat de cv’s allemaal door een sjabloon worden gemaakt, zodat ze gemakkelijk ontleed en geanalyseerd kunnen worden. De template geeft je ook een mooi uitziend cv. Ik moet toegeven dat de template er zelfs beter uitziet dan mijn cv.
Na het afronden van deze applicatie was ik klaar om aan de volgende te beginnen, omdat de finish al in zicht was. De laatste en derde applicatie bestaat uit drie componenten. Een React-applicatie samen met een Spring boot-applicatie en een Postgresql-database stonden te wachten om wat “Kubernetes magic” te ontvangen. Het eerste obstakel waar ik mee worstelde was een Docker-image bouwen van de React-applicatie. Voorheen hoefde ik alleen maar Docker-images van de Spring boot applicaties te bouwen, wat eenvoudig te realiseren was door gebruik te maken van de Jib-plugin. In dit geval moest ik iets creatiever zijn. Ik nam een kleine glimp op van de Jenkins-pipeline van een vorige Angular-toepassing omdat ik merkte dat dezelfde instructies konden worden gebruikt om de Docker image van de React-toepassing te bouwen. Door deze instructies te kopiëren heb ik een extra BitBucket-branche gemaakt die een andere Jenkins-branch zou maken om de React-applicatie te bouwen en te verpakken naar een Docker-image. Eindelijk, succes. De Jenkins pipeline had een Docker-image van de React-applicatie gebouwd en het werkte foutloos. Op basis van de vorige implementaties heb ik snel de Kubernetes-bestanden voor de laatste applicatie gemaakt en was ik klaar om deze af te ronden.
Stel je een tromgeroffel voor op de achtergrond terwijl ik je het laatste deel van deze reis presenteer.
De laatste applicatie is een stuk software dat de HR-tool wordt genoemd. In een bedrijf als JIDOKA is het belangrijk om je medewerkers te ondersteunen en te helpen. De HR-tool is gemaakt om het gevoel van de werknemer over zijn ervaring op het werk te peilen. Het bevat ook veel mogelijkheden om coachingsessies te organiseren en doelstellingen te bepalen binnen de context van de job. Deze heldere en handige tool verzamelt informatie die van grote waarde is voor de afdeling Human Resources van het bedrijf.
Een belangrijk onderdeel van het project is om alle opgedane kennis ook overdraagbaar te maken aan de medewerkers die verder gaan bouwen aan dit project. Een goede manier om dit mogelijk te maken is documentatie over het project schrijven. Ik ben begonnen met het schrijven van de richtlijnen voor de implementatie van elke applicatie. Een uur later had ik duidelijke en bruikbare instructies die ik kon doorgeven aan mijn mentor. Hij zal deze gebruiken om de applicatie te migreren naar een productieomgeving waar de echte voordelen van Kubernetes worden getest.
Hoewel het lijkt alsof er geen werk meer is, was er toch de mogelijkheid om de Kubernetes-bestanden om te zetten naar Helm charts. Maar daar zal ik in de toekomst meer van onthullen in de posts van deze blog.