Galt vor einigen Jahren noch das Motto, dass Datenbanken besser außerhalb von (Docker-)Containern oder gar eines Kubernetes Clusters betrieben werden sollten, so hat sich das Bild inzwischen stark gewandelt. Nicht nur, dass sich Kubernetes als das neue Betriebssystem von Rechenzentren und der Cloud etabliert hat, es gibt sogar unmittelbare Vorteile bei der Integration von Plattformdiensten mit Kubernetes.
Welche grundsätzlichen Optionen es gibt, und wie das Vorgehen aussehen kann, beleuchtet dieser Beitrag.

Ursprünglich war Docker konzipiert als Eierlegendewollmilchsau Probleme rund um den Betrieb von Software in der Cloud zu lösen.
Dazu gehören verschiedene Aspekte von Bereitstellung der Software als Image bis hin zur Laufzeitumgebung mit Persistenz. Im Kontext von Kubernes kann es zu Überschneidungen kommen, die sich in unangenehmen Überraschungen äußern. Worauf es zu achten gilt, wenn Docker VOLUMEs und Kubernetes im Spiel sind - zum Beispiel bei Datenbanken - wird in diesem Beitrag vorgestellt.

Azure DevOps ist der Nachfolger des Microsoft Team Foundation Server (TFS). Inbegriffen sind Buildserver (CI), Version Control (git), Verwaltung manueller Testpläne und Artefaktauslieferung (CD).
Die Features von Azure DevOps können dabei je nach Bedarf aktiviert werden.

Im folgenden soll eine Angular Webanwendung mit Azure DevOps als Buildserver gebaut werden. Damit der Build gemeinsam mit der Software versioniert und entwickelt werden kann, wird die Buildkonfiguration im YAML Format als Azure Pipeline im Repository abgelegt.

Nachdem DockerHub die automatischen Builds von Docker Images nicht mehr kostenlos für jeden anbietet, bieten sich GitHub Actions als eine praktische Alternative an. ( Die Umsetzung von Multi-Arch Builds mit DockerHub wurde in dem Beitrag Docker Multi Arch Images mit DockerHub behandelt.)
In diesem Beitrag wird eine Umsetzung von Multi-Arch Images am Beispiel das Angular-CLI Docker Images vorgestellt.

OpenID Connect und OAuth2 sind vielleicht etwas moderner und hipper als das bereits etwas in die Jahre gekommene SAML 2 Protokoll. Soll jedoch im Enterpriseumfeld eine Anwendung in bestehende Landschaften integriert werden, führt selten ein Weg an SAML 2 vorbei. Das gilt um so stärker, wenn es sich um eine Branche mit hohem Sicherheitsbedarf wie Luftfahrt, Banken oder Versicherungen handelt.

Keycloak hat sich als zuverlässige und gleichzeitig sehr leicht zugängliche Plattform zur Umsetzung von OpenID Connect oder SAML erwiesen. Dabei kann Keycloak sowohl produktiv eingesetzt werden, als auch sehr komfortabel als lokale Testumgebung für Entwicklung und Test verwendet werden. Zur Integration von Keycloak in Spring Boot existieren neben einem Keycloak Modul auch Spring-Security-SAML bzw. OAuth2 Client und Resourceserver.

Gerade wenn es um das Thema Security geht, bringen automatisierte Tests ein wichtiges Sicherheitsnetz für die Software. Wir wollen Keycloak als SAML 2 IdP verwenden und mit einer Spring Boot Anwendung Authentifizierung mit SAML 2 als Beispielanwendung für automatisierte Integrationstests verwenden. Ein - relativ einfacher - Weg wäre, Keycloak als Docker Container im Rahmen der CI-Pipeline mit Jenkins, Bamboo oder GitLab-CI bereitzustellen, so dass die zu testende Software darauf zugreifen kann. Allerding verliert man damit die Möglichkeit, die Tests lokal genauso zu entwickeln und zu validieren, wie sie nachher in der Buildserver Umgebung laufen.

Eine Alternative stellen Testcontainers dar. Die allgemeine Verwendung von Testcontainers wurde bereits in Testcontainers mit JUnit 5 erläutert. Nun schauen wir uns an, wie Keycloak, Testcontainers und Spring Boot SAML 2 zusammen eingesetzt werden kann.

Regelmäßig kommt in unseren Docker Schulungen Verwunderung auf, wenn wir Beispiele zum Einsatz von Containern im Entwicklungsprozess aufzeigen. Denn Container bzw. Docker bringt gerade da auch immense Vorteile: Neben einer möglichen Parität zwischen Produktionsumgebung und Entwicklersystem ist es gerade die sehr einfache Möglichkeit, Umsysteme als Container bereitzustellen.

Das kann für einen Frontendentwickler das Backend sein, für einen Backendentwickler kann es die richtige Datenbank, Message-Queue oder ein anderer (Micro-)Service sein.
Verfügen aktuelle IDEs in der Regel über Docker-Integration oder wird docker-compose eingesetzt, stellt sich die Frage, wie in CI-Umgebungen Container für Integrationstests am besten eingesetzt werden können. Hier hat das Projekt Testcontainers eine Lösung ins Rennen geschickt: Durch eine gelungene Abstraktion lassen sich Container sehr leicht in Tests verwalten und zusammen mit den Tests orchestrieren. Container-Typen und Versionen werden gemeinsam mit dem Testcode versioniert, was die Wartung und Refactoring erleichtert. Auch ein häufiges Problem, nämlich auf den erfolgreichen Start eines Containers bzw. des damit bereitgestellten Dienstes zu warten, wird gut gelöst.

Testcontainers gibt es für verschiedene Programmiersprachen bzw. Plattformen. Wir schauen uns im folgenden einmal die Umsetzung für Java speziell im Kontext von JUnit 5 genauer an.

Container, allen voran Docker, sind in aktuellen Infrastrukturen ein fester Bestandteil. Waren früher gerade Buildserver und CI-Umgebungen schwer zu warten, da diverse Werkzeuge oftmals jeweils in mehreren Versionen gepflegt werden müssen, können Build-Container alle benötigten Werkzeuge direkt mitbringen.

Moderne Buildserver wie DroneCI oder GitLab CI unterstützen daher nativ die Verwendung von Werkzeugcontainern in Form von Docker Images. Für Angular gibt es beispielsweise mit https://hub.docker.com/r/trion/ng-cli-karma ein Image, in dem Angular CLI und Webbrowser bereitgestellt werden.

In diesem Beitrag werfen wir einen Blick auf Cypress, dass sich sehr gut zur Umsetzung von Integrations- und Ende-zu-Ende Tests eignet. Cypress kann prinzipiell mit beliebigen Technologien kombiniert werden, beispielsweise serverseitig gerenderten Anwendungen, oder mit Angular, React oder Vue im Browser umgesetzten Anwendungen.
Wir verwenden in diesem Beispiel React, jedoch sollte die Übertragung auf andere Frameworks dem Entwickler sehr einfach von der Hand gehen.

Im vorhergehenden Artikel wurde der Einsatz von GitHub Actions beschrieben, um eine Angular Anwendungen auf GitHub zu testen und zu bauen.
Das Thema Deployment wurde dabei aufgrund der Vielzahl an Varianten nicht weiter behandelt. In diesem Beitrag wird nun erklärt, wie die ebenfalls von GitHub bereitgestellte Plattform zum Hosting von statischen Seiten, GitHub Pages, genutzt werden kann, um darauf eine Angular Anwendung bereitzustellen.

Der große Vorteil von clientseitigen Frameworks kommt dabei voll zur Geltung: Es wird lediglich ein simpler Webserver benötigt, der die HTML, JavaScript und CSS Dateien ausliefert. Serverseitige Logik wird für das Angular Frontend an sich nicht benötigt.

Jib eignet sich sehr gut, um Docker Images mit Maven oder Gradle zu erzeugen, ohne dass dazu ein Docker Daemon verwendet werden muss. Im Gegensatz zu Docker unterstützt Jib derzeit noch keine Multi-Arch Images. Damit ist ein automatischer Build für die jeweilige Plattform nicht möglich, was sich zum Beispiel auf einem Raspberry Pi, ODROID oder anderen Maschinen auf Basis der ARM Architektur bemerkbar macht.

Mit einer kleinen Konfigurationsanpassung ist es jedoch möglich, passende Images zu erzeugen.