GitLab Runner für Windows Headless

Oder wie Windows und Kubernetes mit Hilfe vom GitLab Runner die „besten Freunde“ wurden?

  

Heute berichtet uns Florian (Cloud Consultant bei teuto.net), in einem Tutorial von seinen Erfahrungen, wie man Windows Applikationen in Docker Containern bündeln kann.

Auch die Welt um Microsoft Windows hat Bekanntschaft mit Docker und mittlerweile auch Kubernetes gemacht. Um Windows-Applikationen in entsprechenden Docker Containern bündeln zu können, benötigen wir einen Windows Host. Sinnvollerweise integrieren wir auch unsere Windows-Applikationen mit GitLab-CI. Hierfür benötigen wir den GitLab Runner auf unserem Windows Host und verbinden diesen mit unserem GitLab.

Voraussetzungen

Im Rahmen dieses Tutorials benötigen wir einen Windows Host mit installiertem OpenSSH, um unsere Kommandozeilen- bzw. PowerShell-Befehle an den Host absetzen zu können. Desweiteren nutzen wir scoop (https://scoop.sh/), um zusätzliche Software wie Git zu installieren. Weiterhin benötigen wir Admin-Zugang für die GitLab-Instanz, die wir mit dem GitLab Runner verbinden möchten. Zu Beginn verbinden wir uns via SSH mit unserem Windows Host und richten für GitLab-Runner ein entsprechendes Verzeichnis ein.

Verzeichnis vorbereiten

Microsoft Windows [Version 10.0.17763.379]
(c) 2018 Microsoft Corporation. All rights reserved.
administrator@WIN-BUILDER-3 C:UsersAdministrator>powershell
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
PS C:UsersAdministrator>mkdir C:GitLab-Runner
PS C:UsersAdministrator>cd C:GitLab-Runner

Prerequisites installieren

scoop ist ein Paket-Manager, mit dem wir eine Vielzahl schöner Tools installieren können. Wir benötigen beispielsweise Git.

scoop installieren

iex (new-object net.webclient).downloadstring('https://get.scoop.sh')

git installieren

scoop install git

GitLab Runner installieren

Üblicherweise kann die gitlab-runner.exe über den PowerShell Command Invoke-WebRequest heruntergeladen werden. Dieser ist jedoch unserer Erfahrung nach sehr langsam.

GitLab-Runner Download: Invoke-WebRequest

Invoke-WebRequest -UseBasicParsing https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-windows-amd64.exe -OutFile gitlab-runner.exe

Schneller geht es, die Datei lokal herunterzuladen und dann per scp auf den Windows Host zu kopieren. Dazu laden wir den GitLab-Runner zunächst auf unsere lokale Maschine herunter: https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-windows-amd64.exe

Nach dem folgenden Schema können wir die Datei per scp auf unseren Windows Host kopieren:

$ scp ~/Downloads/gitlab-runner-windows-amd64.exe Administrator@<Windows-Host-IP>:C:/GitLab-Runner/gitlab-runner.exe

Befindet sich die heruntergeladene Datei nun unter C:\GitLab-Runner\gitlab-runner.exe installieren wir den Dienst.

PS C:GitLab-Runner> .gitlab-runner.exe install
Runtime platform                                    arch=amd64 os=windows pid=736 revision=de7731dd version=12.1.0

Unter der URL https://<GitLab-URL>/admin/runners erhalten wir das Token, welches wir benötigen, um den Runner mit GitLab zu verbinden.

PS C:GitLab-Runner> .gitlab-runner.exe register --non-interactive --url https://<GitLab-URL> --registration-token <TOKEN> --executo
r shell --locked=false
Runtime platform                                    arch=amd64 os=windows pid=3424 revision=de7731dd version=12.1.0 
Registering runner... succeeded                     runner=Pss8Wz9W 
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

Nun ist der GitLab Runner registriert und unter https://<GitLab-URL>/admin/runners gelistet.

Debugging

Lassen wir an diesem Punkt eine Pipeline laufen, stellen wir fest, dass der Job während eines Git-Commands  in einen Timeout läuft. Hier ist es hilfreich ein Tiefgreifendes Debugging vorzunehmen. Zum einen können wir in der Datei C:\GitLab-Runner\config.toml unter unserem gewählten Runner die folgende Zeile ergänzen:

environment =  [„GIT_CURL_VERBOSE=1“, „GIT_TRACE=1“]

Desweiteren können wir den CI-Job in den Debug-Modus versetzen, was für die Produktionsreife jedoch unbedingt wieder abzuschalten ist.

gitlab-ci.yml

job_name:
variables:
CI_DEBUG_TRACE: "true"

Git konfigurieren

Der Grund dafür, dass der Runner, wie weiter oben erwähnt, in einen Timeout läuft, ist eine Konfiguration in Git. Lassen wir uns die Git Konfiguration ausgeben:

PS C:GitLab-Runner> git config --list
core.symlinks=false
core.autocrlf=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
help.format=html
http.sslcainfo=/ssl/certs/ca-bundle.crt
diff.astextplain.textconv=astextplain
rebase.autosquash=true
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
credential.helper=helper-selector

Unter credential.helper benötigen wir statt helper-selector den Wert manager. Hierzu dienen die folgenden Befehle.

PS C:GitLab-Runner> git config --system --unset credential.helper helper-selector
PS C:GitLab-Runner> git config --system --set credential.helper manager
PS C:GitLab-Runner> git config --list
core.symlinks=false
core.autocrlf=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
help.format=html
http.sslcainfo=/ssl/certs/ca-bundle.crt
diff.astextplain.textconv=astextplain
rebase.autosquash=true
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
credential.helper=manager

Zuletzt starten wir den GitLab-Runner Service und überzeugen uns von seinem Status. Jetzt ist unsere CI-Pipeline in der Lage Windows Container über den auf unserem Windows Host installierten GitLab Runner zu bauen.

PS C:GitLab-Runner> .gitlab-runner.exe start
Runtime platform                                    arch=amd64 os=windows pid=3692 revision=de7731dd version=12.1.0
PS C:GitLab-Runner> .gitlab-runner.exe verify
Runtime platform                                    arch=amd64 os=windows pid=3432 revision=de7731dd version=12.1.0 
Verifying runner... is alive                        runner=TM_9eM-x 

Wir hoffen, Euch hat unser Tutorial gefallen und Ihr probiert es aus. Über euer Feedback freuen wir uns sehr.

Ihr möchtet noch mehr über Kubernetes und seine Begrifflichkeiten wissen, dann stöbert gern in unserer Wissensbasis oder besucht uns auf dem OWL Tech und Innovation Day am 26.09. in Paderborn.

Bis demnächst bei  „Kubernetes und ich“