Continuous Integration – Automatisierung mit Gitlab

Im Testlabor

Gitlab als Alternative zu Github oder Bitbucket ist insbesondere bei Selbst-Hostern beliebt. Es bietet üppige Funktionen für das Projektmanagement, angefangen bei Repositories über Issue-Tracking, Wikis bis hin zu Continuous Integration – CI. Dieser Artikel beschreibt die CI-Möglichkeiten von Gitlab für ein Beispiel-Projekt und zeigt darüber hinaus, wie Sie diese auch zur vereinfachten Administration von Linux-Servern nutzen können.
Sich wiederholende Aufgaben sind mühselig und fehleranfällig, wenn sie von Hand ausgeführt werden. Im August befasst sich IT-Administrator deshalb mit dem ... (mehr)

Seit Version 8.0 ist Continuous Integration fester Bestandteil von Gitlab. Per Default steht es seitdem in allen Projekten zur Verfügung. Hinter dem Begriff verbirgt sich die Ausführung beliebiger Kommandos auf einem dafür bereitgestellten Server. Da die Ausführung zumeist nicht zeitkritisch ist, eignet sich dafür auch ein ausrangierter Arbeitsplatzrechner, der andernfalls seinen Dienst als Staubfänger im Lagerraum verrichten würde. Ausgestattet mit einem handelsüblichen Linux-System müssen anschließend nur noch die Gitlab-Runner-Software und fehlende Abhängigkeiten für die entsprechenden Projekte installiert werden.

Gitlab vorbereiten

Wenn Sie nicht über eine laufende Instanz von Gitlab verfügen oder diese nicht zum Experimentieren verwenden wollen, bietet sich an, das auf Ubuntu basierende Docker-Image der Community-Edition [1] zu verwenden. Damit setzen Sie in kurzer Zeit eine laufende Gitlab-Instanz auf ihrem Rechner auf, ohne diese umständlich konfigurieren zu müssen. Installieren Sie dafür Docker in der aktuellen Version, für unsere Tests benutzen wir Version 17.03.1. Soll es sich nur um eine Testinstanz handeln, brauchen sie die erzeugten Daten gar nicht außerhalb des Containers lagern und starten diesen einfach mit dem folgenden Befehl und überprüfen anschließend den Status des Containers:

$ docker run --name gitlab -d --expose 80:80 gitlab/gitlab-ce:latest
$ docker ps

Solange der Status ("health: starting") lautet, wird Gitlab vorbereitet. Anschließend können Sie unter seiner Docker-IP-Adresse die Webseite öffnen. Die IP-Adresse herauszufinden ist leider nicht so einfach, weil weder »ip« noch »ifconfig« in dem Docker-Container installiert ist. Führen Sie den folgenden Befehl aus, der alle IP-Adressen des Containers direkt aus dem "/proc"-Dateisystem anzeigt:

$ docker exec -ti gitlab /bin/cat/proc/net/fib_trie | awk '/32 host/{print f}{f=$2}'

Setzen Sie nun in der Weboberfläche das Benutzerpasswort für den Benutzer "root" und melden Sie sich anschließend an. In der Übersicht wählen Sie "New Project" und erstellen ein neues Projekt. Zur Ausführung der Befehle für die Continuous Integration benötigen Sie noch den sogenannten Runner. Haben Sie alles aufgesetzt und auch das Beispielprojekt erfolgreich angelegt, erhalten Sie Zugriff auf die projektspezifische Webseite von Gitlab. Unter "Settings / CI/CD Pipelines" erhalten Sie eine Übersicht der existierenden Runner und können dort auch neue anlegen.

Gitlab-Runner einrichten

Ein Runner führt die in einem Repository hinterlegten Kommandos aus. Der Erfolg eines Runs wird über den Rückgabewert der ausgeführten Kommandos bestimmt. Die von Gitlab bereitgestellte Runner-Software erlaubt unterschiedliche Setups. Für den Runner können Sie direkt ihr Testsystem, eine beliebige virtuelle Maschine oder wieder den bereitgestellten Docker-Container [2] verwenden. Am einfachsten ist es auch hier wieder, auf den vorbereiteten Docker-Container zurückzugreifen. Diesen starten Sie mit dem folgenden Befehl und beginnen die Registrierung beim soeben aufgesetzten Gitlab-Server:

$ docker run --name gitlab-runner -d gitlab/gitlab-runner:latest
$ docker exec -ti gitlab-runner gitlab-runner register

Zur Registrierung des Runners geben Sie die auf der Webseite angegebene URL sowie das Registrierungs-Token ein. Suchen Sie sich einen Namen zur Identifikation des Runners aus. In unserem Beispiel nennen wir ihn "Test-Runner".

Tags erlauben die Nutzung spezifischer Runner für einzelne Aufgaben. Angenommen Sie testen Software sowohl mit MySQL als auch mit PostgreSQL, können Sie zwei Runner mit jeweiligen Tags zur Verfügung stellen. Dort ist dann das Datenbank-Managementsystem bereits vorbereitet und Sie brauchen sich nicht weiter kümmern. Ebenso lassen sich Runner mit unterschiedlichen Betriebssystemen verwenden. In Vorbereitung für unser erstes Beispiel vergeben wir die Tags "gcc" und "gtest". Da wir den Runner auch für unser zweites Beispiel noch nutzen können, erlauben wir auch das Ausführen von nicht-getaggten Jobs und binden den Runner auch nicht fest an unser Test-Projekt.

Bild 1: URL und Runner-Token für die Konfiguration.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Loadtests ohne Server

Für Loadtests der eigenen Server bietet sich die Cloud an, denn kurz getaktet lassen sich dort viele Rechnerinstanzen starten, die das eigene Budget nur wenig belasten. Noch flexibler, günstiger und besser skalierbar sind Tests mit einer Serverless-Infrastruktur wie AWS Lambda. Wir führen vor, wie Sie dort mit Serverless Artillery eigene Loadtests starten. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018