Mit Docker haben sich Container als Auslieferungsformat (nicht nur) für Microservices zum Status Quo für Cloudanwendungen etabliert. Zur Erstellung der Container-Images war lange Zeit Zugriff auf einen Docker-Daemon erforderlich. Besonders in Umgebungen wie Kubernetes-Clustern oder Public-Clouds mit gemeinsam genutzter Infrastruktur soll auf privilegierte Container verzichtet werden. Mit dem typischen Ansatz von Docker-in-Docker oder Docker-Outside-Docker erhält ein so ausgeführter Build nämlich relativ viele Rechte. Dank der OCI Spezifikation für Image-Formate ist Docker mit einem Dockerfile jedoch nur noch eine Möglichkeit, zum auslieferbaren Image zu gelangen.

Ein weiterer Aspekt sind die oft schwer umzusetzenden Optimierungsmöglichkeiten für Docker Images: Um vom Layer-Caching optimal zu profitieren und damit sowohl I/O-Operationen als auch Speicherplatz zu sparen, sollten die Daten, die sich weniger häufig ändern, in einem separaten Layer positioniert werden, als Daten, die sich regelmäßig ändern. Bei einer Spring Boot Anwendung könnte man zum Beispiel zwischen allen Abhängigkeiten und den eigentlichen, zu der Anwendung selbst gehörenden Class-Dateien differenzieren: Die Abhängigkeiten werden sich seltener ändern, als das Programm, das bei jedem Bugfix und jeder Erweiterung Änderungen erfährt. Nur dieser geänderte Image-Layer muss dann verteilt werden.

Für beide Probleme soll das Google Projekt "Jib" eine Lösung liefert. Am Beispiel einer Spring Boot Anwendung und Maven wird der Einsatz von Google Jib demonstriert.

Die Beispielanwendung kann z.B. von hier bezogen werden: https://github.com/trion-development/spring-boot-rest-sample

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.

Qualität von Frontend-Anwendungen erhöhen und sicherstellen ist ein wichtiges Ziel. Vor allem, wenn es um große Anwendungen mit hohen Investitionen geht, sollen diese oft langfristig gewartet und ausgebaut werden. Wie das Thema Qualitätssicherung am Beispiel einer Angular Anwendung angegangen werden kann, stellte Karsten Sitterberg bei dem Meetup der "Frontend Freunde" in Münster vor.

Docker-Images sind plattformabhängig: Während früher Docker ausschließlich unter Linux auf x86 Plattformen ein Thema war, kamen mit der ARM-Architektur und Windows-Containern zusätzliche Varianten hinzu. Die einzige Option, das jeweils richtige Image für die Plattform auszuwählen, war dann, mit Image Tags zu arbeiten, sofern von einem Projekt überhaupt mehrere Architekturen unterstützt wurden und nicht ein ganz anderes Repository genutzt werden musste. Tags sind eindimensional und es gibt ggf. weitere Image-Varianten zu berücksichtigen. Darum hat jedes Projekt eine eigene Namenskonvention erstellt, beispielsweise gibt es dann foo/mariadb:amd64, foo/mariadb:arm, foo/mariadb:alpine-amd64 und foo/mariadb:alpine-arm. Damit werden die zu verwendenen Image-Namen plattformabhängig und können nicht übergreifend verwendet werden, z.B. in Kubernetes-Deploymentmanifests.

Das Problem wurde erkannt und Docker hat in mehreren Schritten den "Multi-Architecture-Support" implementiert.

Wie ein Docker-Image für die Docker-Registry für ARM 64, z.B. für Raspberry PI oder ODROID C2, erzeugt wird, wurde im letzten Artikel beschrieben: Cross-Build von Docker Image Registry für ARM 64. Nun geht es darum, mit diesem Image in Kubernetes eine Docker-Registry aufzubauen, um damit Container-Images im Cluster zur Verfügung zu stellen.

Für die TLS-Absicherung sorgt traefik, der in Kubernetes als Ingress fungiert und von Let’s Encrypt SSL-Zertifikate ausstellen läßt. (Die Einrichtung von traefik als Kubernetes-Ingress kann hier nachgelesen werden: Traefik als Kubernetes Ingress. )

Bisher gibt es die offizielle Docker Registry lediglich als x86 Docker Image. Damit ist ein Betrieb unter ARM oder ARM 64 aktuell nicht möglich. Obwohl Docker Multi-Arch-Support eingeführt hat, also die Möglichkeit unter dem selben Image-Namen verschiedene Architekturen zu bedienen, ist das bei dem hauseigenen Image leider noch nicht umgesetzt worden. In diesem Beitrag geht es nun darum, ein passendes Image durch Cross-Compilation zu erstellen und damit eine Registry bereit zu stellen.

Der Betrieb des mit Docker erstellen Image wird unter CRI-O erfolgen, womit die Interoperabilität, dank der Standardisierung von OCI, unter Beweis gestellt wird.

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.

In einer Public-Cloud-Umgebung wird dauerhafter Speicher für Kubernetes in der Regel durch den jeweiligen Cloud-Provider bereitgestellt. Bedarf an dauerhaften Speicher gibt es dabei regelmäßig, wenn Daten nicht in den jeweiligen Datenbanken oder Messaging-Systemen der Umgebung gehalten wird, sondern lokale.

Wird der Kubernetes Cluster sogar lokal betrieben, gibt es entsprechnd keinen Cloud-Provider, der Storage in Form von Object-Store oder Block-Storage zur Verfügung stellen könnte. Neben NFS und iSCSI, mit denen klassische SAN-Systeme angebunden werden können, wächst auch das Angebot an Cloud-Native-Storage. Dabei handelt es sich um Softwarelösungen, die flexibel und dynamisch Speicher im gesamten Kubernetes Cluster zur Verfügung stellen können.

In diesem Beitrag wird der Einsatz von Rook (https://www.rook.io) auf einem ARM 64 Cluster mit ODROID C2 Knoten demonstriert.

Um Anwendungen erfolgreich bauen zu können, ist - je nach Anwendung - ein hoher Aufwand in die Einrichtung der Umgebung zu investieren. Beispielsweise für ein Android-Projekt muss Java installiert sein, es werden die Android-Tools mit dem Android-SDK benötigt und der Build muss passend konfiguriert werden. Dieses Setup wird aber nicht nur auf den Entwickler-Rechnern benötigt, auch die Countinuous-Integration-Umgebung des Buildservers muss entsprechende Werkzeuge bereitstellen. Um Reproduzierbarkeit zu gewährleisten, sollte sichergestellt sein, dass in allen diesen Umgebungen die gleichen Versionen der Tools genutzt werden.

In diesem Artikel werden wir uns damit beschäftigen, wie auf einfachem Wege eine zur Entwicklung von Android-Projekten geeignete Umgebung mit Hilfe von Docker erstellt werden kann. Am Beispiel von Gitlab-CI wird der Einsatz des entsprechenden Docker-Containers in einer CI-Umgebung gezeigt.

Kubernetes bietet eine Weboberfläche zur Clusterverwaltung bzw. Administration: Das sogenannte Kubernetes Dashboard. Das Dashboard gibt es als vorbereitetes Deployment für die Architekturen AMD/Intel 64 und ARM. Leider gibt es derzeit kein fertiges ARM 64 Deployment. Wer das reguläre ARM Deployment ausprobiert, wird zwar die zugehörigen Resourcen erfolgreich erzeugen, jedoch wird der Container nicht erfolgreich starten und in der Folge wird der Pod-Status mit einem der Fehler Error oder CrashLoopBackOff ausgegeben.