theHacker's Blog
– It's just a glitch in the Matrix –

GitLab-Runner mit Docker-Executor installieren

In einem vergangenen Artikel habe ich einen GitLab-Runner installiert. Der verwendete Shell-Executor hatte allerdings Schwächen, weil alle Aktionen aus den Jobs direkt auf der Maschine des Executors liefern. Wir konnten z. B. keine Software nachinstallieren, weil der Runner keine Root-Rechte hatte.

Heute zeige ich euch, wie ihr einen Docker-Executor einrichtet, der dann für jeden Job eine eigene Umgebung aufbaut.

Installation

Für die Installation verwende ich einen frischen Server mit 1 GiB RAM und 16 GiB HDD. Da auf diesem Server nur die Jobs ausgeführt werden, erwarte ich keinen hohen Verbrauch. Als Betriebssystem verwende ich Ubuntu 18.04 Server.

Vorsicht: Mit Ubuntu 19.04 hat es nicht funktioniert, da das Repository-Installer-Script das Betriebssystem nicht erkennt. Laut der Tabelle im GitLab-Handbuch wird diese Version auch nicht unterstützt.

Mit apt install docker.io installieren wir Docker. Dieser Schritt ist notwendig, bevor wir den Runner installieren.

Wie beim letzten Mal folgen wir der Anleitung aus dem GitLab-Handbuch:

  • curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash, um die Paketquellen zu installieren
  • Mit apt-get install gitlab-runner den GitLab-Runner installieren

Runner registrieren

Zum Schluss registrieren wir den Runner am GitLab. Hierzu verwenden wir den Befehl gitlab-runner register.

Es müssen nun die folgenden Dinge eingegeben werden:

  • Die URL zum GitLab und das Registrierungstoken. Wir erhalten beide Angaben im GitLab-Adminbereich unter „Übersicht / Runners“ in der Box „Einen shared Runner manuell erstellen“.
  • Danach können wir unserem Runner eine Beschreibung geben.
  • Als Tags vergeben wir docker. Das ist später wichtig, damit wir für bestimmte Jobs diesen Runner anfordern können.
  • Als Executor geben wir nun docker ein.
  • Abschließend werden wir nach einem Standard-Docker-Image gefragt. Ich verwende hier alpine:latest.

Danach ist der Runner fertig eingerichtet und taucht im GitLab in der Runner-Liste auf.

root@docker-gitlab-runner:~# gitlab-runner register
Runtime platform                                    arch=amd64 os=linux pid=19079 revision=a8a019e0 version=12.3.0
Running in system-mode.                            
                                                   
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://gitlab/
Please enter the gitlab-ci token for this runner:
B1R4yA19vpeDqTx1rLjE
Please enter the gitlab-ci description for this runner:
[docker-gitlab-runner]: Docker-Runner
Please enter the gitlab-ci tags for this runner (comma separated):
docker
Registering runner... succeeded                     runner=B1R4yA19
Please enter the executor: custom, parallels, kubernetes, docker-ssh+machine, docker, docker-ssh, shell, ssh, virtualbox, docker+machine:
docker
Please enter the default Docker image (e.g. ruby:2.6):
alpine:latest
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded! 
root@docker-gitlab-runner:~# 
GitLab – Runners

Runner verwenden

Zum Test des Runners verwende ich folgende .gitlab-ci.yml:

stages:
- step1
- step2

say-hello:
  stage: step1
  script: echo "Hello"

install-imagemagick:
  stage: step2
  image: ubuntu:latest
  tags:
  - docker
  script:
  - pwd
  - ls
  - ls /opt
  - whoami
  - hostname
  - apt update >/dev/null 2>/dev/null
  - which convert || echo "not installed"
  - apt install -y imagemagick >/dev/null 2>/dev/null
  - which convert || echo "not installed"

Wir haben wieder einen ersten Step, der nur eine einfache „Hello“-Ausgabe macht. Im zweiten Step sind nun Neuerungen drin. Mit der Zeile image: ubuntu:latest geben wir dem Runner die Information, welches Docker-Image wir als Basis für den Build verwenden wollen. Ich möchte die neueste Ubuntu-Version haben. Mit der Angabe tags identifizieren wir den Runner, den wir für diesen Build-Step brauchen.

Der erste Job läuft wie beim letzten Mal auf dem Shell-Executor. Beim zweiten Job sehen wir nun, dass der neue Docker-Executor verwendet wird. Das angeforderte Image ubuntu:latest wird heruntergeladen und in einem Container ausgeführt. Der Runner checkt unser Projekt im Verzeichnis /builds/test/gitlab-runner aus und führt dann unser Script aus. Die ersten Zeilen des Scripts bestätigen uns die neue Verzeichnisstruktur. Das Verzeichnis /opt ist leer. Wir erinnern uns: Auf dem Shell-Executor sahen wir dort die GitLab-Installation.

whoami zeigt uns, dass wir root sind. hostname gibt uns den Hostname des Docker-Containers, in dem wir den Job ausführen. Wir haben nun eine Umgebung ganz für uns allein und können dort machen, was wir wollen.

Die letzten 4 Zeilen zeigen, dass der Befehl convert zuerst nicht verfügbar ist und dann mit der Installation des Pakets imagemagick verfügbar wird.

14. Oktober 2019

Schreib einen Kommentar hierzu

Deine eMail-Adresse wird nicht veröffentlicht.