GitHub Workflow — Build once, deploy to every Cloud Foundry

GitHub Actions? Cloud Foundry? Wie bekommen wir diese beiden Welten zusammen, um ein Deployment von GitHub auf Cloud Foundry auszuführen.

Passend zum angekündigten Release des neuen Workflow Features von GitHub, haben wir uns in einem Lab die GitHub Actions angesehen.

Unser erster Eindruck: Es geht ziemlich leicht von der Hand.

Ausgangssituation

Ein Kunde hat nach einem Starter Projekt gefragt, das zum einen bei GitHub gehostet werden und zum anderen auch gleich ein automatisches Deployment auf Cloud Foundry ermöglichen soll. Vor dem GitHub Workflow Feature haben wir für CI/CD auf Travis gesetzt und entschieden, dass wir das Projekt in einem Lab auf den GitHub Workflow respektive die GitHub Actions umstellen wollen.

Lab Logbuch

Bei Comsysto Reply können wir uns 3 Tage pro Quartal neben der Projektarbeit mit neuen technischen Themen im Rahmen sogenannter Labs beschäftigen. Im Bezug auf oben genanntes Projekt haben wir diesmal das Thema GitHub Actions näher beleuchtet.

Tag 1

Um einen vollständigen Workflow abzubilden, haben wir zunächst ein github-action-lab Projekt erstellt. Dabei handelt es sich um eine simple Spring Boot Applikation, für die wir einen CI/CD-Workflow definieren wollen.

Unsere naive Erwartung war, dass unter GitHub Actions eine Action zu finden ist, die das Deployment eines Artefakts auf Cloud Foundry ermöglicht. Da wir keine finden konnten, suchten wir nach einer Möglichkeit eine neue Action zu entwickeln, die dann auch über die offizielle Actions URL zur Verfügung steht. Bald ist uns aufgegangen, dass Actions aus beliebigen GitHub Public Repositorys in einem Workflow benutzt werden können.

So haben wir mit Hilfe der Workflow Dokumentation eine eigene cloudfoundry-action entwickelt. Orientiert haben wir uns stark an der gcloud action, da sie prinzipiell genau das ermöglicht, was wir auch auf der Cloud Foundry CLI ausführen wollen.

Das Ergebnis war eine erste Version der cloudfoundry-action, mit der ein Deployment auf Cloud Foundry möglich war. Allerdings war diese Version nicht flexibel einsetzbar, da Annahmen bzgl. der auszuliefernden jar-Datei und der manifest.yml in der Action getroffen wurden.

Den Build einer Applikation vom tatsächlichen Deployment dieser zu trennen, ist grundsätzlich eine gute Idee. Dazu aber mehr am Ende des Blogs. Dem Ansatz folgend enthält unser Workflow einen build: job und einen deploy: job. Am Ende des Tages sah unser Workflow wie folgt aus:

Der offensichtliche Nachteil: Aus dem Workflow geht nicht hervor, welche jar-Datei in welcher Weise auf Cloud Foundry ausgeliefert wird. Man kann nur annehmen, dass es die ist, die im Step jobs.deploy.steps.name: Download artifact Step heruntergeladen wurde. Vermutlich wird auch irgendwie die im jobs.build.steps.name: Add manifest to build result Step kopierte manifest.yaml verwendet.

Tag 2

Wir wollten bei der Verwendung der Action alle möglichen Cloud Foundry CLI Kommandos unterstützen, sie damit flexibler einsetzbar und den gesamten Workflow lesbarer machen. Angelehnt an die gcloud action haben wir die Action entsprechend angepasst und damit im Grunde einen Cloud Foundry CLI Wrapper geschaffen. Die Annahmen, die in ersten Version der Action verborgen waren und diese damit auch limitiert haben, konnten somit direkt im Workflow konfiguriert werden.

Die einzige Möglichkeit, Daten zwischen Workflow Jobs zu teilen, ist der Austausch über sogenannte Artefakte. Diesen Mechanismus haben wir schon am Ende von Tag 1 verwendet, um die jar-Datei und die manifest.yaml im Deploy Job zur Verfügung zu stellen.

Da sich die cloudfoundry-action jetzt zu einem reinen CLI Wrapper entwickelt hat, brauchten wir wiederum eine Möglichkeit, den Pfad zur jar-Datei und zur manifest.yaml im jobs.deploy Job verfügbar zu machen. Das erreichten wir durch das Erstellen einer json-Datei im jobs.build.name: Prepare deploymentArchive Step, die dem Artefakt hinzugefügt wird, das wir im jobs.build.name: Upload deploymentArchive Step persistieren. Andere Jobs im Workflow können dann das Artefakt herunterladen und auf den Inhalt zugreifen.

Der Inhalt der deploymentInformation.json Datei sieht wie folgt aus:

Um im jobs.deploy Job diese Datei auszulesen, haben wir eine weitere Action deployment-information-action/read entwickelt. Sie ist dafür zuständig die json-Datei auszulesen und die enthaltenen Werte über die Output Parameter cf-manifest-path und artefact-path nachfolgenden Steps zur Verfügung zu stellen.

Am Ende von Tag 2 sah unser Workflow wie folgt aus:

Tag 3

Um das Erstellen der json-Datei noch in eine Action auszulagern, haben wir uns am letzten Tag noch der deployment-information-action/create Action gewidmet. Sie nimmt als input parameter artifact-base-name, artifact-version, archive-name, target-path und erstellt daraus die unter Tag 2 beschriebene json-Datei.

Von beiden Actions haben wir dann noch ein erstes Release erstellt und violà, am Ende unseres Labs haben wir mit folgender Workflow Konfiguration unser Ziel erreicht:

Fazit und Ausblick

Eine Stärke von GitHub Actions ist ganz klar, dass jeder in einem öffentlichen Repository Actions entwickeln kann. Diese können dann in beliebigen Workflows referenziert werden. Die richtige Lizenz vorausgesetzt sind diese Actions auch OpenSource.

Sich in dem Angebot von Actions zurecht zu finden, ist allerdings nicht intuitiv. Erwartet hätten wir, dass man auf https://github.com/actions/ auch nach 3rd-Party Actions suchen kann. In der Suche berücksichtigt werden aber nur die offiziellen Actions.

Aufgrund der knappen Zeit übersieht man oft Features, die einem das Leben erleichtern bzw. die im Grunde das Problem lösen, das man versucht, selbst zu lösen. So ist es auch uns ergangen. Erst beim Schreiben dieses Beitrags haben wir die create-release Action entdeckt. Es sieht so aus, als könnte diese Action unsere deployment-information-action ersetzen.

Wie schon erwähnt, setzen wir auf das Trennen des Build Jobs vom Deploy Job. Das ermöglicht eine build-once-deploy-everywhere CD Strategie.

Wie genau? Dem widmen wir uns in unserem nächsten Lab.

This blogpost is published by Comsysto Reply GmbH

comsystoreply

Innovation through insight.

comsystoreply

Innovation through insight. Thinking lean and moving agile when delivering software products for the digital era.

Sean @ Comsysto Reply

Written by

Solution Architect working for Comsysto Reply GmbH

comsystoreply

Innovation through insight. Thinking lean and moving agile when delivering software products for the digital era.