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?

Dieser Artikel veranschaulicht den Aufbau einer Docker-basierten Entwicklungsumgebung für Kafka und zeigt, wie die benötigten Infrastrukturkomponenten auf einfache Weise mit Docker Compose bereitgestellt werden können.

Dieser Artikel erläutert am Beispiel eines Angular CLI Dockerfiles den Aufbau eines Docker Containers zur Ausführung von Builds. Die Verwendung des Containers wurde in Docker Build für Angular CLI erklärt. Der fertige Container ist via DockerHub unter trion/ng-cli verfügbar. Das zugehörige Repository bei GitHub findet sich unter https://github.com/trion-development/docker-ng-cli

Der obere Teil des Dockerfile definiert das verwendete Basis Image und deklariert Parameter, die beim Build des Images spezifiziert werden können.

Docker als Containerlösung wird vor allem eingesetzt, um damit Anwendungen leicht und reproduzierbar deployen zu können. Dank der Isolation von Abhängigkeiten stellt ein Container sicher, dass eine Anwendung genauso, wie sie auf einem Entwicklungs- oder Testsystem abgenommen wurde, auch später in Produktion läuft.

Mit einem Docker Container ist auch die gegenseitige Beeinflussung von Anwendungen minimiert: Benötigt eine Anwendung eine bestimmte Laufzeitumgebung, kann diese im Container isoliert bereitgestellt werden. So kann man zum Beispiel unterschiedliche node.js oder npm Versionen komfortabel parallel nutzen, ohne auf dem Rechner selbst Konfigurationen vornehmen zu müssen.

Ähnliche Vorteile gibt es auch während der Entwicklung: