Größe: 1117
Kommentar:
|
Größe: 3909
Kommentar:
|
Gelöschter Text ist auf diese Art markiert. | Hinzugefügter Text ist auf diese Art markiert. |
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"-Button. Bei der ersten Anmeldung muss Gitlab-CI authorisiert werden, den Gitlab-Account nutzen zu dürfen. | 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"-Button. Bei der ersten Anmeldung muss Gitlab-CI autorisiert werden, den Gitlab-Account nutzen zu dürfen. In Gitlab bestehende Projekte können per Knopfdruck in Gitlab-CI eingebunden werden. Siehe auch die [[http://doc.gitlab.com/ci/|offizielle Dokumentation]]. == Runner == Runner sind Prozesse, die die Builds/Tests (sog. Jobs) ausführen. Dabei ist zwischen "Shared"- und "Specific"-Runnern zu unterscheiden. Ein Specific-Runner bedient nur bestimmte Projekte, während Shared-Runner alle Jobs abarbeiten, für die kein Specific-Runner existiert und für die Nutzung von Shared-Runnern freigeschaltet sind (siehe die Option "{{{Allow shared runners}}}" in den Gitlab-CI-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 Runnern ausgeführt Wenn für einen Job keine Tags definiert sind, wird jeweils ein zufälliger Runner benutzt. === Shared-Runner === Der FB3 stellt eine Reihe von "Shared"-Runnern zur Verfügung: || '''Platform''' || '''Tags''' || '''Hostnamen''' || || Debian Wheezy || {{{linux}}} || {{{x{01..25}}}} || || Mac OS X || {{{darwin}}} || {{{a{01..20}}}} || || Smartos/Illumos|| {{{sunos}}} || {{{gitlab-ci-runner-sunos-1}}} || 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. Shared-Runner kann man sich über das Gitlab-CI-Interface nicht auflisten lassen und werden auch nicht 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-CI-Server im Netzwerk erreichen kann. Weitere Informationen zum Erstellen eigener Runner sind im Runners-Tab in der Projektansicht in Gitlab-CI zu finden. |
Zeile 10: | Zeile 39: |
== Shared Runner == | == Sicherheit == |
Zeile 12: | Zeile 41: |
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 den Deploy-Key "{{{Gitlab CI Linux-Pool Runner}}}" einbinden. | Bei der Benutzung und Einrichtung von Runnern sollten einige Punkte in Hinsicht auf Sicherheit und den Schutz vertraulicher Daten beachtet werden: |
Zeile 14: | Zeile 43: |
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. | Jobs sind als beliebige Shell-Skripte definiert, 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. |
Gitlab Continuous Integration
Passend zu Gitlab bietet der FB3 den zugehörigen CI-Dienst Gitlab-CI unter folgender URL an:
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"-Button. Bei der ersten Anmeldung muss Gitlab-CI autorisiert werden, den Gitlab-Account nutzen zu dürfen.
In Gitlab bestehende Projekte können per Knopfdruck in Gitlab-CI eingebunden werden.
Siehe auch die offizielle Dokumentation.
Runner
Runner sind Prozesse, die die Builds/Tests (sog. Jobs) ausführen. Dabei ist zwischen "Shared"- und "Specific"-Runnern zu unterscheiden. Ein Specific-Runner bedient nur bestimmte Projekte, während Shared-Runner alle Jobs abarbeiten, für die kein Specific-Runner existiert und für die Nutzung von Shared-Runnern freigeschaltet sind (siehe die Option "Allow shared runners" in den Gitlab-CI-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 Runnern ausgeführt Wenn für einen Job keine Tags definiert sind, wird jeweils ein zufälliger Runner benutzt.
Shared-Runner
Der FB3 stellt eine Reihe von "Shared"-Runnern zur Verfügung:
Platform |
Tags |
Hostnamen |
Debian Wheezy |
linux |
x{01..25} |
Mac OS X |
darwin |
a{01..20} |
Smartos/Illumos |
sunos |
gitlab-ci-runner-sunos-1 |
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.
Shared-Runner kann man sich über das Gitlab-CI-Interface nicht auflisten lassen und werden auch nicht 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-CI-Server im Netzwerk erreichen kann.
Weitere Informationen zum Erstellen eigener Runner sind im Runners-Tab in der Projektansicht in Gitlab-CI zu finden.
Sicherheit
Bei der Benutzung und Einrichtung von Runnern sollten einige Punkte in Hinsicht auf Sicherheit und den Schutz vertraulicher Daten beachtet werden:
Jobs sind als beliebige Shell-Skripte definiert, 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.