GitLab Runner

Schnellstart 🚀

Neu bei Runnern? Du kannst CI/CD in GitLab verwenden, indem du folgende Schritte befolgst:

Du benötigst eine .gitlab-ci.yml-Datei in deinem Repository und musst einen Runner aktivieren.
Um die Datei zu erstellen, gehe wie folgt vor: Dein-Repository → Build → Pipeline-Editor → Pipeline konfigurieren → Änderungen übernehmen
Wenn die Pipeline läuft – hurra! Falls nicht, gehe zu Einstellungen → CI/CD → Runner und überprüfe, ob Instanz-Runner für dieses Projekt aktivieren eingeschaltet ist.
Für weitere Informationen siehe die offizielle GitLab-Dokumentation sowie diese Dokumentation zur spezifischen Konfiguration am KIT.

Einführung

GitLab Runner arbeiten mit GitLab CI/CD zusammen, um Jobs in einer Pipeline auszuführen. Ein Runner ist ein Prozess, der auf jedem Computer laufen und ausstehende Aufgaben verarbeiten kann. Es muss zwischen "Shared-", „Gruppen-“ und „Projekt-Runnern" unterschieden werden. Ein Project-Runner dient nur für bestimmte Projekte, ein Gruppenrunner ist ausschließlich für die Verarbeitung von Aufgaben zuständig, die mit Projekten in einer Gruppe verknüpft sind. Gemeinsam genutzte Runner ("Shared") stehen allen Gruppen und Projekten in einer GitLab-Instanz zur Verfügung. Den verfügbaren Runner-Typ finden Sie in den Projekteinstellungen Settings -> CI/CD -> Runners.

BITTE BEACHTEN ⚠️: Die Runner wurden bereits mit allen geplanten Funktionen veröffentlicht. Sie werden ohne Versionsnummern aktualisiert. Obwohl die Persistenz der Einstellungen eine hohe Priorität bei den Änderungen hat, wird der Runner-Dienst weiterhin entwickelt, gewartet und ausgebaut.

Typen von KIT Runners

Instanz-Runner (shared)
Projekt-/Gruppen Runner

Die Projekt- und Gruppen-Runner im KIT bedienen Jobs für jeweils eine Gruppe oder ein Projekt. Instanz-Runner hingegen werden mit allen geteilt (shared) und sind generell für alle Projekte verfügbar. Im Falle eines Gruppen-Runners kann der Runner exklusiv für alle Projekte und Untergruppen innerhalb dieser Gruppe verwendet werden.

Spezifikation des Runners

Der GitLab-Runner ist auf einem Kubernetes-Tanzu-Cluster in der VMware-Infrastruktur installiert und bereit, Jobs/Aufgaben in einem Container auszuführen.

Verfügbar Runners Überblick

Parametererklärung ℹ️

Wenn Größen im Format untere - obere angegeben sind – die untere Größe im Bereich ist garantiert und die obere Zahl stellt das Ressourcenlimit dar.

Begriffserklärungen:

Parallelität (Concurrency): Wie viele Jobs dieser Runner gleichzeitig ausführen kann (immer in getrennten Umgebungen pro Benutzer/Projekt/Job)
Timeout: Maximale Dauer eines Jobs
Kerne (Cores): Verfügbare CPU-Kerne des Runners für einen Job
Arbeitsspeicher (Memory): Verfügbarer Arbeitsspeicher des Runners für einen Job in GiB
Festplatte (Disk): Verfügbarer Speicherplatz des Runners für einen Job in GiB

HINWEIS 🗒️: Parallelisierbarkeit und sofortige Verfügbarkeit können nicht garantiert werden. Wie viele Runner tatsächlich für dich gleichzeitig laufen, hängt von vielen Faktoren ab – z. B. Auslastung durch andere Nutzer, Entscheidungen der Workload- und Jobplanungsalgorithmen usw.

KGR1

Platform: Kubernetes
Timeout: 1 hour

Name/Tag	Parallelität	Kerne	Arbeitspeicher	Speicher
`kgr1-instance-mini`	20 (hoch)	0.5 - 0.5	1.6 - 2	4 - 13
`kgr1-instance-standard`	16 (hoch)	1 - 1	2.8 - 3.7	10 - 26
`kgr1-instance-experimental`	(mittler)	~ 1	~ 3 - 4	~ 20
`kgr1-instance-extraordinary`	1 (niedrig)	4 - 6	44 - 45	44 - 92

EXPERIMENTELL – EDGE-RUNNER-VERSION ⚠️: Du kannst auch den experimentellen Runner frei verwenden. Er basiert auf dem Aufbau des Standard-Runners. Du kannst also eine ähnliche Spezifikation erwarten, allerdings mit experimenteller Konfiguration/Funktionalität. Da die Spezifikation dieses Runners nicht stabil ist, wird sie nicht so umfassend dokumentiert.

KGR2

Platform: Docker
Timeout: 1 Stunde

Name/Tag	Parallelität	Kerne	Arbeitspeicher	Speicher
`kgr2-instance-hugedisk`	1 (niedrig)	0.5 - 0.5	1.6 - 2	4 - 13

KGR3

Platform: Kubernetes
Timeout: 1 Stunde

Name/tag	Concurrency	Cores	Memory	Disk
`kgr3-instance-standard`	4 (mittler)	1 - 1	2.8 - 3.7	10 - 26

Betriebssystem – Auswahl der Linux-Distribution

WICHTIG 🗒️: Wir unterstützen ausschließlich Linux.

Verwende die Variable image, um das Image des Runners festzulegen. Wenn du nichts angibst, wird standardmäßig Ubuntu verwendet.

Wir empfehlen folgende zwei Images:

ubuntu:latest – Standard-Image, wenn nichts anderes angegeben ist
alpine:latest – leichtgewichtiges Linux-Image, empfohlen, wenn du mehr Ressourcen für Builds, Skripte usw. freihalten möchtest

Falls diese Images nicht deinen Anforderungen entsprechen, kannst du auch andere verwenden, z. B.:
debian:latest, centos:latest, fedora:latest, archlinux:latest, opensuse/leap:latest ...

HINWEIS 🗒️: Nicht jede Version ist zwangsläufig verfügbar. Prüfe dies im Voraus oder verwende eine angegebene Version bzw. latest, sofern verfügbar.

Beispiele für eine CI/CD-Konfigurationsdateien

Beispiel für .gitlab-ci.yml - Hallo Welt

hello_world:
  # Verwendung des getaggten Runners mit dem Tag "kgr1-instance-standard"
  tags:
    - "kgr1-instance-standard"

  # Angabe der Stage
  # (Die häufigsten Stages und Reihenfolge sind build->test->deploy)
  stage: build

  # Wenn kein Image spezifiziert ist, wird das Standard-Image verwendet
  # Standard: image: "gitlab/gitlab-runner:ubuntu"

  # Angabe der Befehle, die vom Runner ausgeführt werden sollen
  script:
    - echo "Hello world"

Beispiel für .gitlab-ci.yml - Erweiterung

build_the_script:
  tags:
    - "eager-blackbear-0"
  stage: build
  image: "gitlab/gitlab-runner:ubuntu"

  script:
    - echo "print(42)" > get_answer.py 

  # Verwendung von Artifacts, um das Skript zur nächsten Stage zu übergeben
  artifacts:
    paths:
      - get_answer.py


test_the_script:
  tags:
    - "eager-blackbear-0"
  stage: test
  image: "gitlab/gitlab-runner:ubuntu"

  script:
    - apt update
    - apt install python3 -y
    - if [ "$(python3 get_answer.py)" == "42" ]; then echo 'Antwort ist korrekt'; else echo 'Antwort ist NICHT korrekt'; fi

Runner mit einem bestimmten Tag

Mithilfe eines Tags wird gesteuert, welche Jobs auf welchen Runners und für welche Gruppe oder welches Projekt ausgeführt werden können. Wenn einem Job Tags zugewiesen wurden, wird er nur auf einem Runner mit den entsprechenden Tags ausgeführt.

In der Datei .gitlab-ci.yml können Sie den CI/CD-Variablen mit einen Tag für die dynamische Runner-Auswahl verwenden.

    variables:
      KIT_KUBERNETES_RUNNER: kit-öjwenadnh64$s82gowß3urhnßü1nvwß1nvsa

      job:
        tags:
          - docker
          - $KIT_KUBERNETES_RUNNER
        script:
          - echo "Hallo Runner wird verfügbar"

KIT Runner-Tag

Geben Sie das Tag des Runners in der tags-Sequenz an, wenn Sie den zu verwendenden Runner spezifizieren möchten (mehr dazu im folgenden Abschnitt):

tags:
  - "eager-blackbear-0"

Variablen

Sensible Variablen wie Token oder Passwörter sollten in den Einstellungen der Benutzeroberfläche gespeichert werden, vorzugsweise nicht in der Datei .gitlab-ci.yml. CI/CD-Variablen können auf der UI in diesem Abschnitt Settings -> CI/CD -> Variables definiert werden.

alt text

Sicherheit

Bei der Einrichtung von Runnern sollten einige Punkte in Hinsicht auf Sicherheit und den Schutz vertraulicher Daten beachtet werden. Jeder Benutzer, der Zugriffsrechte auf das Projekt hat, kann beliebige nicht überprüfte Befehle ausführen. Wenn Sie Ihren Runner einrichten, müssen Sie sicherstellen, dass keine vertraulichen Informationen für unbefugte Benutzer zugänglich sind. Insbesondere bei der Verwendung von Shared-Runnern ist zu beachten, dass das private Authentifizierungstoken des Runners lesbar sind und der Runner von einer anderen Maschine nachgeahmt werden könnte.

Rate-Limit

Um eine kontinuierliche Bereitstellung für alle Nutzendenden, Projekte und Gruppen zu gewährleisten, kann jedes Projekt maximal 5 Pipelines pro Minuten neu starten. Sollte dies in Ihrem Fall nicht ausreichen, schreiben Sie uns bitte ein Ticket mit einer kurzen Erklärung, warum in ihrem Projekt mehr gleichzeitige Pipelines aktiv sein müssen.

Besondere Bedürfnisse

Wenn Sie spezielle Bedürfnisse für einen Runner mit einem guten Grund haben, können Sie uns mit einem Ticket kontaktieren und Ihre Anforderung beschreiben.