@@ -14,9 +14,13 @@ Weitere Informationen und mehr Details mit der aktuellsten Referenz ist immer au
Aktuell haben wir drei Stages definiert. Die Build-, Push- und Deploy-Stage.
- In der Build Stage werden die beiden Jobs zur Erstellung der Docker Images definiert.
Die Images werden danach gezippt und in die Artifacts hochgeladen. Das sollte in der Zukunft eventuell angepasst werden, sodass die Images in die Gitlab Registry gepushed werden. Die Registry funktioniert allerdings noch nicht.
-
- In der Push stage wird zunächst der ssh-agent installiert und konfiguriert, sodass man im script Teil ssh-Befehle ausführen kann. Ohne Weiteres ist dies nämlich nicht möglich, da man ein Passwort für die Verbindung benötigt. Nach der Konfiguration wird dann zuerst das Weblcient Image und dann das Backend Image kopiert. Dann wird noch der aktuellste docker-compose.yml File kopiert und ausgetauscht.
- In der deploy Stage bzw. in deren Job werden dann die zuvor kopierten Images mit dem docker load Befehl zum docker deamon hinzugefügt. Dann wird mit docker-compose up der Weblient und das Backend gestartet
# Manuelles Deployment
# Manuelles Deployment
1. Die Build Jobs er Pipeline starten und über den Dialog der Pipeline die Artifacts herunterladen. Alternativ können die Images auch lokal erstellt werden und mit docker save gespeichert werden.
2. Dann müssen die Images mit docker load in den Docker deamon geladen werden.
3. Abschließend kann alles mit docker-compose gestartet werden.
# Technischer Hintergrund Gitlab-CI-Pipline
Die im .gitlab-ci.yml File festgelegte Konfiguration wird dann an einen sogenannten Runner weitergekeitet. Ein Runner ist eigentlich ein ganz normaler PC (meist jedoch ein Server oder eine VM mit Linux Betriebssystem).
