Wolkensturm aus Fernost

PouchContainer & Dragonfly: Was die Alibaba Cloud zu bieten hat

Oliver Arafat

© Shutterstock / Torychemistry

Die „Big 3“ im Cloud-Umfeld sind aktuell AWS, Microsoft Azure und die Google Cloud. Auch was Container-Infrastrukturen und deren Orchestrierung angeht, sind diese drei die ersten Ansprechpartner. In diesem Artikel erläutert Oliver Arafat, Senior Cloud Solutions Architect bei Alibaba Cloud, anhand von Beispielen, warum sich in Punkto Containerorchestrierung ein Blick nach China lohnt, wo die hierzulande eher unbekannten PouchContainer oder Dragonfly erfolgreich im Einsatz sind. Er erklärt zudem, auf welche DevOps-Technologien er aktuell setzt und welche Rolle diese bei Alibaba Cloud spielen.

Wieso  man PouchContainer und Dragonfly unbedingt kennen sollte

Ganz egal ob Startup, Mittelständler oder Konzern, Unternehmen sollten stets auf bestmögliche Technologien zurückgreifen und auch deren Entwicklung vorantreiben. Laut einer aktuellen IDC-Studie gaben 77 Prozent der deutschen Unternehmen an, dass bei ihnen bereits DevOps-Prozesse im Einsatz sind – Tendenz steigend. Unternehmen erkennen den Wert, den innovative Technologien und starke Infrastrukturen mit sich bringen.

Durch meine Arbeit komme ich tagtäglich mit Technologien in Kontakt, die außerhalb Chinas in der Entwicklerszene noch recht unbekannt sind. Viele davon spielen allerdings in der Champions League. Der Bereich Containerorchestrierung und -verteilung eignet sich als Beispiel. Die meisten europäischen Entwickler fokussieren sich eher auf Docker oder Podman. In anderen Märkten wie China setzen Entwickler auch auf PouchContainer und Dragonfly. Es lohnt sich, einen genaueren Blick auf diese Technologien zu werfen.

PouchContainer

PouchContainer ist ein Open-Source-Projekt, das 2011 ins Leben gerufen wurde, um die Containertechnologie voranzutreiben. Der Aufbau unterteilt sich grundsätzlich in eine Ökosystem-Architektur und eine Komponenten-Architektur. Dies garantiert eine klare Trennung der Funktionalitäten.

Ökosystem-Architektur

Die Ökosystem-Architektur scheint auf den ersten Blick ein wenig kompliziert – ist sie aber nicht. Bis zur oberen Orchestrierungsebene unterstützt PouchContainer Kubernetes und Swarm. Für die darunter liegende Laufzeitumgebung ist PouchContainer kompatibel mit OCI-kompatibler Laufzeit wie runC, runV oder auch runlxc. Um große Speicher- und Netzwerkerweiterungen zu ermöglichen, sind CNI und CSI verknüpft. Schauen wir uns die verschiedenen Bausteine genauer an.

Runtime Layer

Der Runtime Layer konzentriert sich hauptsächlich auf OCI-kompatible Komponenten, die von PouchContainer unterstützt werden. Diese Laufzeiten vereinheitlichen Spezifikationen zu Standards für Betriebssystemprozess- und Anwendungscontainer. Derzeit unterstützt PouchContainer vier Arten von OCI-kompatiblen Laufzeiten: runC, runlxc, runV und katacontainer.

Mit runC erstellt PouchContainer gewöhnliche Container wie z.B. Docker. Mit runlxc erstellt PouchContainer Container auf der Basis von LXC. Der Einsatz von runlxc ist sehr hilfreich, wenn Admins Container auf einer Vielzahl von Linux-Kerneln (insbesondere ältere Versionen) laufen lassen müssen. Auch für Hypervisor-basierte Container gibt es etliche Anwendungsszenarien. PouchContainer unterstützt sie mit runV und katacontainer.

Alle vier genannten Laufzeiten werden über containerd orchestriert, somit übernimmt containerd die gesamte Containerverwaltung. Es abstrahiert eine Vielzahl an syscalls und OS-spezifischer Funktionalität, um Container auf unterschiedlichen Betriebssystemen, wie beispielsweise Linux und Windows, laufen lassen zu können.

Orchestration Layer

PouchContainer hat von Anfang an Kubernetes unterstützt. Es bietet hier eine Integration mit cri-containerd, so dass Pouch-Container entsprechend verwendet werden können, um Pods zu verwalten und abzubilden. Der Control Flow umfasst dabei cri-containerd, containerd-client, containerd, runC/runV und schließlich den Pod. Zukünftig wird die Kommunikation direkt über das cri-Plugin von containerd laufen.

Container Layer

Pouch verfolgt mit Rich Containers einen etwas anderen Ansatz, als man es von Docker gewöhnt ist. Anstatt eine Anwendung pro Container zu fordern, kann man sich Pouch-Container eher als leichtgewichtige VMs vorstellen, die mehr als einen Prozess pro Container vorsehen und dafür sogar einen eigenen Init-Prozess auf Basis von systemd und sbin-init mit verschiedenen pre- und post-Hooks vorsehen. Durch die Unterstützung von runlxc kann Pouch zudem auch mit älteren Kernel-Versionen (2.6.32+) genutzt werden. Dadurch eignet es sich sehr gut, um auch ältere Legacy-Applikationen zu containerisieren.

Dies ist sicherlich ein Grund dafür, dass die Alibaba Cloud heute trotz vieler historisch gewachsener Applikationen zu 100 Prozent auf Containern läuft. Pouch ist daher vor allem für die folgenden Anwendungsszenarien geeignet:

  • Die schnelle Containerisierung traditioneller IT-Infrastrukturen
  • Die Bereitstellung von Diensten in Großunternehmen
  • Applikationen im Finanzsektor, die sehr hohe Anforderungen an Isolierung, Sicherheit und Stabilität haben

Komponenten-Architektur

Bei der Komponentenarchitektur ist der PouchContainer in zwei Hauptteile strukturiert: PouchContainer CLI und Pouchd.

PouchContainer CLI

Es gibt viele verschiedene Befehle, die im PouchContainer CLI gebündelt sind, wie create, start oder exec. Benutzer können via Pouchd mit dem PouchContainer CLI interagieren: Wenn ein Befehl ausgeführt wird, übersetzt das PouchContainer CLI ihn in Pouchd-API-Aufrufe. Das PouchContainer-Client-API ist ein integriertes Paket im PouchContainer-CLI. Es ist zudem problemlos möglich, das PouchContainer-Client-Paket in Software von Drittanbietern zu integrieren. Dieses Paket unterstützt aktuell allerdings lediglich Golang. Wenn Pouchd über das PouchContainer-Client-Paket aufgerufen wird, erfolgt die Kommunikation über HTTP.

Pouchd

Pouchd ist von Anfang an entkoppelt und benutzerfreundlich konzipiert und baut auf folgenden Komponenten auf:

HTTP Server

Der HTTP-Server empfängt API-Aufrufe direkt und antwortet auf der Client-Seite. Seine Aufgabe ist es, Anfragen zu analysieren und zu transformieren, um sie an den Bridge Layer übergeben zu können.

Bridge Layer

Der Bridge Layer ist ein Übersetzungs-Layer, der Objekte vom Client bedient, um den Anfragen von Manager oder containerd gerecht zu werden. Dies ist die Voraussetzung, um für das API von Moby kompatibel zu sein.

Manager (System/Network/Volume/Container/Image)

Manager ist der Hauptprozessor von Pouchd. Er bearbeitet die passenden Objekte aus den Anfragen. Es gibt derzeit fünf Manager: Container-Manager, Image-Manager, Netzwerk-Manager, Volumen-Manager und System-Manager.

ctrd

ctrd ist der containerd-Client in Pouchd und unterstützt die Kommunikation zwischen Manager und containerd.

Dragonfly

Dragonfly ist ein P2P-gestütztes Bild- und Dateiverteilungssystem, das wir auch bei Alibaba Cloud selbst im Einsatz haben, um täglich Millionen von Container-Images zuverlässig abzurufen und zu deployen. Es ist Teil der Cloud Native Computing Foundation und wird dort aktuell als Incubation Level Project verwaltet.

Durch den Peer-to-Peer Ansatz ist die Container-Registry kein Flaschenhals mehr, da die Container-Images zwischen den einzelnen Cluster-Knoten übertragen werden. Hierbei können bis zu 99,5 Prozent der ausgehenden Bandbreite einer Container-Registry eingespart werden. Drangonfly ist hierbei nicht-invasiv, unterstützt verschiedene Containerformate und hat keine Anhängigkeiten auf externe Caches oder Datenbanken. Eingebaute Fehlerbehandlungen, wie die automatische Isolierung fehlerhafter Nodes und Speicherkapazitäts- und Konsistenz-Checks (auch ohne MD5 Hashes), gewährleisten das performante und robuste Deployment neuer Container-Images.

Die Technologien sind außerdem integraler Bestandteil der Container-Orchestrierungs- und Registrierungsdienste, die Entwicklern für eigene Projekte zur Verfügung stehen:

Modernste Technologie aus aller Welt in einem Team

Bei Alibaba Cloud arbeiten wir stetig daran, unsere Technologien zu verbessern und Innovationen zu implementieren. Denn wir benötigen für unseren Kunden eine leistungsstarke Cloud-Infrastruktur für extreme Skalierbarkeit und Robustheit. Die Alibaba Cloud hat beispielsweise in den ersten 68 Sekunden des 2019er „Global Shopping Festivals“ am 11.11., auch bekannt als Singles Day, eine Milliarde US-Dollar an Brutto-Warenvolumen verarbeitet. Insgesamt wurden auf der Infrastruktur von Alibaba Cloud innerhalb von 24 Stunden 38,4 Milliarden US-Dollar an GMV umgesetzt, und das ohne auch nur eine Sekunde an Ausfallzeit. Diese starke Technologien mit zu entwickeln macht stolz und bringt jede Menge Spaß. Aktuell beschäftigen wir uns beispielsweise mit IIoT-Plattformen, die moderne Technologie-Stacks und Dienste wie Kafka, Cassandra und Flink mit unseren führenden Sicherheitsdiensten für Anti-DDoS verbinden.

Geschrieben von
Oliver Arafat

Oliver Arafat ist Senior Solutions Architect bei Alibaba Cloud.

Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: