In der Softwareentwicklung gehören CI/CD-Pipelines inzwischen zum guten Ton. Allerdings braucht man hierfür einiges an Infrastruktur, um den Buildprozess so weit zu automatisieren. In dieser kurzen Artikelserie will ich eine mögliche Pipeline auf Basis von GitHub, GitHub Actions, quay.io und OpenShift-basierten Runnern für GitHub Actions betrachten. Ich nutze hier OpenShift, da ich einen OKD-Cluster zu Verfügung habe, aber die Runner lassen sich auch 1:1 für Kubernetes-Cluster nutzen.
Meine Software ist eine Java spring-boot-Anwendung, die per Maven gebaut wird. Aber dies betrifft nur den kurzen build-Teil der Pipeline und man kann die gleiche Methode auch für Gradle-Builds oder auch für node.js nutzen – man muss gegebenenfalls einen anderen Build-Runner aussuchen.
Dieser Teil der Artikelserie verdeutlicht das Zusammenspiel der Komponenten und bietet so eine Übersicht. Die einzelnen Bestandteile werden dann in den folgenden Artikeln besprochen.
Wir nutzen hier die Services von Github (als git-Repository und als Steuerung für unsere Pipeline, bei Github „Workflow“ genannt), quay.io (als Container-Repository, das App-Repository ist nur als zukünftige Erweiterung der Pipeline eingetragen) und natürlich unseren eigenen OCP-Cluster (bei mir noch OKD 3.11).
Die Applikation kommt aus einem weiteren Projekt von mir, aber ist in diesem Kontext Nebensache. Sie wird per Maven gebaut und dann per podman-Build in einen Container gegossen. Den java-Runner werden wir hier im Rahmen der Artikel selbst erweitern, um den Node-Part der Anwendung ebenfalls hier bauen zu können. Und weil wir gerade dabei sind, packen wir auch noch gradle als Buildsystem in den Container. Aber dazu mehr im entsprechenden Artikel dieser Serie.
Das mag jetzt nach einem großen Haufen an Komponenten aussehen, aber neben dem Runner-Projekt auf OCP und den Repositories auf Github (source) und quay.io (Container) sind es noch zwei Dateien im Source-Repository (.github/workflow/ci.yaml und src/main/docker/Dockerfile), die unsere Pipeline vervollständigen werden.
Schauen wir uns den Ablauf der Pipeline mal systematisch an:
So ein Workflow funktioniert ganz einfach. Nach dem Auslöser (normalerweise ein commit) führt er einfach der Reihe nach alle definierten Aktionen aus. Wenn ein Fehler auftritt, bricht er ab. Wurden alle Aktionen ausgeführt, beendet sich der Workflow. Nichts besonderes also.
Wir werden einen einfachen Workflow haben, der die Software
- mittels Maven auf dem java-runner baut,
- den Container mittels buildah baut und
- ihn dann per podman nach quay.io hochlädt.
Es kommen neben diesen grundsätzlichen Arbeiten noch ein paar technische Aktionen (auschecken des Codes, aufsetzen der Build-Umgebung, …) Also nichts, wovor man sich fürchten müsste.
Damit haben wir unseren Überblick. Im nächsten Teil werden wir uns um das Aufsetzen des Github-Repositories (und die Definition des Workflows dort) kümmern.