Runner verstehen

Wer führt die Jobs aus

GitLab selbst führt keine Jobs aus. Es verwaltet nur die Warteschlange. Ein Runner ist ein kleines Programm (gitlab-runner) auf irgendeinem Rechner, das GitLab regelmässig fragt: «Hast du Arbeit für mich?» Bekommt es einen Job, führt es ihn aus und schickt Log und Ergebnis zurück.

sequenceDiagram
    participant R as Runner (VM)
    participant G as GitLab
    participant D as Docker
    R->>G: Gibt es einen Job?
    G-->>R: Job «build», Image node:24-alpine
    R->>D: Container starten, Repo klonen
    D-->>R: Log, Exit-Code, Artefakte
    R->>G: Ergebnis hochladen

Wichtig für die Firewall: Die Verbindung geht vom Runner zu GitLab, nie umgekehrt. Die Runner-VM braucht nur ausgehendes HTTPS, keinen offenen Port.

Drei Reichweiten

Art	Wer darf ihn nutzen	Wer legt ihn an
Shared Runner	Alle Projekte der GitLab-Instanz	Die Administratoren der Instanz
Group Runner	Alle Projekte einer Gruppe	Owner der Gruppe
Project Runner	Ein Projekt	Maintainer des Projekts

Auf gitlab.ethz.ch gibt es keine Shared Runner. Darum hat die Kursgruppe einen Group Runner: einmal eingerichtet, läuft er für jedes Projekt in der Gruppe, auch für deines. Ein Project Runner hätte nur der Lernplattform geholfen.

Woran du es erkennst

Pipeline «pending» oder «stuck», und im Job steht: «This job is stuck because the project doesn’t have any runners online assigned to it.» Unter Settings → CI/CD → Runners siehst du, welche Runner dem Projekt zur Verfügung stehen und ob sie online (grüner Punkt) sind.

Executor

Der Runner kann Jobs auf verschiedene Arten ausführen, das ist der Executor:

• shell: direkt auf der VM, mit dem, was dort installiert ist. Einfach, aber jeder Job hinterlässt Spuren, und ein rm -rf im Script trifft die VM.
• docker: pro Job ein frischer Container aus dem image des Jobs. Sauber, reproduzierbar, Standard.
• kubernetes, virtualbox und andere für grössere Umgebungen.

Diese Plattform nutzt den Docker-Executor. Das ist der Grund, warum jeder Job ein image hat und warum apk add im Deploy-Job nötig ist: Der Container weiss nichts von der VM.

Was auf der VM landet

Beim ersten Lauf einer Pipeline zieht Docker die Images: koalaman/shellcheck-alpine, node:24-alpine, alpine:3.21. Das dauert, danach sind sie lokal. Der npm-Cache aus Modul 6 liegt ebenfalls auf der Runner-VM. Darum braucht sie Plattenplatz, 40 GB sind komfortabel, und Docker sollte gelegentlich aufräumen (docker system prune).

Vertrauen

Ein Runner führt aus, was in .gitlab-ci.yml steht, von wem auch immer der Push kommt. Ein Group Runner führt also Jobs aller Projekte der Gruppe aus. Für eine Kursgruppe mit bekannten Mitgliedern ist das in Ordnung. Für eine Gruppe, in die Fremde pushen können, nicht.

Selbstcheck · 3 Fragen

1. In welche Richtung geht die Verbindung zwischen Runner und GitLab?

GitLab verbindet sich zum RunnerDer Runner verbindet sich zu GitLabBeide Richtungen

Darum braucht die Runner-VM keinen offenen Port.

2. Warum ein Group Runner statt eines Project Runners?

Er ist schnellerEr steht allen Projekten der Gruppe zur VerfügungProject Runner gibt es nicht mehr

3. Was unterscheidet den Docker-Executor vom Shell-Executor?

Docker ist langsamerJeder Job läuft in einem frischen Container statt direkt auf der VMShell kann keine Artefakte

Antworten prüfen