GitHub Runner in OpenShift/kubernetes

Nachdem wir uns im letzten Teil das quay.io-Container-Repository aufgesetzt haben Das Aufsetzen der OpenShift basierten GitHub Action Runner ist der letzte Schritt, den wir noch brauchen, um die CI-Pipeline fertig zu haben. Und darum kümmern wir uns in diesem Artikel.

Ich gebe zu, ich habe es mir eigentlich recht bequem gemacht, denn hier haben schon meine Kollegen von Red Hat sehr viel vorbereitet. Es gibt ein Helm-Chart und selbst einige Runner haben sie schon im Angebot. Nur beim Java-Runner musste ich etwas nacharbeiten, da ich für Vaadin neben dem Java 11 auch noch node.js im gleichen Runner gebraucht habe (Vaadin kompiliert den Frontendteil zusammen mit dem Java-Anteil). Aber dazu kommen wir später.

Als erstes brauche ich ein Projekt in meiner OpenShift-Umgebung (nunja, ich nutze hier meine OKD-Installation, die noch immer in Version 3.11 läuft, aber wenn Ihr ein OpenShift 4 habt, sollte es nicht viel anders sein).

$ oc new-project github-runner
Now using project "github-runner" on server "https://console.das.wuesstet.ihr.wohl.gerne:8443".

You can add applications to this project with the 'new-app' command. For example, try:

    oc new-app django-psql-example

to build a new example application in Python. Or use kubectl to deploy a simple Kubernetes application:

    kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node

$

Natürlich muss man dazu eingeloggt sein. Aber wie das geht, wisst Ihr bei eurem Cluster selbst.

Da builda-sa mit erhöhten Rechten laufen muss, erledige ich das hier gleich. Immer daran denken, dass dies natürlich ein Bruch der Security-Sandbox ist. Ob ihr dazu bereit seid, müsst Ihr selbst abwägen.

$ oc create -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: buildah-sa
EOF
$ oc adm policy add-scc-to-user privileged -z buildah-sa
securitycontextconstraints.security.openshift.io/privileged added to: ["system:serviceaccount:github-runner:buildah-sa"]
$

Jetzt haben wir den privilegierten Benutzer, damit buildah seine Arbeit verrichten kann. Allerdings brauchen wir noch ein GitHub PAT (personal access token) – ich verweise aus Faulheit auf die recht gute Dokumentation seitens GitHub mit der Anmerkung, dass wir mindestens die Berechtigung repo benötigt. Dieses Token und den Eigentümer des GitHub-Repositories schreiben wir uns mal in Umgebungsvariablen, denn wir werden sie öfter benötigen:

$ export GITHUB_PAT=<Personal Access Token>
$ export GITHUB_OWNER=<Eigentümer eures Repositories>
$ export GITHUB_REPO=<Repository>

Den letzten Eintrag braucht Ihr nur, wenn ihr den Runner an ein bestimmtes Repository binden wollt. Wenn Ihr es euch für mehrere Projekte einfach machen wollt, legt bei GitHub eine Organisation an und bindet die Runner an die Organisation – dann könnt ihr die Repos innerhalb der Organisation mit den gleichen Runnern glücklich machen und müsst nicht jedes Repository bei GitHub einzeln mit Runnern bespaßen.

Wir brauchen natürlich das Helm-Chart, um die Runner zu installieren. Das bekommen wir auch von GitHub:

$ helm repo add openshift-actions-runner https://redhat-actions.github.io/openshift-actions-runner-chart
$

Jetzt kann der Spaß losgehen:

$ helm upgrade --install buildah-runner openshift-actions-runner/actions-runner --set-string githubPat=$GITHUB_PAT --set-string githubOwner=$GITHUB_OWNER --set-string runnerImage=quay.io/redhat-github-actions/buildah-runner --set-string privileged=true --set runnerLabels="{podman,buildah}"
$ helm upgrade --install java-runner-11 openshift-actions-runner/actions-runner --set-string githubPat=$GITHUB_PAT --set-string githubOwner=$GITHUB_OWNER --set-string runnerImage=quay.io/klenkes74/java-runner-with-maven --set-string runnerTag=latest --set runnerLabels="{java,java-11,maven,gradle,ant,ivy}"
$ 

Ihr könnt auch gerne noch die anderen Runner der Red Hat Community of Practice installieren – es gibt noch einen allgemeinen Runner, einen Runner für node.js und einen k8s-tools-runner, damit Ihr per GitHub-Action auch direkt euren Cluster konfigurieren könnt. Aber für unsere Anwendung benötigen wir nur den Java- und den buildah/podman-Runner.

Dem aufmerksamen Leser wird auch noch etwas am java-runner-11 aufgefallen sein. Er lädt kein Image von quay.io/redhat-github-actions (wo es auch einen java-11-runner gibt), sondern einen von mir bereitgestellten Runner von quay.io/klenkes74/java-runner-with-maven. Das liegt daran, dass der normale Runner kein Maven beinhaltet. Und weil ich gerade dabei war, habe ich noch gradle, ant und ivy und – wie oben schon erwähnt – node.js mit reingeworfen. Wider erwarten findet er auch bereits bei mir unbekannten Projekten innerhalb von AWS Anwendung – wie ich durch die quay.io-Statistiken erfahren durfte. Wer sich für den Runner und seinen Bau interessiert, kann sich das auf https://github.com/klenkes74/java-runner-with-maven anschauen. Vielleicht schreibe ich da auch einen Blog drüber – aber eigentlich ist das nur ein Dockerfile, dass diverse Sachen nachinstalliert.

Und jetzt sollten die Pods laufen und sich zu Github verbinden. Auf OpenShift-Seite sieht es ungefähr so aus:

$ oc get pod
NAME                                READY   STATUS    RESTARTS   AGE
buildah-runner-774f989c86-sc96s     1/1     Running   0          13d
java-runner-11-79f5c4f49d-rlmjt     1/1     Running   0          20h
$

Und auf Github findet man es unter den Settings (bei mir natürlich bei der Organisation und nicht im Repository):

Voilá, die Github-Runner laufen und verrichten ihre Arbeit. Ihr könnt euch auch über die OKD-Console den Output anschauen:

Jetzt haben wir alles zusammen. Ein Push in die konfigurierten Branches (bei mir development) wird den Workflow CI auslösen und am Schluss liegt dann – wenn alles funktionierte – das Container Image im quay.io-Repository.

Inzwischen habe ich im Projekt noch CodeQL-Checks hinzugefügt und einen zweiten Workflow für Releases auf den main-Branch gesetzt. Aber das ist dann nochmal ein neues Thema.

Ich wünsche allen viel Spaß mit Github-Actions ohne dabei auf die Minuten schauen zu müssen.