Allgemeine Informationen über Runners

Typen von Runners

GitLab am KIT bietet Projekt-/Gruppen- und Instanz-Runner (shared).

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. In beiden Fällen wird für jeden Auftrag ein eigener temporärer Container erstellt.

Im Falle eines Gruppen-Runners kann der Runner exklusiv für alle Projekte und Untergruppen innerhalb dieser Gruppe verwendet werden.

Anfordern eines Gruppen/Projekt-Runners für das zentrale GitLab

Um einen GitLab-Runner zu verwenden, müssen Sie ein kurzes Formular ausfüllen. Besuchen Sie zuerst IT-support Seite und gehen Sie zur Kundenlogin IT-Surpport Ticket System

Wenn Sie ein neues Ticket öffnen, dann finden Sie in der Text Template ein Antragsformular mit dem Titel "GitLab am KIT: Anfrage zur Bereitstellung von GitLab-Runner".

Sie können Ihr Profil und Ihre Anfrage in diesem Formular ausfüllen. Hier ist ein Beispiel:

• Name: Muster Mann
• E-Mail Adresse: muster.mann@kit.edu

• GitLab Runner werden in der folgenden Ebene eingesetzt (URL): [ https://gitlab.kit.edu/gruppe/projekt ]

• (Optional) Müssen Sie Ihre Jobs/Aufgaben mit mehreren Runners parallelisieren? Wie viele Runners werden in der CI/CD-Pipeline benötigt? (Default: 1 Runner): [x Runners]

• (Optional) Wie lange benötigen Sie GitLab-Runner in Ihrem persönlichen oder Gruppenprojekt (max. 6 Monate): [Dauer 1 Woche/ 3 Monate/ 6 Monate]

Der Runner wird zur Verfügung gestellt, sobald der Bereitstellungsschritt abgeschlossen ist.

Spezifikation des Runners

Jobs/Aufgaben der GitLab-Runner werden in einem Container auf einer Kubernetes-Infrastruktur verarbeiten.

Es gibt mehrere Größen für Runner. Für Projekte und Gruppen wird die Standardgröße verwendet (bei Bedarf kann die Größe oder Anzahl der Runner in Projekten aber angepasst werden). Für Instanz-Runner werden alle Größen benutzt. Die Größen sind folgende:

HINWEIS 🗒: Die Angaben erfolgen im Format „von“ - „bis“. Die untere Zahl im Bereich ist garantiert, die obere Zahl ist die jeweilige Kapazitätsgrenze.

Tags und Verfügbarkeit

Klasse	Tag	Parallelisierbarkeit	Time-out
mini	kgr1-instance-mini	20 (hoch)	1 Stunde
standard	kgr1-instance-standard	20 (hoch)	1 Stunde
extraordinary	kgr1-instance-extraordinary	1 (niedrig)	1 Stunde

Container Größen

	Kerne	Arbeitspeicher (GiB)	Speicher (GiB)
kgr1-instance-mini	0.5 - 0.5	1.6 - 2	11 - 13
kgr1-instance-standard	1 - 1	2.8 - 3.7	16 - 26
kgr1-instance-extraordinary	4 - 6	44 - 45	103 - 112

So nutzen Sie den Runner

HINWEIS 🗒: Dies ist eine kurze Anleitung, wie Sie unsere Runner verwenden können. Weitere Informationen zur Verwendung des GitLab Runners finden Sie in der offiziellen Dokumentation zu Runners.

1. Aktivieren Sie den Runner für Ihr Projekt
   • Dies können Sie in den Projekteinstellungen unter CI/CD -> Runners vornehmen.
2. Erstellen Sie eine CI/CD-Konfiguration mit einer .gitlab-ci.yml-Datei und übernehmen Sie die Änderungen.
3. Der Runner sollte nun Jobs aufnehmen und die Schritte des Runners ausführen.

Auswahl der Linux-Distribution (Optional)

Verwenden Sie die Variable image, um den Runner zu spezifizieren. Wenn Sie dies nicht tun, verwendet der Runner Ubuntu.

Wir empfehlen die folgenden zwei Images:

• ubuntu:latest - Standard-Image, falls kein anderes angegeben wird
• alpine:latest - leichtgewichtiges Linux-Image, das empfohlen wird, wenn Sie mehr Ressourcen für Ihre Builds, Skripte usw. freihalten möchten

Falls diese Images nicht Ihren Anforderungen entsprechen, können Sie auch andere wählen, wie: debian:latest, centos:latest, fedora:latest, archlinux:latest, opensuse/leap:latest...

HINWEIS❗: Nicht jede Version ist möglicherweise verfügbar. Überprüfen Sie dies vorher oder verwenden Sie die angegebene Version oder latest, wenn 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 "eager-blackbear-0"
  tags:
    - "eager-blackbear-0"

  # 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.

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.