#import "../Helpers/code-snippets.typ": code

== Gitlab CI/CD
Gitlab Continuous Integration / Continuous Deployment (CI/CD) ermöglicht es uns, automatisch die Container Images für das Backend und Frontend zu bauen und ins K3s zu deployen. Dies stellt sicher, dass unsere Applikation sehr einfach, schnell und konsistent deployt werden kann. Die gesamte Konfiguration für Gitlab CI/CD ist in der Datei `.gitlab-ci.yml` im Root unseres Repos definiert.

Die Pipeline wird nur ausgeführt, wenn entweder die Umgebungsvariable `VERSION_BACKEND` oder `VERSION_FRONTEND` gesetzt ist (oder beide). Somit können Backend und Frontend individuell oder gemeinsam neu deployed werden. Man muss manuell im Gitlab UI die Umgebungsvariable(n) setzen und die Pipeline starten.
#figure(
  image("../Images/02/pipeline.png", width: 100%),
  caption: [ Pipeline starten ]
)
Die Images für das Backend und Frontend werden mit Kaniko gebaut und in die integrierte Gitlab Container Registry unter `registry.gitlab.diller.gl` gepusht. Kaniko benötigt keinen privileged Pod mit Docker-in-Docker, somit ist es die sicherste Methode, um Container Images in einer CI/CD Pipeline zu bauen.

Anschliessend werden die Kubernetes Ressourcen für das Backend, Frontend, HAProxy und Traefik in den Cluster deployed. Die Images werden dabei aus der Auth-geschützten Gitlab Container Registry gepullt, daher muss ein Pull Secret für den Zugriff auf das Registry erstellt werden. Die Umgebungsvariablen `CI_DEPLOY_USER` und `CI_DEPLOY_PASSWORD` mit dem Registry Login haben wir gesetzt, indem wir einen Deploy Token mit dem Namen `gitlab-deploy-token` erstellt haben. Der Token wurde nach dem Least Privilege Prinzip erstellt, er darf nur die Container Registry lesen und sonst nichts.
#figure(
  image("../Images/02/deploytoken.png", width: 100%),
  caption: [ Deploy Token ]
)