|
Größe: 1866
Kommentar:
|
← Revision 31 vom 2021-11-05 13:27:31 ⇥
Größe: 5880
Kommentar:
|
| Gelöschter Text ist auf diese Art markiert. | Hinzugefügter Text ist auf diese Art markiert. |
| Zeile 3: | Zeile 3: |
| Passend zu [[Dienste/Gitlab|Gitlab]] bietet der FB3 den zugehörigen CI-Dienst [[https://about.gitlab.com/gitlab-ci/|Gitlab-CI]] unter folgender URL an: | Seit Version 8.0 direkt in [[Dienste/Gitlab|Gitlab]] integriert, bietet der FB3 den zugehörigen [[http://de.wikipedia.org/wiki/Kontinuierliche_Integration|Continuous Integration]] Dienst [[https://about.gitlab.com/gitlab-ci/|Gitlab-CI]] an. |
| Zeile 5: | Zeile 5: |
| [[https://ci.gitlab.informatik.uni-bremen.de/]] | Siehe auch die [[https://gitlab.informatik.uni-bremen.de/help/user/index.md#gitlab-cicd|offizielle Dokumentation]]. |
| Zeile 7: | Zeile 7: |
| Die Anmeldung erfolgt via oAuth über Gitlab, d.h. man meldet sich zuerst bei Gitlab an und klickt dann im Gitlab-CI Interface einfach den "Login with Gitlab". Bei der ersten Anmeldung muss Gitlab-CI authorisiert werden, den Gitlab-Account nutzen zu dürfen. | Bei Fragen oder Problemen mit Gitlab-CI, bitte ein Ticket [[https://gitlab.informatik.uni-bremen.de/fb3t/gitlab/issues|im Gitlab-Projekt]] aufmachen. Damit CI/CD in einem Projekt genutzt werden kann, muss in den Projekteinstellungen unter ''Settings -> General -> Visibility, project features, permissions'' die Option ''CI/CD'' aktiviert werden. |
| Zeile 10: | Zeile 12: |
| == Shared Runner == | == Runner == |
| Zeile 12: | Zeile 14: |
| Auf den Rechnern des Linux-Pool in der E0 des MZH laufen Gitlab-CI-Runner mit den Berechtigungen des lokalen Nutzers {{{gitlab_ci}}} im "shared"-Modus. Um diese nutzen zu können, muss man in den Einstellungen des jeweiligen Gitlab-CI-Projektes die Option {{{Allow run builds on shared runners}}} aktivieren und im Gitlab-Projekt folgenden SSH-Key als Deploy-Key installieren: | Der Gitlab-CI-Server, auch Koordinator genannt, führt selbst keine Builds aus, sonder delegiert dies an sogenannte Runner. Ein Runner ist ein Prozess, der auf einem beliebigen Rechner laufen kann, und den Koordinator pollt, um anstehende Jobs abzuholen und zu bearbeiten. Dabei ist zwischen "Shared"-, "Group-" und "Specific"-Runnern zu unterscheiden. Ein Specific-Runner bedient nur bestimmte Projekte, ein Group-Runner alle Projekte in besimmten Gruppen. Shared-Runner bearbeiten alle Jobs, für die kein Specific-Runner existiert und die für die Nutzung von Shared-Runnern freigeschaltet sind (siehe ''Settings -> CI/CD -> Runners'' in den Projekteinstellungen). |
| Zeile 14: | Zeile 16: |
| {{{ ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCyMfXH0T1b055MlGaPCbdDxlYA/YrE7MmH6V8RXL9KokU5JprfGmfE63MgvymO/rOtGzqC7O9JETgffIz/AlIe8mLGG4mvPA+lYk6txYvMf5pEfFZZAriG3yID6zKigBkDnXfSOQNG7JqJihFVsGAJF9Il53ejlglcjAAGUK6N6841LPk0SlR Rh735oiycdH+8f/jBw63lPbXaDlue6OCDlqtS5Y9cZChCv1Jz0k9qLF4wZQ8IRhXM5MFccK4Qk1Z+i1UcCUuGHIe2EQ69kfDfpHx33y1OcAt/iWB8QvOnptkrx2jMCZTNAWblRV49MNa3unFQosAwlk9rX3oqMfF+qmjlz/9rgJpH7pCrPhklec5r2FzsWMHhMKk8qivve+8RJTGx1BVtmS09Gs r3+pWxGSj6OyxBru7LllTuEsfVHNvWui6yVxIrNWFAXZmn7KaGac4gFv6rYkXrOMGV0hDV4Ped2HpFEoz4fQbtDli2R3kmy+fiqYuuK1zHj+IH2hXrhAN5ESKatZorhRI9MiZvcZXJgIPqg9JYJZiORGmKKLEq5Rc6CXeWfudjf3GlXLxdaQZLJZEU1etT7rxFXbyV7EcyAftr30TXuXlcEZnU8 ZZFt9MEDjN7MGKNUKf36WQ9JVNPynzGX+Is4LB86GSWr7eKr4xo+TB22moiIETc2w== Gitlab-CI-Runner Linux-Pool }}} |
Da nicht immer alle Jobs in allen Umgebungen funktionieren, kann mit Tags gesteuert werden, welche Jobs auf welchen Runnern ausgeführt werden können. Wenn einem Job Tags zugeordnet wurden, wird dieser nur auf einem Runner mit den passenden Tags ausgeführt. Wenn einem Job keine Tags zugeordnet sind, dann wird dieser nur von Runnern ausgeführt, die explizit dafür konfiguriert sind, ungetaggte Jobs zu bedienen. Wenn mehrere Runner für die Ausführung eines Jobs in Frage kommen, wird einer davon per Zufall ausgewählt. |
| Zeile 21: | Zeile 18: |
| Fehlende Pakete für Builds/Tests können auf Anfrage nachinstalliert werden. Dazu kann man einfach eine E-Mail an <<MailTo(service AT informatik DOT uni-bremen DOT de)>> senden. | === Shared-Runner === Der FB3 stellt eine Reihe von Shared-Runnern zur Verfügung: || '''Platform''' || '''Tags''' || '''Hostnamen''' || || Mac OS X || {{{darwin}}} || {{{m{01..06}}}} || || Kubernetes || {{{linux, docker, kubernetes}}} || {{{fb3-k8s-{1..4}}}} || Die MacOS-Runner laufen auf den Pool-Rechnern in der E0 im MZH, wodurch man vor dem Anlegen von Jobs problemlos manuell testen kann, ob die Umgebung den Anforderungen genügt. Der ''Kubernetes''-Runner ist auf einem [[https://de.wikipedia.org/wiki/Kubernetes|Kubernetes]]-Cluster installiert und führt Jobs in [[[https://en.wikipedia.org/wiki/Docker_(software)|Docker]]-Containern aus. Der Kubernetes-Shared-Runner bedient auch ungetaggte Jobs. Fehlende Pakete, die für die Ausführung eines Jobs benötigt werden, können auf Anfrage nachinstalliert werden. Dazu kann man einfach eine E-Mail an <<MailTo(service AT informatik DOT uni-bremen DOT de)>> senden oder ein Ticket im [[https://gitlab.informatik.uni-bremen.de/fb3t/gitlab/issues|Gitlab-Projekt]] aufmachen. Ein Ausschnitt der Liste der verfügbaren Shared-Runner wird im Runners-Tab in der Projektansicht angezeigt. Man kann nur im Nachhinein über das Build-Log feststellen, auf welchem Shared-Runner ein Job ausgeführt wurde. === Specific-Runner === Man kann auch eigene Specific-Runner erstellen, die dann nur die eigenen Projekte bedienen. Der Vorteil ist, dass man die Entwicklungsumgebung individuell anpassen, oder auch einfach eine bestehende Umgebung direkt weiter benutzen kann. Voraussetzung für den Betrieb eines Runners ist, dass dieser den Gitlab-Server erreichen kann. Weitere Informationen zum Erstellen eigener Runner sind in der Projektansicht in Gitlab unter ''Settings -> CI/CD -> Runners'' zu finden. === Sicherheit === (!) Dieser Abschnitt gilt nur für Runner, die den {{{shell}}}-Exektuor nutzen (also bei den angebotenen Shared-Runnern derzeit die Mac OS X Runner). Bei der Benutzung und Einrichtung von Runnern sollten einige Punkte in Hinsicht auf Sicherheit und den Schutz vertraulicher Daten beachtet werden: Jobs sind beliebige Shell-Skripte, die mit den Rechten des Benutzers ausgeführt werden, unter dem der jeweilige Runner-Prozess läuft. Das bedeutet, dass jeder Gitlab-Benutzer, der die entsprechenden Zugriffsrechte auf ein Projekt hat, beliebige Befehle mit den Rechten der Runner ausführen kann, die das jeweilige Projekt bedienen. Gerade beim Einrichten eigener Runner sollte also darauf geachtet werden, dass keine vertraulichen Informationen zugreifbar sind und dass der Runner nicht mehr Rechte auf dem unterliegenden System hat, als er für die Bearbeitung seiner Jobs benötigt. Insbesondere bei Shared-Runnern ist zu beachten, dass dadurch z.B. der private Authentisierungs-Token des Runners ausgelesen werden und dadurch der Runner von einer anderen Maschine imitiert werden könnte. Außerdem ist es möglich, direkt auf den Code der bisher vom jeweiligen Runner bearbeiteten Projekte zuzugreifen, solange diese im Arbeitsverzeichnis des Runners verbleiben. === Docker === Wie oben beschrieben führen die mit {{{linux, docker, kubernetes}}} getaggten Runner ihre Jobs in einem Docker-Container aus. Das Default-Image ist {{{debian:latest}}}, was aber gemäß der [[https://gitlab.informatik.uni-bremen.de/help/ci/docker/using_docker_images.md|offiziellen Dokumentation]] selbst eingestellt werden kann. Abhängigkeiten können im Docker-Image entweder durch die {{{service}}}-Notation oder z.B. durch Aufrufen von {{{apt-get}}} im {{{before_script}}}-Bereich in {{{.gitlab-ci.yml}}} installiert werden. Alternativ können selbst erstelle Docker-Images über die in Gitlab integrierte [[https://gitlab.informatik.uni-bremen.de/help/user/packages/container_registry/index.md|Container-Registry]] genutzt werden. |
Gitlab Continuous Integration
Seit Version 8.0 direkt in Gitlab integriert, bietet der FB3 den zugehörigen Continuous Integration Dienst Gitlab-CI an.
Siehe auch die offizielle Dokumentation.
Bei Fragen oder Problemen mit Gitlab-CI, bitte ein Ticket im Gitlab-Projekt aufmachen.
Damit CI/CD in einem Projekt genutzt werden kann, muss in den Projekteinstellungen unter Settings -> General -> Visibility, project features, permissions die Option CI/CD aktiviert werden.
Runner
Der Gitlab-CI-Server, auch Koordinator genannt, führt selbst keine Builds aus, sonder delegiert dies an sogenannte Runner. Ein Runner ist ein Prozess, der auf einem beliebigen Rechner laufen kann, und den Koordinator pollt, um anstehende Jobs abzuholen und zu bearbeiten. Dabei ist zwischen "Shared"-, "Group-" und "Specific"-Runnern zu unterscheiden. Ein Specific-Runner bedient nur bestimmte Projekte, ein Group-Runner alle Projekte in besimmten Gruppen. Shared-Runner bearbeiten alle Jobs, für die kein Specific-Runner existiert und die für die Nutzung von Shared-Runnern freigeschaltet sind (siehe Settings -> CI/CD -> Runners in den Projekteinstellungen).
Da nicht immer alle Jobs in allen Umgebungen funktionieren, kann mit Tags gesteuert werden, welche Jobs auf welchen Runnern ausgeführt werden können. Wenn einem Job Tags zugeordnet wurden, wird dieser nur auf einem Runner mit den passenden Tags ausgeführt. Wenn einem Job keine Tags zugeordnet sind, dann wird dieser nur von Runnern ausgeführt, die explizit dafür konfiguriert sind, ungetaggte Jobs zu bedienen. Wenn mehrere Runner für die Ausführung eines Jobs in Frage kommen, wird einer davon per Zufall ausgewählt.
Shared-Runner
Der FB3 stellt eine Reihe von Shared-Runnern zur Verfügung:
Platform |
Tags |
Hostnamen |
Mac OS X |
darwin |
m{01..06} |
Kubernetes |
linux, docker, kubernetes |
fb3-k8s-{1..4} |
Die MacOS-Runner laufen auf den Pool-Rechnern in der E0 im MZH, wodurch man vor dem Anlegen von Jobs problemlos manuell testen kann, ob die Umgebung den Anforderungen genügt. Der Kubernetes-Runner ist auf einem Kubernetes-Cluster installiert und führt Jobs in Docker-Containern aus.
Der Kubernetes-Shared-Runner bedient auch ungetaggte Jobs.
Fehlende Pakete, die für die Ausführung eines Jobs benötigt werden, können auf Anfrage nachinstalliert werden. Dazu kann man einfach eine E-Mail an <service AT informatik DOT uni-bremen DOT de> senden oder ein Ticket im Gitlab-Projekt aufmachen.
Ein Ausschnitt der Liste der verfügbaren Shared-Runner wird im Runners-Tab in der Projektansicht angezeigt. Man kann nur im Nachhinein über das Build-Log feststellen, auf welchem Shared-Runner ein Job ausgeführt wurde.
Specific-Runner
Man kann auch eigene Specific-Runner erstellen, die dann nur die eigenen Projekte bedienen. Der Vorteil ist, dass man die Entwicklungsumgebung individuell anpassen, oder auch einfach eine bestehende Umgebung direkt weiter benutzen kann. Voraussetzung für den Betrieb eines Runners ist, dass dieser den Gitlab-Server erreichen kann.
Weitere Informationen zum Erstellen eigener Runner sind in der Projektansicht in Gitlab unter Settings -> CI/CD -> Runners zu finden.
Sicherheit
Dieser Abschnitt gilt nur für Runner, die den shell-Exektuor nutzen (also bei den angebotenen Shared-Runnern derzeit die Mac OS X Runner).
Bei der Benutzung und Einrichtung von Runnern sollten einige Punkte in Hinsicht auf Sicherheit und den Schutz vertraulicher Daten beachtet werden:
Jobs sind beliebige Shell-Skripte, die mit den Rechten des Benutzers ausgeführt werden, unter dem der jeweilige Runner-Prozess läuft. Das bedeutet, dass jeder Gitlab-Benutzer, der die entsprechenden Zugriffsrechte auf ein Projekt hat, beliebige Befehle mit den Rechten der Runner ausführen kann, die das jeweilige Projekt bedienen.
Gerade beim Einrichten eigener Runner sollte also darauf geachtet werden, dass keine vertraulichen Informationen zugreifbar sind und dass der Runner nicht mehr Rechte auf dem unterliegenden System hat, als er für die Bearbeitung seiner Jobs benötigt.
Insbesondere bei Shared-Runnern ist zu beachten, dass dadurch z.B. der private Authentisierungs-Token des Runners ausgelesen werden und dadurch der Runner von einer anderen Maschine imitiert werden könnte. Außerdem ist es möglich, direkt auf den Code der bisher vom jeweiligen Runner bearbeiteten Projekte zuzugreifen, solange diese im Arbeitsverzeichnis des Runners verbleiben.
Docker
Wie oben beschrieben führen die mit linux, docker, kubernetes getaggten Runner ihre Jobs in einem Docker-Container aus. Das Default-Image ist debian:latest, was aber gemäß der offiziellen Dokumentation selbst eingestellt werden kann. Abhängigkeiten können im Docker-Image entweder durch die service-Notation oder z.B. durch Aufrufen von apt-get im before_script-Bereich in .gitlab-ci.yml installiert werden.
Alternativ können selbst erstelle Docker-Images über die in Gitlab integrierte Container-Registry genutzt werden.