Lab 1 Report
Labo 1 Report Jelle Everaet lab1_report.md
https://gitlab.stud.atlantis.ugent.be/jeveraet/devops-project/-/pipelines/77482
Lab 1: Report
CI/CD Pipeline Resultaat
Onderstaande link leidt naar de laatste, en succesvol uitgevoerde CI/CD job die het spel uitvoerde.
https://gitlab.stud.atlantis.ugent.be/jeveraet/devops-project/-/pipelines/77482
Structuur van .gitlab-ci.yml
.gitlab-ci.yml is opgebouwd uit 3 stages: build, package en execute. Deze worden hieronder verder besproken, tezamen met de moeilijkheden die ik onderweg ondervond.
Build Stage
De Build Stage bouwt de applicatie en genereert build artifacts. De Maven dependencies worden gecached zodat ze in volgende stages niet opnieuw gedownload moeten worden, en via de artifacts worden de gebouwd bestanden doorgegeven aan de volgende jobs.
Het moeilijkste deel van deze fase van het opzetten van de CI/CD pipeline vond ik het aanvankelijk begrijpen van wat alles was, zoals de image, de Maven environment variables en de stages. Door gewoon echter de documentatie te lezen en online op te zoeken begreep ik het uiteindelijk.
Package Stage
De tweede stage, of de Package Stage bouwt een Quarkus container image, en pusht deze naar Gitlab. Het maakt gebruik van de Maven dependencies die gecached werden, en de artifacts uit de vorige stage.
De moeilijke aspecten van het opzetten van deze stage waren het correct toekennen van de automatisch gedefinieerde waarden voor de Quarkus environment variables, en dat er in het script -Dquarkus.container-image.build moest gebruikt worden in het commando ./mvnw package. Het eerste was snel opgelost door opnieuw de aangeboden documentatie door te lezen, en het tweede vond ik met behulp van AI.
Execute Stage
De derde en laatste stage, de Execute stage, start het spel met logic-service als job service. Aangezien alles wat de runner nodig heeft, in de docker image en de job service zit, moet deze stage geen gebruik maken van de cache of artifacts.
Het moeilijke hier vond ik vooral het begrijpen van wat een job service is, en waarom er hier geen gebruik gemaak moest worden van de cache en de artifacten.
Verder ondervond ik niet echt concrete problemen waardoor de pipeline niet werkte, de meeste problemen kwamen voort uit het niet begrijpen van wat ik aan het doen was, wat gedurende het lezen van de documentatie opgelost werd.
Vragen
- "What is ./mvnw and what is the advantage of using it above mvn?"
Antwoord:
./mvnw verwijst naar een Maven wrapper script dat uit het project komt. Deze wrapper downloadt een versie van Maven die compatibel is met het uit te voeren project. Dit maakt het voor developpers makkelijker om samen te werken, omdat ze zo automatisch dezelfde versie en configuratie gebruiken, onafhankelijk van je lokale systeem. Het vermijdt ook dat je Maven zelf moet installeren.
- "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?"
Antwoord:
Caches zijn één of meerdere gedownloade files die opgeslagen worden. Deze kunnen gebruikt worden door verschillende pipelines en jobs. Welke cache precies gebruikt wordt, word bepaald door het gebruik van een Cache Key.
Een Artifact wordt opgeslagen op de GitLab server voor een configureerbare duur. Het is beschikbaar doorheen alle stages in een pipeline en kan gedownload worden uit de view.
Omdat caches hergebruikt kunnen worden tussen verschillende pipeline-runs, gebruiken we deze voor de Maven-dependencies.
De build-bestanden die aangemaakt worden in een pipeline worden het liefst steeds doorgegeven naar de volgende stages, dus hier gebruiken we de artifacts voor.
- "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?"
Antwoord:
Bij het gebruik van een 25-jre image, houd je de container die hieruit is gebouwd, klein en veilig, omdat ontwikkeltools en debuggingfunctionaliteiten hieruit ontbreken.
Daarom gebruiken we dus een 25-jre image als de basis voor de runtime container.
Voor CI/CD build jobs is echter de volledige Java Development Kit nodig om de code te compileren. Daarom gebruikt men hiervoor een 25-jdk image.
Een 25-jdk image in production zou leidden tot een onnodig grootte container, me functionaliteiten zoals het debuggen die niet nodig zijn voor de client.
Omgekeerd, een 25-jre image zou niet werken voor de build jobs, omdat dan tools zoals de compiler ontbreken.