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.

Kubernetes nutzt Container Images im OCI- oder Docker-Format, um Workload im Cluster zu verteilen und auszuführen. Möchte man - zum Beispiel im Rahmen eines CI-Builds - in einem Kubernetes-Cluster auch Docker-Images bauen, gibt es im wesentlichen drei Ansätze:

Den Docker-Daemon, der im Cluster selbst Container bereitstellt, in einem Build-Container zu verwenden bringt vor allem den Nachteil mit sich, dass der Build die Stabilität der Cluster-Node beeinträchtigen kann. Zudem ist nicht gesagt, dass überhaupt ein Docker-Daemon bereitsteht, schließlich könnte der Kubernetes-Cluster auch CRI-O als Runtime verwenden. Diese Option scheidet somit in der Regel aus.

Docker-in-Docker (DinD) ist eine häufig gewählte Option, verlangt jedoch, dass der entsprechende Container priviligiert gestartet wird. Aus Sicherheitsaspekten ist diese Option zwar nicht optimal, lässt sich jedoch in der Praxis gut einsetzen. Das gilt selbst dann, wenn die Container-Engine des Clusters gar kein Docker verwendet.

Als letzte Optionen bleibt noch die Verwendung spezialisierter Werkzeuge zur Erstellung von Container-Images. In diesem Beitrag wurde die Verwendung von Buildah beschrieben, in Spring Boot mit Jib die Verwendung von Jib.

Jib ist speziell auf Java-Anwendungen ausgerichtet, buildah benötigt zum Bauen von Images root-Berechtigungen - beide Werkzeuge bringen damit gewisse Einschränkungen mit.

Von Google kommt das Werkzeug Kaniko, das in diesem Beitrag vorgestellt wird, und speziell für den Einsatz in Kubernetes konzipiert wurde.

Auch wenn mit Docker die Containertechnologie fast überall Einzug hält, gibt es immer wieder in der praktischen Arbeit Herausforderungen zu meistern. Ganz besonders dann, wenn die Anwendung, die in einen Container verbracht werden soll, nicht dafür ausgelegt wurde, entsprechend betrieben zu werden. Vor allem im PHP Umfeld finden sich oft Anwendungsarchitekturen, die der Docker Philosophie "Ein Container, eine Aufgabe" entgegen stehen.

Ein möglicher Ansatz zur Lösung ist die Nutzung von Docker lediglich zur Ausführung der PHP- und Webserverprozesse und separate Verwaltung der PHP Programmdateien. Ein Host-Mount kann die Dateien in beliebige Container einbinden - doch verliert man dann gerade die Stärke von Docker, sowohl für Rollout als auch Rollback eine handhabbare Einheit bestehend aus Anwendungsserver und Programmdateien bereitzustellen.

Das Problem besteht bei PHP Anwendungen in Docker darin, dass diese typischerweise aus mehreren Komponenten bestehen:

Zumindest die ersten beiden Dienste benötigen Zugriff auf die selben PHP Programmdateien. Einen Scheduler und PHP-FPM im selben Container auszuführen passt nicht so ganz zur reinen Lehre von Docker, ist aber solange leicht zu verschmerzen, wie lediglich eine Container-Instanz läuft.

Sowieso als externe Resourcen verwaltete Dienste wie die Datenbank oder einen Memcached in einem separaten Container laufen zu lassen ist naheliegen. Doch wie geht mit man Software um, die für eine gänzlich andere Betriebsumgebung konzipiert wurde?

Am Beispiel typischer PHP Projekte kann man die unterschiedlichen Vorgehensweisen und damit einhergehende Eigenschaften betrachten.

Das seit Angular 6 als Beta verfügbare Feature "Angular Elements" wird mit Angular 7 erweitert und für den produtkiven Einsatz stabilisiert. Mit Angular Elements lassen sich mit dem Angular-Framework leichtgewichtige Web-Components entwickeln, die sich in unterschiedlichen Kontexten einsetzen lassen.

Karsten Sitterberg stellt in seinem Artikel "Architektur mit Angular Elements" vor, wie sich bereits mit Angular in Version 6 die Entwicklung von Web-Components gestalten lässt und welche Konsequenzen sich für die Architektur von Anwendungen durch die neuen Möglichkeiten ergeben.

Um auf Kubernetes-Dienste zuzugreifen gibt es mehrere Möglichkeiten, eine davon ist der Ingress. Ingress eignet sich für HTTP basierte Dienste und kann Funktionalitäten wie TLS-Terminierung und Load-Balancing übernehmen. Im Prinzip handelt es sich bei Ingress also um so etwas wie einen Reverse-Proxy.

Kubernetes bringt dabei keine Ingress-Implementierung mit, sondern es gibt diverse Optionen von nginx über HA-Proxy und Apache Trafficserver bis zu traefik. Wie traefik als Kubernetes-Ingress-Implementierung eingesetzt werden kann, wird in diesem Beitrag vorgestellt.

Im Markt der Serverless-Ansätze positioniert sich Oracle mit Project Fn. Dieser Beitrag demonstriert den Einsatz des Fn Project um mittels Docker oder Kubernetes Function-As-A-Service (FaaS) bzw. Serverless Architekturen umzusetzen. Als Demo wird eine Java Anwendung mit Project Fn als Docker-Container erstellt und im Fn Server betrieben.

Docker ist die führende Umsetzung von Linux Containern - kein Wunder, hat Docker die Idee von Containern als leichtgewichtige Alternative zu Virtualisierung erst populär gemacht. Inzwischen hat sich das Ökosystem deutlich weiterentwickelt. Google hat mit dem Kubernetes Projekt den defacto Standard für Scheduling und Verwaltung von Containern und zugehörigen Resourcen geschaffen. Neben Docker existieren mit rkt (CoreOS) und CRI-O (Open Container Initiative) weitere Container Runtimes für das mittlerweile gesetzte OCI Image Format. Relativ neu dabei sind die Werkzeuge buildah zum Bauen von Containern und podman zur Ausführung mittels CRI-O (beide von Project Atomic, RedHat).

Warum entstehen unterschiedliche Runtimes und Build-Toolchains? Welche Vorteil für Nutzer im Kontext von Docker oder Kubernetes ergeben sich daraus?

Der Trend weg von großen, schwerfälligen Applikationsservern hin zu Microservices und Containern wird durch die Cloud als Ablaufumgebung stark beschleunigt. Konsequent weitergedacht erhält man noch kleinere Dienste, Nanoservices, die lediglich einzelne Funktionen umsetzen. Als minimale Deploymenteinheit lässt sich darüber eine feingranulare Skalierung erzielen, und durch verringerten Overhead eine kosteneffiziente Nutzung der Infrastruktur realisieren. Vorreiter war Amazon mit Lambda, doch auch andere Cloud Anbieter zogen schnell nach, und bieten Function-as-a-Service (FaaS) oder "serverless" Umgebungen an.

Kubernetes als De-facto-Standard für containerbasierte Cloudinfrastruktur bietet von Haus aus zwar kein vergleichbares Modell an, jedoch gibt es mit Oracle Fn, Kubeless und Open Whisk zahlreiche Projekte, die FaaS als OpenSource Plattform für den Einsatz in eigener Cloudinfrastruktur oder auch öffentlichen Kubernetes Cloud-Runtimes ermöglichen wollen.

Im folgenden wird ein kurzer Blick auf Kubeless in Kombination mit Java geworfen. Ausschlaggebend für diese Auswahl war ein relativ unkompliziertes Setup, wodurch die Hemmschwelle für Experimente verringert wird.

Auf der Konferenz JavaLand stellten Stefan Reuter und Thomas Kruse das Thema "Self-Contained Systems" (SCS) im Kontext moderner Technologieentscheidungen vor.

Auf Basis von Erfahrungen in mehreren Projekten wurde der Weg von einer monolithischen Anwendungslandschaft zu einer Zielarchitektur auf Basis von Microservices und modernen Frontendtechnologien wie Angular skizziert.

Empfohlen wurde dabei die Nutzung von Domain-Driven Design für den Schnitt fachlicher Domänen und damit für die Identifikation möglicher SCS.