Gerade wenn es um Side-Projects oder Hobbyprojekte geht, ist das Budget oft begrenzt. Dann ist es besonders wichtig, dass keine zusätzlichen Kosten für TLS Zertifikate anfallen.
Im Zentrum eines solchen Projekts steht ein Vue.js-Frontend, das sich mit einer HTTP API verbinden soll. Natürlich mit der erforderlichen Sicherheit, die Transport Layer Security (TLS) bieten kann.

Bislang war ZeroSSL besonders deswegen attraktiv, da keine Rate-Limits kreativer Forschung entgegen standen. Allerdings liefert ZeroSSL seit einiger Zeit fehlerhafte (abgelaufene) Zertifikate aus der Vergangenheit oder auch API Fehler.

Da ACME ein Standard ist, sollte das auch mit anderen Anbietern gehen, und ein weiterer Anbieter ist Google.

Die Suche nach dem idealen Self-Hosted Newsletter-Tool kann herausfordernd sein. Es gibt inzwischen auch sehr viele Produkte mit (im grossen und ganzen) ähnlichem Funktionsumfang. In diesem Beitrag werden drei populäre Lösungen verglichen:

Jedes dieser Tools bietet unterschiedliche Funktionen und Vorteile, aber welches passt am besten zu den Anforderungen moderner Systeme?

Drools ist eine Rule-Engine, also ein Baustein für Expertensysteme und zur Flexibilisierung von Entscheidungen. Dabei ist Drools flexibel in bestehende JavaEE, Spring Boot und andere Frameworks integrierbar.
Dieser Beitrag beschäftigt sich mit folgender Fragestellung: Wie könnte eine Cloud-native Umsetzung von Drools im Gegensatz zu dem klassischen Modell einer Einbettung aussehen?

In vielen Kundenprojekten ist der Wunsch zu beobachten, von klassisch betriebenen Anwendungen sofort in die Cloud oder zumindest nach Kubernetes zu migrieren. Vielleicht schwingt dabei der Wunsch mit, Zeit zu sparen, indem Zwischenschritte ausgelassen werden. Oder man ist sich sehr wohl bewußt, dass man in Gewissen Bereichen versäumt hat, Know-How aufzubauen und in Modernisierung zu investieren.

Wir empfehlen regelmäßig zumindest kleine Zwischenschritte einzuplanen, um Erfahrungen mit der Erstellung aber auch dem Design von Anwendungen für Container- und Cloudumgebungen zu sammeln. Das gilt um so mehr, wenn das Unternehmen sich nicht ganze Teams, die sich nur um Infrastruktur und Support kümmern können, leisten möchte.

Eine gute Möglichkeit zum Start stellt der Einsatz von Docker Containern ohne automatischen Orchestrator wie Kubernetes, Mesos oder Docker-Swarm dar. Dabei wählt man typischerweise eine Anwendung aus, die nicht absolut essentiell ist, und optimalerweise bereits von einem Team mit modernen Technologien und vor allem Mindset entwickelt und betreut wird.

Mit verhältnismäßig wenig Infrastruktur können dann auch bereits Patterns aus der Cloud-Welt verprobt werden und entsprechende Erfahrungen mit den notwendigen Umsystemen und Prozessen gewonnen werden. Wichtig ist dabei, dass man den Schwenk auf fertige Lösungen vornimmt, und nicht mit eigenen Mitteln Dinge nachbaut und wartet, die ein Orchestrator mitliefert.

Hat man sich für traefik als Reverseproxy und Loadbalancer entschieden, um Container verfügbar zu machen, kann man bereits von vielen Vorzügen profitieren.

Ein Kunde wünschte sich Canary-Deployments auszuprobieren, und das allein mit traefik. Wie so ein Canary oder A/B Deployment mit traefik umgesetzt werden kann, zeigt der folgende Beitrag.

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.

Single Board Computer (SBC) wie der Raspberry Pi oder die ODROID-Serie eignen sich sehr gut als stromsparende und hinreichend performante Maschinen für Container-Hosting mit Docker oder Kubernetes.
In dem Artikel "Kubernetes auf Odroid N2" wurde die Einrichtung von Kubernetes auf ODROID N2 mit Arch Linux ARM beschrieben.
Der von Hardkernel, dem Hersteller der ODROIDs, bereitgestellte Kernel basiert auf einem alten Stand und wurde durch zusätzliche Treiber und Patches für den ODROID N2 kompatibel gemacht.
Leider bringt der verwendete Kernel einige Nachteile mit sich: So gibt es zum Teil Abstürze und Instabilitäten. Der Prometheus Node-Exporter führt zu einem sofortigen Absturz, so dass an Metrikmonitoring gar nicht zu denken ist. (Hier scheint das Problem in der dynamischen Taktung zu liegen cpufreq_cpu_get, taucht im Stacktrace stets auf.)

Abhilfe schafft der sogenannte Mainline-Kernel. Das ist ein nicht gepatchter Kernel und kann seit Linux 5.5 prinzipiell verwendet werden, da die Unterstützung der verwendeten Hardwarekomponenten des ODROID N2 in diesem enthalten ist.

Im Backend hat sich der Architekturstil "Microservices" für viele Anwendungsbereiche durchgesetzt. Dabei stellt sich relativ schnell die Frage: Wie geht man mit dem Thema Frontend um?

In dem Vortrag "Frontend Architektur für Microservices" gab Thomas Kruse auf der W-JAX 2019 in München einen Überblick zu verschiedenen Herangehensweisen.
Der Vortrag zeigt die speziellen Herausforderungen, die sich aus einer guten Benutzbarkeit von Frontends für Microservices ergeben.

Durch aktuelle Entwicklungen im Bereich von WebComponents und modularer SPA Frameworks ergeben sich zusätzliche Architekturoptionen, die in dem Vortrag bewertet wurden.

Bei dem Meetup Digital Innovation Ruhr behandelte Thomas Kruse in seinem Vortrag "Frontend Architektur für Microservices" verschiedene Architektur Optionen, um mit den Herausforderungen des Frontends bei einer Microservice Architektur umzugehen.

Für den Vortrag wurden die Erfahrungen aus verschiedenen Projekten in einem zeitlichen und technologischen Kontext eingeordnet und liefern damit Entscheidungshilfen für Architekten, die sich mit dem Thema Frontend im Microservice Kontext befassen.

Ein besonderes Augenmerk wurde dabei auf den Systemschnitt aus der Perspektive des Frontends und des Nutzers gelegt, der in der Regel eine integrierte Oberfläche ohne Brüche im Prozess erwartet.

Dank aktueller Entwicklungen eignen sich inzwischen Webcomponents für bestimmte Aufgabenstellungen und wurden mit einem Beispiel auf Basis von Angular Elements praktisch demonstriert.

Bereits in diesem Beitrag zu Docker Multi-Arch Images wurden die Grundlagen erläutert, wie Docker-Images dank Manifest automatisch passend für die jeweilige Plattform ausgewählt werden.

Doch die Erstellung solcher multiplen Images und der zugehörigen Manifest-Dateien ist mit dem automatischen Build auf Docker Hub nicht so intuitiv umsetzbar, wie bei regulären Images. Eine Lösung kann da ein eigener Buildserver inkl. Build-Agents für die zu unterstützenden Plattformen darstellen.

Dieser Beitrag erklärt, wie unter Verwendung von QEMU zur Cross-Compilation und den DockerHub Build Hooks entsprechende Docker-Images und das Manifest vollautomatisch erzeugt und publiziert werden können. (Hintergründe zum Cross Build von Docker Images finden sich hier: Docker Multi-Arch Images )

Update: In diesem Artikel wird ein ähnliches Verfahren, jedoch mit GitHub Actions vorgestellt: Multi Arch Images mit GitHub Actions.

Von Rancher Labs stammt eine abgespeckte Version von Kubernetes mit dem Namen k3s. Kubernetes wird oft als k8s abgekürzt, so dass eine reduzierte Version passenderweise als k3s bezeichnet werden kann.

Das Ziel von k3s ist, eine Kubernetes Umgebung anbieten zu können, wenn begrenzte Resourcen in der Betriebsumgebung den Einsatz einer regulären Kubernetes Installation erschweren oder unmöglich machen.

Im Gegensatz zum vollen Kubernetes Stack benötigt k3s kein etcd als Datenspeicher, sondern setzt auf SQLite. Hier macht sich die Architektur von Kubernetes natürlich besonders bezahlt: Da lediglich der Kubernetes API Server auf die Persistenz zugreifen darf, merken alle weiteren Komponenten von der Umstellung nichts. Um weiteren Hauptspeicher zu sparen wurden auch viele Controller Manager entfernt, die in der Zielumgebung jedoch sowieso nicht sinnvoll zum Einsatz kommen würden.

Im folgenden schauen wir uns an, wie mit Docker und k3s ein Kubernetes Cluster als Docker Container aufgesetzt werden kann. Das ist besonders praktisch, wenn es darum geht, Tests zu machen oder mit Kubernetes zu entwickeln. So spart man sich Minikube oder einen Testcluster.
Übringens arbeitet man auch bei Kubernetes selbst daran, Docker als Umgebung nutzen zu können: Das kind-Projekt (Kubernetes in Docker) verfolgt einen vergleichbaren Ansatz: https://kind.sigs.k8s.io/

Natürlich kann k3s auch ganz ohne Docker eingesetzt werden und ist sogar der Regelfall, denn k3s soll z.B. in Kombination mit Raspberry Pi und vergleichbaren Single Board Computer (SBC) gut verwendet werden können.
Mehr zu k3s gibt es auf der offiziellen Homepage: https://k3s.io/