Skip to content

Lab 1 Report

Lab 1 Report

Structuur van .gitlab-ci.yml

De pipeline is opgebouwd uit drie opeenvolgende stages:

  1. build

    • Job: maven-build
    • Compileert de code met Maven (./mvnw compile).
    • De Maven-wrapper wordt gebruikt om afhankelijkheid van een lokale Maven-installatie te vermijden.
    • Cache wordt ingesteld op .m2/repository/ om afhankelijkheden herbruikbaar te maken per branch.
    • De gegenereerde target/ folder wordt opgeslagen als artifact (met een bewaartijd van 7 dagen)

  2. package

    • Job: maven-container-image-generation
    • Maakt en pusht automatisch een Docker-container image van de service met behulp van de Quarkus Jib-extensie.
    • Gebruikt GitLab-omgevingsvariabelen ($CI_REGISTRY, $CI_PROJECT_PATH, enz.) om correct naar de GitLab Container Registry te pushen.
    • De image wordt getagd als latest.

  3. execute

    • Job: run-game
    • Draait een spel als integratietest, waarbij de devops-runner gebruikt wordt als image.
    • De logic-service container wordt opgezet als job service en beschikbaar gemaakt via zijn alias logic-service.
    • De runner maakt verbinding met de service via http://logic-service:8080.
    • Het spel wordt gelimiteerd tot 100 beurten met korte wachttijden (25ms), om lange jobs te vermijden.

Problemen en aanpak

Ik heb geen noemenswaardige problemen ondervonden tijdens het opstellen van de .gitlab-ci.yml. De structuur van de pipeline en het gebruik van services en artifacts waren duidelijk te begrijpen dankzij de GitLab-documentatie, de officiële handleidingen van Maven en Quarkus, en AI-hulpmiddelen die hielpen om technische details snel te verduidelijken. Hierdoor kon ik de pipeline correct opzetten zonder grote obstakels.

Vragen

Vraag 1

What is ./mvnw and what is the advantage of using it above mvn?

./mvnw is een Maven-wrapper script dat ervoor zorgt dat een project altijd met een specifieke, vooraf bepaalde versie van Maven wordt gebouwd.

Een aantal voordelen zijn:

  • Er is geen aparte installatie van Maven nodig
  • Het verkleint de kans op versie-gerelateerde fouten (omdat iedereen automatisch dezelfde versie gebruikt)
  • Het is handig in CI/CD-omgevingen, waar Maven anders handmatig geïnstalleerd dient te worden
  • Het verhoogt de consistentie en reproduceerbaarheid van builds tussen verschillende systemen
  • Het is handig als men aan meerdere projecten op een systeem werkt die verschillende Maven-versies gebruiken, omdat er dan niet meerdere versies van Maven op het systeem geïnstalleerd hoeven te worden

Vraag 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?

Cache wordt gebruikt om tijdelijke gegevens, zoals dependencies of build-bestanden, op te slaan zodat ze niet telkens opnieuw gedownload of gegenereerd hoeven te worden. Dit versnelt de opvolgende builds aanzienlijk. Artifacts daarentegen zijn de eind- of tussenproducten van een build die bewaard worden om later in het proces te gebruiken, bijvoorbeeld bij het testen of voor deployment.

Maven dependencies (opgeslagen in de map .m2/repository/) veranderen meestal niet vaak, maar kunnen verschillen per branch. Door deze per branch te cachen, wordt voorkomen dat dependencies bij elke build opnieuw gedownload moeten worden, wat de bouwtijd aanzienlijk verkort. Het gebruik van caching kan echter wel leiden tot een hogere opslagbehoefte en de cache is niet altijd volledig up-to-date.

De map target/ bevat de gecompileerde klassen en build-resultaten die in latere jobs, zoals container-image generatie, opnieuw nodig zijn. Door deze bestanden als artifacts te bewaren, kunnen opvolgende jobs de build-uitvoer hergebruiken zonder opnieuw te moeten compileren. Dit voorkomt dubbele builds en maakt een efficiënte samenwerking tussen jobs binnen dezelfde pipeline mogelijk.

Vraag 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?

JDK (Java Development Kit) bevat alles wat nodig is om Java-code te compileren en bouwen zoals de compiler (javac), debugging tools en een runtime environment terwijl JRE (Java Runtime Environment), zoals de naam al doet vermoeden, enkel de Java Runtime Environment bevat die nodig is om een reeds gecompileerde Java-applicatie uit te voeren. Vandaar wordt als basis-image voor het bouw-proces (dat in de CI/CD pipeline gebeurt) gebruik gemaakt van een JDK-image en voor de runtime container (waar de applicatie reeds gecompileerd is) een JRE-image.

Gebruik van 25-jdk-image voor zowel CI/CD-build jobs als runtime containers

  • Nadelen
    • Grotere imagegrootte => meer overhead bij deployment
    • Bevat onnodige tools in productie => geeft aanleiding tot een groter beveiligingsrisico (grotere blootstelling)
    • Volgt niet de best practice om productiecontainers zo klein mogelijk te houden
  • Voordelen
    • Er dient maar 1 image gebruikt te worden

Gebruik van 25-jre-image voor zowel CI/CD-build jobs als runtime containers

  • Nadelen
    • Er kan geen code gebouwd worden vanuit een JRE, de javac-tool ontbreekt bijvoorbeeld
  • Voordelen
    • Geen: het is niet "minder efficiënt", het is gewoon onbruikbaar voor builds