Kaniko ist in Version 1.0 erschienen, damit ist es Zeit, sich das Werkzeug genauer anzusehen. Bereits in Mit Kaniko Docker Images ohne Daemon bauen und Mit Kaniko Docker Images in Kubernetes bauen wurde Kaniko vorgestellt. Auch wenn sich Kaniko weiterentwickelt hat - so braucht man keine root-Rechte mehr, um ein Image zu bauen - so gibt es leider noch kein ARM oder ARM64 Image.

In diesem Beitrag geht es also darum, wie auf Basis eines existierenden Dockerfile ein Build in Kubernetes durchgeführt werden kann. Dabei wird der Docker-in-Docker Ansatz gewählt, womit auch bei einer anderen Container-Runtime wie rkt oder CRI-O keine Probleme auftreten.

Zertifikate spielen in einem Kubernetes Cluster eine wichtige Rolle: Durch Zertifikate wird eine Vertrauensbeziehung ausgedrückt.
Vor allem bei einer statischen Beziehung zwischen Services lässt sich eine Authentifizierung durch TLS Zertifikate sehr effizient ausdrücken.

Kubernetes bringt daher auch typischerweise eine eigene Certificate Authority (CA) mit, die als Trust-Root für alle im Kubernetes Cluster verwendeten Zertifikate dienen kann.
Eine eigene CA kann, je nach verwendeten Verfahren zur Cluster Einrichtung, ebenfalls verwendet werden, oder es können intermediate-CA Zertifikate eingesetzt werden. Standard ist jedoch dass jeder Kubernetes Cluster über eine eigene CA verfügt.

Wie man mit dieser CA interagieren kann wird in diesem Beitrag erklärt.

In diesem Kubernetes Beitrag geht es darum, eine CI Pipeline auf Kubernetes Infrastruktur aufzusetzen. Wie bereits in den vorherigen Kubernetes Beiträgen soll auch hier ein Augenmerk auf dem Support der ARM Plattform gelegt werden. Leider trotz der zunehmenden Verbreitung von ARM im Serverumfeld noch immer nicht selbstverständlich, dass Multi-Arch Images bereitgestellt werden.

Lange Zeit war Spring zusammen mit Spring Boot der Defacto-Standard, wenn es um die Entwicklung von Microservices bei hoher Entwicklerproduktivität ging. Nun schicken die Entwickler von Grails ein neues Framework ins Rennen: Micronaut.

Das Versprechen von Micronaut: Aus den Ansätzen von Grails, Spring Boot und Spring zu lernen und ein Framework bereitzustellen, das den Anforderungen von modernen Cloud- und Microserviceumgebungen gewachsen ist.
Aus technischer Sicht sind einige Punkte, wie minimierter Einsatz von Java-Reflection und Proxies, spannend, die für die Verwendung der Substrate VM und Graal relevant sind.

Werfen wir einen Blick auf Micronaut - eine Einführung.

Java Anwendungen haben den Ruf, schwergewichtig und langsam zu sein. Langsam ist Java dank ausgefeilter Optimierungen der JVM zwar nicht (mehr), jedoch sind Docker Container Images von Anwendungen relativ gross.

Das ist dadurch bedingt, dass eine JVM und ein Betriebssystem mitgeliefert werden muss, damit die Java Anwendung im Docker Container ausgeführt werden kann.

In aktuellen Java Versionen ist dank GraalVM die Möglichkeit gegeben, Java Anwendungen als native Programme zu kompilieren und statisch zu linken. Damit ist weder eine JVM noch ein Betriebssystem im Container Image erforderlich - vergleichbar mit dem aus der Go Welt bekanntem Vorgehen.

Wie das ganze funktioniert, wird im folgenden Beitrag vorgestellt.

Continuos Integration mit Docker Images für Angular Frontend Anwendung illustriert Karsten Sitterberg am Beispiel von GitLab-CI in seinem Artikel im aktuellen Entwickler Magazin. Continuos Integration ist vor allem im Frontend Bereich eine Herausforderung, da ein Frontend ohne Umsysteme bzw. Backend schwer zu testen ist. Auch der für die Testdurchführung regelmäßig erforderliche Browser kann in CI-Umgebungen schwierig sein.

gRPC hat bisher vor allem im Backend oder bei der direkten Kommunikation zwischen Anwendungen auf dem Endgrät und dem Backend eine Rolle gespielt. Aufgrund der zunehmenden Rolle von Browseranwendungen sollte gRPC auch in clientseitigen Webanwendungen genutzt werden können.
Das zugehörige Projekt ist gRPC-Web: https://github.com/grpc/grpc-web

In diesem Beitrag wurde die Erstellung eines Spring Boot gRPC Backends demonstriert. Nun get es darum, das Backend in einer Angular Webanwendung mit gRPC-Web anzubinden.

In diesem Beitrag wurde die Installation von Kubernetes auf ODROID unter Arch Linux ARM beschrieben.

Hier geht es nun um das Update auf Kubernetes 1.13, auch in diesem Fall mit selbst übersetzten Paketen für Arch Linux. Bei anderen Distributionen sind ggf. bereits die Upstream Pakete verfügbar.

Wie schon in Kubernetes Upgrade Arch Linux ARM im Detail beschrieben, wird das Update in folgenden Schritten durchgeführt:

In verteilten Systemen, zu denen etwa solche mit Microservice- und Cloud-Architekturen zählen, müssen in der Regel über Anwendungsgrenzen hinweg Funktionsaufrufe erfolgen. Typischerweise kommt dabei für synchrone Aufrufe HTTP als Transportschicht zum Einsatz, das Format der ausgetauschten Daten kann XML, JSON oder eine andere spezifische Datenstruktur sein. Welche HTTP-Verben und welche Adressen (URLs) wie zu verwenden sind, ist dabei eine fast schon in philosophische Bereiche ausufernde Debatte zwischen den verschiedenen Ansätzen. Am häufigsten finden sich REST und Abwandlungen davon als Schnittstellenkonzept.

Im Gegensatz zu der reichhaltigen API-Oberfläche von REST findet sich SOAP als XML-basiertes RPC- (Remote-Procedure-Call-) Verfahren, bei dem lediglich HTTP POST-Requests zum Einsatz kommen. Neben dem oft als schwerfällig bezeichneten Vorgehen von Design und Implementierung von SOAP-Schnittstellen hat XML als Transportformat auch deutliche Auswirkungen auf möglichen Durchsatz und erforderliche CPU- und Speicherresourcen bei der Verarbeitung.

Als Alternative zu diesen Ansätzen hat Google gRPC entwickelt: gRPC setzt ebenfalls auf HTTP auf, verwendet jedoch Google Protocol Buffers als optimiertes Datenformat. Wie der Einsatz im Kontext einer Java-Spring-Boot-Anwendung aussehen kann, wird im Folgenden dargestellt.