Statt Docker und Kubernetes: Facebook braucht Tupperware für seine Container
Vor allem das Unternehmen Docker hat in den vergangen Jahren mit seiner gleichnamigen Software die Container-Technik unter Linux vorangetrieben und quasi zum Mainstream werden lassen. Mit Kubernetes, das Ursprünglich von Google erstellt worden ist, hat sich die Container-Community auch auf einen Standard zur Orchestrierung geeinigt. Auch bei Facebook wird für die eigenen Dienste massiv auf Container-Technik gesetzt, nur eben völlig ohne Docker oder Kubernetes, wie der Facebook-Entwickler Zoltan Puskas auf dem Open Source Summit Europe in Prag(öffnet im neuen Fenster) erklärt.
Der Grund dafür scheint zunächst recht naheliegend zu sein: Als Facebook begonnen habe, Container zu nutzen, sei die Technik von Docker noch nicht verfügbar gewesen, so Puskas. Außerdem sei die Integration von Tupperware in bestehende Systeme von Facebook schlicht einfacher.
Doch aus dem Vortrag geht auch hervor, dass der Aufbau der Container-Lösung bei Facebook mit den eingangs genannten Techniken derzeit wohl nur schwierig umzusetzen wäre oder Facebook dafür zumindest sehr viel Portierungsarbeit leisten müsste.
Tupperware als rundum-sorglos Verpackung
Die verschiedenen Aufgaben von Tupperware lassen sich dabei analog zu den bekannten Container-Techniken beschreiben. So gibt es bei Facebook etwa einen Tupperware-Scheduler, der ähnliche Aufgaben übernimmt wie Kubernetes oder Swarm von Docker. Statt der Docker Engine oder Rkt von CoreOS nutzt Tupperware einen eigenen Agent zum Ausführen und Bereitstellen der Container.
Für die Netzwerkverbindungen der Nodes und Containeranwendungen setzt Tupperware auf das Konzept des Identifier Locator Addressing (ILA), das im Linux-Kernel unterstützt(öffnet im neuen Fenster) wird und bei dem Internet-Standardisierungsgremium IETF unter der Führung von Facebook diskutiert(öffnet im neuen Fenster) wird.
Die Idee von ILA ist es, IPv6-Adressen so zu aufzuteilen, dass ein dynamischer Teil den Ort eines Knotens im Netzwerk und ein statischer Teil den Knoten selbst beschreibt und damit unabhängig von seinem Einsatzort identifizierbar macht.
Das von CoreOS für Kubernetes erstellte Netzwerktool Flannel(öffnet im neuen Fenster) ist dagegen ein Daemon, der auf allen Hosts laufen muss und für deren Verknüpfung untereinander sorgt.
Wie zu erwarten, kann dann das Tupperware-System von den Facebook-Admins per Kommandozeilenwerkzeug oder eben über eine Web-Oberfläche gesteuert werden. Außer Tupperware macht sich Facebook für die eigentlichen Container noch eine Vielzahl von Linux-Techniken zu Nutze.
Btrfs, Systemd und Cgroups für Container
Container-Images baut Facebook mit dem eigenen Build-Tool Buck, das als Open Source Software bereit steht. Verteilt werden diese Images in den Facebook-Rechenzentren über eine interne Paketverwaltung.
Die Images selbst werden wie bei anderen Container-Systemen auch in Schichten zusammengesetzt. Facebook nutzt hier als Basis die Distribution Centos, eine eigene Schicht mit Konfigurationen für SSH und Zertifikate sowie eine Schicht für Anwendungen und deren einzelne Binärbestandteile.
Statt der sonst üblichen virtuellen Union-Dateisysteme wie OverlayFS 2 nutzt Facebook jedoch das native Linux-Dateisystem Btrfs und hier insbesondere die Copy-on-Write-Funktion, um lediglich Unterschiede (Binary Diffs) zwischen den Images verteilen zu müssen.
Weitere Vorteile von Btrfs in diesem Kontext sind laut Facebook, dass weniger Festplattenplatz benötigt wird, die I/O-Zugriffe auf die Platten verringert werden und die Layer mit Hilfe der Btrfs-Snapshots unabhängig voneinander versioniert werden können. Letzteres ermöglicht wiederum auch unterschiedliche Update-Zyklen für die Layer. Außer Facebook setzt sonst wohl nur Suse mit seinen kommerziellen Container-Angeboten derart massiv auf Btrfs.
Systemd als Container-Dienst
Anders als Docker, das einen eigenen zentralen Daemon zum Starten der Container verwendet, setzt Facebook analog zu der Rkt-Containerengine von CoreOS auf Systemd. Facebook reduziert hier im Vergleich zu Rkt(öffnet im neuen Fenster) aber das Einsatzszenario auf das allernötigste und beschränkt sich ausschließlich auf die Verwendung von Systemd-Nspawn, das den Container in einem Namespace startet. Das sei extrem schnell, so Puskas.
In den Containern selbst wird der Init-Daemon von Systemd zum Starten und Verwalten der Anwendungen genutzt. Die Integration der sogenannten Control Groups (Cgroups) in Systemd ermöglicht Facebook zudem eine einfache Kontrollmöglichkeit der zur Verfügung stehenden Systemressourcen für die Anwendungen. Systemd ermögliche es hier außerdem, einfach Log-Dateien aus dem Container heraus zu verteilen.
Der beschriebene Ansatz von Facebook ist im Vergleich zu anderen Container-Systemen sehr minimal, hat laut Puskas aber den klaren Vorteil, das nur Werkzeuge Anwendung finden, die in einer Linux-Distribution sowieso verwendet werden.
Für interessierte Nutzer macht es das zumindest theoretisch sehr einfach, das Container-System von Facebook zu übernehmen. Das Unternehmen plant aber derzeit wohl nicht, daraus ein Open-Source-Projekt zu erstellen. Das gelte insbesondere für den eng an Facebook gebundenen Tupperware-Stack. Ob Facebook dieses als Open Source bereitstellen wird, wollte oder konnte Puskas auf Nachfrage nicht beantworten, die Zukunft vorhersehen könne er aber auch nicht.