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:~#
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.
Kommentare zu diesem Artikel
Schreib einen Kommentar zum Artikel
Vielen Dank für deinen Kommentar! :-)
Da alle Kommentare von Hand bearbeitet werden,
gedulde dich bitte, bis der Kommentar freigeschaltet wird.
Formular nicht richtig ausgefüllt.
Oops... da ist was schiefgelaufen :-(
Dein Kommentar konnte nicht gespeichert werden.
Bitte probier es später nochmal.