Auch wenn Docker stand heute die vermutlich am weitesten verbreitete Container-Lösung darstellt, gibt es doch einen regen Wettbewerb. Besonders seit Kubernetes in Version 1.5 das Container-Runtime-Interface (CRI) eingeführt hat, mit dem sich die tatsächliche Container-Implementierung austauschen lässt. Das CRI-O Projekt stellt einen Adapter zwischen der durch die OCI (Open Container Initiative) spezifizierten Schnittstellen für Container-Runtimes und dem durch Kubernetes mit CRI definierten Integrationspunkten dar. Standardmäßig verwendet CRI-O die OCI konforme Containerimplementierung runc.

Andere OCI kompatible Laufzeitumgebungen wie rkt oder Intel Clear Container lassen sich damit ebenfalls einsetzen. In einem typischen Docker basierten Setup sähe die Interaktion so aus:

Mit CRI-O sieht die Interaktion so aus:

Der Stack bei CRI-O ist also deutlich geringer, ist jedoch als auf Kubernetes fokussierter Stack auch kein vollständiger Ersatz für die vielen verschiedenen Anwendungsfälle von Docker.

Im folgenden geht es um das konkrete Setup von CRI-O mit Kubernetes unter Arch Linux ARM.

Auch wenn Arch Linux meist topaktuelle Pakete hat, so ist dies bei Projekten wie Kubernetes auf der ARM Architektur nicht der Fall. Auch im AUR, also dem von der Community gepflegten Bereich, finden sich für ARM 64 bit keine Kubernetes Pakete. Es ist jedoch relativ einfach, sich auf Basis des Quellcodes von Kubernetes einen eigenen Build zu erzeugen. Damit sind sowohl für ARM 32bit als auch ARM 64bit eigene Arch Linux Kubernetes Pakete in überschaubarer Zeit und mit nur wenigen Handgriffen gebaut.

Wie das geht, wird im folgenden Beitrag erklärt.

Im Artikel Kubernetes Cluster mit Raspberry Pi wurde ein Cluster-Setup mit Raspberry Pi Computern gezeigt. Als Alternative dazu bieten ODROID-C2 Maschinen doppelt so viel RAM und auch etwas mehr CPU Leistung. Viel wichtiger ist dabei jedoch die deutlich bessere Netzwerkanbindung mit 1Gbit, die auch tatsächlich erreicht werden. Der ODROID unterstützt schnellen eMMC Speicher und UHS-1 SDR50 MicroSD, der preislich deutlich günstiger als die eMMC Module sind. Der ODROID besitzt als Hauptspeicher DDR3 SDRAM Module, die rund doppelt so hoch getaktet sind, wie die LPDDR2 des Raspberry Pi 3. Preislich liegt ein Raspberry Pi 3 bei ca. 36 Euro und ein ODROID C2 bei 58 Euro - je nach Einsatzzweck ist das Preis-Leistungsverhältnis bei dem ODROID deutlich besser. Die ARMv8 Architektur des ODROID C2 wird von Arch Linux und Ubuntu Cloud als 32 und 64 bit Variante unterstützt, Raspian gibt es bisher lediglich als 32 bit Variante.

Ein Nachteil beim 64bit Betrieb ist der etwas höhere Speicherbedarf. Zwar hat der ODROID mit 2GB RAM doppelt so viel Speicher wie der Raspberry Pi, doch für den Betrieb vieler Container kann man nie genug Speicher haben. Hier kann man nun von einem Trick profitieren, der in ähnlicher Form bereits auch von Apple standardmässig eingesetzt wird, um Nutzern auch mit relativ wenig Speicher ein gutes Gesamterlebnis zu bieten.

Ein Mini-Cluster für Kubernetes eignet sich hervorragend für Experimente und zum Training. Wie beispielsweise in Kubernetes Cluster mit Raspberry Pi erklärt, eignen sich für einen kostengünstigen Start Raspberry Pi Minicomputer ausgezeichnet. Leider ist ARM aktuell nicht im Fokus der diversen Cloud-Native Storage Lösungen, so dass sich als Alternative ein externes Volume anbietet. Das häufig anzutreffende Synology NAS bietet NFS Support. Wie sich dies mit Kubernetes einsetzen lässt, wird im folgenden illustriert.

Sowohl für Trainings als auch eigene Experimente ist ein physischer Cluster oft anschaulicher, als virtuelle Maschinen. Als preiswerter Einstieg bieten sich bereits seit geraumer Zeit die Raspberry Pi Minicomputer an. Für rund 40 Euro pro Gerät erhält man einen Rechner mit 1 Gb RAM und vier ARM Kernen. Dazu wird noch eine USB Stromversorgung und MicroSD Speicherkarten benötigt, und schon kann es los gehen.

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.

Der Browser entwickelt sich mehr und mehr zu einer vielseitigen Plattform, die als Ziel für immer komplexere Anwendungen dient. Um mit dieser neuen Plattform alle Anwendungsfälle abbilden zu können, müssen auch aufwändige grafische Darstellungen wie etwa 3D-Modelle oder ganze Spiele auf dieser Plattform möglich sein. Für 3D-Modelle und Videospiele wurden bisher zum Beispiel OpenGl oder Direct3D verwendet. Im Browserumfeld steht mit WebGL jetzt eine vergleichbare API für 3D-Programmierung zur Verfügung. Damit wird ermöglicht, aus dem Browser heraus per JavaScript Grafiken zu erzeugen, die hardwarebeschleunigt direkt durch die Grafikkarte gerendert werden.

Bei der Nutzung von eigenen Docker-Images stellt sich früher oder später die Frage, wie eine sinnvolle Build-Automatisierung am besten umgesetzt wird. Der Docker-Host, auf dem die Images gebaut werden, läuft früher oder später in Probleme durch verwaiste Volumes, Image-Layer und ganze Images. Soll auch der Buildserver als Docker-Container betrieben werden, so wird die Situation noch etwas komplizierter: Auf keinen Fall soll versehentlich ein Container während des Builds oder sogar der Container des Buildservers selbst "aufgeräumt" werden.

Damit ergeben sich im Prinzip folgende Optionen

Die zuletzt genannte Option wird im folgenden exemplarisch mit Jenkins, Ansible und Vagrant/VirtualBox vorgestellt. Vagrant dient dabei lediglich zur Veranschaulichung, in produktiven Umgebungen wird man auf Cloud-Resourcen oder VMware ESX zurückgreifen.

Docker hat mit Version 17.05 sogenannte Multi-Stage Builds eingeführt. Dieser Beitrag zeigt, wie Docker-Multi-Stage-Builds effektiv für Angular-Anwendungen eingesetzt werden können und um was es sich bei Docker-Multi-Stage-Builds überhaupt handelt.

Dieser Artikel zeigt, wie sich mit wenigen Schritten eine komfortable und leicht zu wartende Umgebung für Entwicklung und lokale Tests von Java Spring-Boot und TypeScript Angular Anwendungen erstellen lässt.

Vorweg stellt sich die Frage: Warum sind neue Ansätze sinnvoll und was steckt hinter den eingesetzten Technologien?