Dem GitLab-Runner auf der Spur

Mit GitLabs CI/CD-Pipelines lassen sich Projekte sehr komfortabel bauen und deployen. Dass die Beschreibung der Pipelines als Teil des Projektes automatisch unter Versionskontrolle steht, ist sehr praktisch. Pipelines werden über die Config-Datei „.gitlab-ci.yml“ im Rootverzeichnis des Git-Repositorys definiert.

Im konkreten Fall wollte ich eine Pipeline für das auch schon unter Monitoring einer Scala-Anwendung mit Icinga2 auffällig gewordene Projekt konfigurieren. Die Pipeline sollte die Anwendung bauen, dockern und auf einem Remote-Server deployen. Praktischer Weise gab es in unserem GitLab bereits einen Runner, der laut seiner Tagliste mit „sbt, shell, hosted“ genau die relevanten Fähigkeiten mitbrachte. Der Runner hörte auf den für mich kryptischen Namen „bdp“. Aber das störte mich erstmal nicht weiter.

Das Scala Build Tool sbt lief problemlos, so dass das Docker-Image per sbt:docker-publish schnell gebaut und in die Docker-Registry gepusht war.
Auch die Shell tat was sie sollte, brach dann aber leider beim Versuch per ssh auf den Remote-Server zuzugreifen mit dem Fehler „Host key verification failed.“ ab.

runner_build_failed

Kein Problem, dazu braucht man ja normaler Weise nur per „ssh-copy-id user@remote-server“ den Public-Key des users, der die Verbindung aufbaut, auf den Remote-Server zu kopieren.

Nach einiger Suche, wurde mir klar, dass der Runner nicht auf dem GitLab-Server lief. Wo war mir aber unklar.

Sag mir, wo du läufst!

GitLab-Runner können auf beliebige Server verteilt werden und dezentral ihre Arbeit verrichten. Die Runner werden unter Verwendung eines Token mit der GitLab-Ci Coordinator Url verbunden. Ein super Ansatz.

In der GitLab-UI finden sich leider nur wenige Informationen über die Runner. Die IP-Adresse des Runners gehört nicht dazu.

runner_infos_in_gitlab_ui

Mit einem kleinen Trick lassen sich Informationen vom Runner selbst über die Jobs der Pipeline auslesen. Dazu trägt man in „.gitlab-ci.yml“folgendes ein:

gitlab-ci-yml

(Getestet mit CentOS7. Abhängig vom OS muss die korrekte IP-Adresse ggf. anders ermittelt werden.)

Nachdem der Job gelaufen ist, findet sich in seinem Log folgendes:

runner_infos_from_pipeline_job

Damit kennen wir den Namen des Benutzers, dessen Public-Key wir kopieren müssen, und die IP-Adresse des Rechners auf dem der Runner läuft.

Die folgenden Schritte sind dann Standard

  1. Auf der 192.168.0.168 zum user „gitlab-runner“ werden
  2. Falls noch nicht vorhanden, ein Public- / Privat-Key-Pair für den user „gitlab-runner“ erstellen
  3. Per ssh-copy-id den Public-Key des users „gitlab-runner“ auf den Remote-Server kopieren. Dabei ist es wichtig den user zu verwenden, der später aus dem CI-Job den ssh-Zugriff nutzen wird, z.B deployment_user@remote-server-ip

Nun kann sich der Runner als „deployment_user“ per ssh direkt mit dem Remote-Server verbinden und dort das Deployment vornehmen.

runner_build_succeeded

Voilà

Advertisements

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s