Lab 1 Report

Link naar een succesvolle pipeline-run: https://gitlab.stud.atlantis.ugent.be/dvlaminc/devops-project/-/pipelines/77750

Beschrijving van .gitlab-ci.yml structuur: De pipelinestructuur bestaat uit drie stages: maven-build, maven-container-image-generation en run-game. In de eerste stage (maven-build) wordt het Java-project gecompileerd en verpakt met behulp van ./mvnw. In de tweede stage (maven-container-image-generation) wordt op basis van het .jar-bestand een Docker image gemaakt met Jib en naar de Gitlab Container Registry gepusht. Hiervoor heb ik de eclipse-temurin:25-jdk image gebruikt, omdat de JDK de compiler bevat. Tijdens deze stap wist ik eerst niet waar ik de extra variablen (zoals image naam, registry pad,..) moest toevoegen. Daar was ik even mee bezig maar door de documentatie op te zoeken en de variablen in de variables: -sectie van de job te plaatsen. De laatste stage (run-game) voert de game automatisch uit. Nog enkele problemen die ik had, was zoals gezegd het opstellen van de variables, ook nog fouten in de .gitlab-ci.yml file (mijn syntax was fout): In het begin faalde de pipeline doordat er fouten waren in de YAML-indeling. Dit heb ik opgelost door even te stoppen, problemen opzoeken en de Gitlab CI Lint tool te gebruiken.

Antwoorden op de vragen:

1. What is ./mvnw and what is the advantage of using it above mvn? Het is een Maven wrapper script dat bij het project hoort. De wrapper downloadt automatisch de correcte Maven-versie die bij het project past, zo moeten ontwikkelaars Maven niet lokaal installeren. Iedereen werkt met dezelfde versie van Maven, wat samenwerking eenvoudiger maakt. De wrapper wordt alleen binnen het project gebruikt en heeft geen invloed op de rest van het systeem.

2. Explain the key differences between GitLab's cache and artifacts mechanisms. For each of Maven dependencies and build files, explain which mechanism you chose and why. What are the trade-offs of your choices? Gitlab biedt twee mechanismen om bestanden te bewaren tussen jobs: cache en artifacts. Caches kunnen gedeeld worden tussen pipelines en jobs, artifacts blijven binnen één pipeline en worden opgeslagen op de Gitlab server. Toegepast op dit labo kiezen we voor de ~/.m2/repository voor cache omdat het maven dependencies bevat. Dit zorgt ervoor dat we opnieuw compileren zonder alles opnieuw te downloaden met als gevolg een snellere pipeline. voor de target/*.jar bestanden kiezen we artifacts omdat dit nodig is om het buildresultaat door te geven aan de volgende stage die de Docker image bouwt. De trade-offs voor cache zijn dat je snelle builds hebt gedeeld tussen pipelines maar als nadeel dat het vervuild kan raken waarvoor we een cache key nodig hebben. Voor artifacts hebben we een betrouwbare overdracht van build-bestanden, maar wel dat het per pipeline wordt opgeslagen en dat kost veel serverruimte en bandbreedte.

3. In this lab, we use a 25-jre image as the base for our runtime container and a 25-jdk image for the CI/CD build jobs. Explain the reasoning behind this choice. What would be the impact (positive or negative) of using 25-jdk for both? What about using 25-jre for both? Tijdens het builden in CI/CD hebben we de compiler nodig -> JDK. Tijdens runnen in de productie/game is de code al gecompileerd en is JRE voldoende. De JRE image is lichter, sneller en veiliger, omdat overbodige ontwikkeltools excludeert. Als we 25-jdk voor alles gebruiken werkt het wel, maar is de runtime container vele male groter (wegens meer memory/disk), bevat het heel de tijd onnodige tools -> minder veilig, en het zorgt voor langzamere downloads & deploys. En als we 25-jre voor alles gebruiken zullen beide jobs falen, omdat JRE geen compiler bevat. Maven kan dan geen code compileren of testen uitvoeren.