In einem aktuellen Angular.io Projekt stand ich vor dem Problem, die fertige Anwendung auf zwei verschiedene Webserver im lokalen Netzwerk zu verteilen.
Zu Beginn habe existierte nur ein einfaches Script, was per rsync den Datenabgleich vorgenommen hatte Das musste nach jeder Erstellung händisch gestartet werden – mühsam und es konnte auch einmal vergessen werden.
Im Rahmen der Testerstellung und der Nutzung von Gitlab als Versionsverwaltungsplatform, konnten die Mechanismen der CI/CD genutzt werden. So wurde eine Pipeline erstellt die zuerst den Test und das Linting durchführt und anschließend die Release Version erstellt, die dann verteilt werden kann.
Gitlab Runner installieren
Der Gitlab Runner ermöglicht es, die Pipeline auf einem anderen Rechner als den Server zu starten. Das versetzte mich in die Lage, den Kopierprozess zu automatisieren.
Der Einfachheit halber nutzte ich als Basis gleich das Docker-Image von gitlab/gitlab-runner. Zur Konfiguration des Containers erstellte ich ein Dockerfile
FROM gitlab/gitlab-runner
RUN apt update && apt install -y
RUN apt install -y rsync ssh
RUN mkdir /home/gitlab-runner/.ssh && \
chown gitlab-runner:gitlab-runner /home/gitlab-runner/.ssh && \
chmod 700 /home/gitlab-runner/.ssh
COPY --chown=gitlab-runner:gitlab-runner --chmod=600 gitlab-runner-config.key /home/gitlab-runner/.ssh/
COPY config /etc/ssh/ssh_config.d/01-locale.conf
Das Dockerfile installiert noch rsync und ssh und kopiert noch den privaten ssh Schlüssel, sowie die ssh Konfiguration zur Verbindung zu meinen Servern
Wichtig ist außerdem, das die Benutzerrechte des .ssh Verzeichnis richtig gesetzt sind.
Wichtig: Bei der ersten Verbindung fragt ssh nach der Korrektheit des Fingerprints des Servers und speichert diesen in der Datei known_hosts im .ssh Verzeichnis. Das sollte vor der ersten rsync Verbindung bereits erledigt sein.
Und zum einfacheren Start des Containers nutze ich docker-compose
version: '3.9'
services:
gitlab-runner:
build:
context: '.'
dockerfile: Dockerfile
volumes:
- gitlab-runner-config:/etc/gitlab-runner
- '/var/run/docker.sock:/var/run/docker.sock'
container_name: 'gitlab-runner'
volumes:
gitlab-runner-config:
Die docker-compose Datei legt fest die der Container heißen soll und das die Daten auch einem persistenten Volume „gitlab-runner-config“ gespeichert werden.
Mit
docker-compose up -d
wird der Container erst aus dem Image gebaut und dann gestartet.
Gitlab Runner Job anlegen
Auf der Internetseite von Gitlab kann im jeweiligen Repository ein Runner angelegt werden. Im Prinzip erzeugt man ein Token, was als Authentifizierung vom lokalen Prozess zum Server hin dient.
Um den Runner anzulegen wechselt man in die Optionen, weiter zu CI/CD und dort zu Runner. Mit einem Klick auf New project Runner gelangt man in die Konfigurationsseite. Je nach Anforderung kann die Plattform, in der der Runner läuft gewählt werden. Ein wichtiges Detail ist der Tags Eintrag. Damit kann man einem Job aus der Pipeline einem Runner zuordnen.
![](https://seito.de/wp-content/uploads/2023/11/Bildschirmfoto-2023-11-15-um-06.40.47.png)
![](https://seito.de/wp-content/uploads/2023/11/Bildschirmfoto-2023-11-15-um-06.41.28-816x1024.png)
![](https://seito.de/wp-content/uploads/2023/11/Bildschirmfoto-2023-11-15-um-06.43.49-676x1024.png)
![](https://seito.de/wp-content/uploads/2023/11/Bildschirmfoto-2023-11-15-um-06.44.16-1024x817.png)
![](https://seito.de/wp-content/uploads/2023/11/Bildschirmfoto-2023-11-15-um-06.44.45-1024x749.png)
![](https://seito.de/wp-content/uploads/2023/11/Bildschirmfoto-2023-11-15-um-06.45.44-1024x708.png)
Klickt man auf Create runner, wird einem der Token und die Url angezeigt, die man dann auf dem lokalen PC braucht, um einen neuen Runner zu registrieren.
Runner lokal registrieren
Mit den oben angezeigten Daten kann man nun an die lokal laufende Runner-Instanz gehen und den Runner registrieren. Dazu ruft man den oben angelegten gitlab-runner auf. Da ich den Dienst in meinem Fall in einem Docker Container betreibe, sieht der Aufruf wie folgt aus.
docker-compose exec gitlab-runner gitlab-runner --register
Im Terminal werden nun die Url und der Token abgefragt. Danach die Art worin der Job ausgeführt werden soll. In meinem konkreten Fall entscheide ich mich für Shell, da ich keinerlei Übersetzung irgendwelchem Codes durchführen muss, sondern lediglich die Synchronisierung des fertigen Programmes per rsync an die beiden Server erfolgt. Wurde alles korrekt umgesetzt, findet man in dem gitlab-runner Docker Container unter /etc/gitlab-runner/config.toml die Konfiguration. Diese Datei kann auch für spätere Zwecke gespeichert werden.
docker-compose exec gitlab-runner bash
Schreibe einen Kommentar