© Noam Armonn, 123RF.com

Sowohl Docker als auch Open Stack ziehen als schnell wachsende Flotten durch die Welt. Wo sie sich kreuzen, darf man also besondere Brisanz erwarten. Seit Anfang 2015 gibt es genau ein solches Projekt am Schnittpunkt der beiden Technologien: Magnum. Das Linux-Magazin gibt einen ersten Überblick.

Es steht außer Frage, dass Docker [1] einen Hype ausgelöst hat. Allein die Tatsache, dass Microsofts neuestes Betriebssystem diese Technologie unterstützt [2], spricht Bände. Schon seit etwas längerer Zeit surft auch Open Stack [3] auf seiner eigenen Hype-Welle. Nun gibt es unter dem Namen Magnum einen Berührungspunkt zwischen den beiden vielberedeten Projekten.

Genau genommen kann Open Stack allerdings schon seit der Version Havana mit Docker umgehen [4]. Doch die Geschichte ist etwas komplizierter: Bisher gelang die Integration der Containertechnik über das Open-Stack-Compute-Modul Nova. Den Puristen hat diese Art der Einbindung von Docker als Hypervisor-Treiber [5] allerdings nie richtig gefallen. Natürlich war das am einfachsten und ein paar Gemeinsamkeiten mit KVM und Konsorten hat Docker ja auch tatsächlich. Dennoch sind Container nun mal keine Hypervisoren.

So wäre das Aufbohren des Nova-API für Container zwar prinzipiell möglich, sauberer ist allerdings die Entwicklung einer eigenen Schnittstelle. Die Chance, neue oder andere Entwicklungen in der Containerwelt ebenfalls zu integrieren, beispielsweise Rocket [6], sind dann ebenfalls höher. Genau an dieser Stelle setzt Magnum ([7], [8]) an. Als neuer Open-Stack-Schnittstellendienst bietet es CaaS – Container as a Service.

Schnittstellen und Dirigenten

Im Januar 2015 gab Adrian Otto von Rackspace die Veröffentlichung der ersten Version von Magnum bekannt [9]. Die Eckdaten sind schnell aufgezählt: Die Software steht unter der Apache-Lizenz [10] und ist in Python [11] geschrieben. Seit Ende März findet sich Magnum offiziell auf der Liste der Open-Stack-Projekte [7]. Die technische Leitung hat der schon erwähnte Adrian Otto [12] inne. Das primäre Ziel ist es, eine Open-Stack-Schnittstelle zur Orchestrierung von Containern bereitzustellen.

Hinter den Kulissen werkeln zwei Programme (Listing 1). Da ist einmal der Magnum-API-REST-Server. Er bildet die Schnittstelle nach außen: Er nimmt Anfragen entgegen und gibt Dritten Auskunft. Für Ausfallsicherheit oder einfache Skalierung besteht die Möglichkeit, mehrere API-Server gleichzeitig laufen zu lassen. Anfragen an die Schnittstelle beantwortet der Prozess nicht selbst, sondern leitet sie an die zweite Magnum-Komponente – den so genannten Conductor – weiter. Dieser interagiert dann mit den Container- beziehungsweise den entsprechenden Orchestrierungsinstanzen. Eine Skalierung des Magnum-Dirigenten durch den Betrieb mehrerer Instanzen ist im Moment noch nicht möglich, aber fest geplant.

01 $ ps auxww|grep -i magnu
02 stack    19778  0.1  1.2 224984 49332 pts/30   S+   12:20   0:16 /usr/bin/python /usr/bin/magnum-api
03 stack    19844  0.0  1.4 228088 57308 pts/31   S+   12:20   0:03 /usr/bin/python /usr/bin/magnum-conductor
04
05 $ which magnum
06 /bin/magnum
07
08 $ magnum --version
09 0.2.2
10

An dieser Stelle wird klar, dass das Magnum-Projekt eigentlich gar keine Schnittstelle zur direkten Verwaltung von Linux-Containern ist, sondern eher ein API für die Container-Orchestrierung. Zum gegenwärtigen Zeitpunkt unterstützt die Software das Zusammenspiel mit Kubernetes [13], Docker Swarm [14] und Mesos [15].

Wer sich die Orchestrierungssoftware der Docker-Erfinder genauer angesehen hat, vermutet zu Recht, dass eine Ansteuerung einzelner Container über Magnum ebenfalls möglich wäre. Schließlich benutzt Swarm dasselbe API [14]. Aber noch einmal: Magnum versteht sich als Schnittstelle zur Verwaltung der Container, nicht als direkte Schnittstelle zu den Containern selbst.

Installationsvoraussetzung

Damit Magnum mit Kubernetes oder Swarm in Kontakt treten kann, müssen die erst mal vorhanden sein. Das heißt, wer CaaS bieten will, muss auf der grünen Wiese anfangen und die entsprechende Infrastruktur erst mal implementieren. Dazu greift Magnum auf die Open-Stack-interne Orchestrierung – also Heat – zurück. Entsprechende Vorlagen sind Teil des Projekts.

Im Labor des Linux-Magazins kam Open Stack in der Spielart Devstack [16] zum Einsatz, das auf Wunsch gleich vier Magnum-Vorlagen für Heat automatisch installiert (Listing 2). Von denen sind zwei nicht nutzbar, weil das zugehörige Glance-Objekt fehlt.

01 $ magnum-template-manage list-templates --details
02 +------------------------+---------+-------------+---------------+------------+
03 | Name                   | Enabled | Server_Type | OS            | COE        |
04 +------------------------+---------+-------------+---------------+------------+
05 | magnum_vm_atomic_k8s   | True    | vm          | fedora-atomic | kubernetes |
06 | magnum_vm_atomic_swarm | True    | vm          | fedora-atomic | swarm      |
07 | magnum_vm_coreos_k8s   | True    | vm          | coreos        | kubernetes |
08 | magnum_vm_ubuntu_mesos | True    | vm          | ubuntu        | mesos      |
09 +------------------------+---------+-------------+---------------+------------+
10 $
11 $ glance image-list
12 +--------------------------------------+---------------------------------+-------------+------------------+-----------+--------+
13 | ID                                   | Name                            | Disk Format | Container Format | Size      | Status |
14 +--------------------------------------+---------------------------------+-------------+------------------+-----------+--------+
15 | 1d4a3b18-e48a-4554-aa19-6845b1938d69 | cirros-0.3.4-x86_64-uec         | ami         | ami              | 25165824  | active |
16 | 2bbf1d2a-75d8-4c1b-a9e1-2ff65d5ff725 | cirros-0.3.4-x86_64-uec-kernel  | aki         | aki              | 4979632   | active |
17 | 95fe59ac-920f-43f0-964c-1aabdd972b0d | cirros-0.3.4-x86_64-uec-ramdisk | ari         | ari              | 3740163   | active |
18 | 58ac680d-f640-4af0-83e5-23d417ab4f70 | fedora-21-atomic-3              | qcow2       | bare             | 770179072 | active |
19 +--------------------------------------+---------------------------------+-------------+------------------+-----------+--------+

In den Tests gab es auch immer wieder Schwierigkeiten, sobald man abseits des Kubernetes-Weges wanderte. Weitere Informationen liefert der Kasten “Auf ins Getümmel”. Magnum setzt voraus, dass die notwendige Software Teil des Glance-Objekts ist oder, wenn es in den Image-Service noch nicht eingegliedert ist, im Rahmen der Installation der entsprechenden Nova-Rechenkomponente dort landet.

Auf ins Getümmel

Es gibt mehrere Möglichkeiten, die ersten Schritte mit Magnum zu machen. Als noch recht junges Projekt empfiehlt es sich, für den Start möglichst tagesaktuelle Software für alle notwendigen Komponenten zu verwenden. Für die erfolgreiche Installation von Open Stack gibt es verschiedene Ansätze und Möglichkeiten. Um möglichst nahe an Magnum zu bleiben, sollte der Admin Devstack verwenden.

Als Betriebssystembasis eignen sich am besten Ubuntu, Fedora oder Open Suse. Weitere Details sind in der Schnellstart-Anleitung für Entwickler dokumentiert. Wenn möglich, sollte ein gut ausgestatteter physischer Server als Grundlage dienen. Das beste Zusammenspiel mit Magnum bieten derzeit Kubernetes als Orchestrierungslösung mit Atomic als Docker-Host. Aber diese haben nun mal ein Mindestmaß an Anforderungen.

Damit ist die COE-Frage (COE: Container Orchestration Engine) eigentlich auch schon beantwortet. Wer die Herausforderung nicht scheut, kann hier noch Swarm oder Mesos wählen. Empfehlenswert ist das aber nicht. Insbesondere das Apache-Projekt Mesos ist ein Abenteuer für sich.

Wer lieber Core OS als Docker-Basis einsetzt, muss an zwei Stellen nachhelfen. Das Glance-Objekt muss die Eigenschaft »os_distro« besitzen (Abbildung 1). Für den dort vermerkten Wert muss es eine entsprechende Vorlage in der Open-Stack-Orchestrierung Heat geben.

Abbildung 1: Für Magnum muss ein Glance-Objekt bestimmte Eigenschaften besitzen, beispielsweise »os_distro«.

Die Container-Orchestrierung durchzieht mehrere Abstraktionsschichten. Zunächst den Dienst, den der Open-Stack-Benutzer anbieten oder benutzen möchte. Das kann im einfachsten Fall ein Webserver sein, der lediglich statische Seiten liefert. Realistischer ist aber ein Setup, das aus mehreren Softwarekomponenten besteht, die zwar separat laufen, dann aber zusammenspielen müssen.

Eine Schicht darunter liegt Orchestrierungssoftware für die Linux-Container. Die Dokumentation und auch der Reifegrad der Software zeigen, dass der Fokus ganz klar auf Kubernetes liegt. Die logische Gruppierung von Containern heißt bei Magnum nämlich ebenfalls Pod – ein Begriff, der eins zu eins aus der Google-Welt der Containerverwaltung stammt. Eine weitere Schicht darunter befinden sich dann die Container.

Weitere Abstraktionsschichten lassen sich am besten erkennen, wenn man Magnum quasi von unten aufrollt. Das ist zunächst das Konstrukt Bay, das Docker-Hosts zusammenfasst. Im Magnum-Sprech heißen Letztere übrigens Nodes. Um die Bays einfach erzeugen zu können, gibt es Vorlagen, die auf den Namen Bay-Modell hören. Der wesentliche Unterschied ist hier die verwendete Orchestrierungssoftware. Für Bay-Vorlagen heißt sie Container Orchestration Engine oder kurz COE (Listing 2). Weitere Konfigurationsmöglichkeiten listet die Onlinehilfe des Magnum-Clients oder auch die Dokumentation [17].

Abbildung 2 zeigt die eben dargestellten Zusammenhänge in vereinfachter Form. Die wesentlichen Punkte sind die beiden Serverkomponenten von Magnum, das Verwenden von Orchestrierungssoftware für Open Stack und Docker sowie die Abstraktionsmodelle.

Abbildung 2: Die Architektur von Magnum im Überblick.

Der Admin möge sich nicht von der einfachen Darstellung täuschen lassen. In der Praxis gibt es viele Details bei der Verwendung von Magnum zu beachten. Erste Hinweise bietet der Kasten “Auf ins Getümmel”. Kenner der Materie ahnen auch, dass es schwer ist, eine einfache Schnittstelle für Kubernetes, Swarm und Mesos bereitzustellen.

Des Weiteren bietet Magnum ein Hochverfügbarkeitskonzept. Das Stichwort lautet Replication Controller (RC) und basiert auf Pods-Gruppen. Dieses Konstrukt stellt sicher, dass immer die gewünschte Anzahl an notwendigen Prozessen läuft, um den vorgesehenen Dienst bereitzustellen. In der Praxis generiert der Anwender zunächst den Pod, dann den Dienst und stülpt zum Schluss den Replication Controller darüber.

Zur Sicherheit

Die bislang strapazierte Motivation für Magnum war der Wunsch, in Open Stack Container-Spezifika zu nutzen, die über das Hypervisor-Konzept hinausgehen. Das Implementieren von CaaS als eigenen API-Dienst hat aber noch zwei weitere Konsequenzen, die sich auf natürliche Weise ergeben und die auch beabsichtigt sind: Durch Magnum sind Container nun eine eigenständige und per Open Stack ansteuerbare Ressource. Damit reiht sich CaaS in Dienste wie DBaaS (Database as a Service, Trove [18]) ein.

Mit Magnum lassen sich Linux-Container über Open Stack als Dienst anbieten. Die Anbindung als Hypervisor-Treiber für Nova erlaubte dies nicht. Im Idealfall kann sich der Benutzer jetzt komplett auf die Containeranwendung konzentrieren und braucht keinen Gedanken an die Compute-Infrastruktur mehr zu verschwenden.

Die zweite Konsequenz der Existenz als separate Open-Stack-Komponente ist die Keystone-Integration. Auf ganz natürliche Weise ergeben sich Mandantenfähigkeit und andere Sicherheitsmechanismen. Design-bedingt ist es nicht möglich, Docker-Container verschiedener Open-Stack-Kunden auf einem Host laufen zu lassen. Diskussionen, ob man dem Hypervisor oder dem Docker-Host trauen kann, sind nahezu hinfällig.

Wie geht’s weiter?

Die Trennung von Container und Hypervisor ist ein Schritt in die richtige Richtung. Dem Open-Stack-Admin stehen nun alle Möglichkeiten offen. Sieht der Anwendungsfall die Container eher im Hypervisor-Kontext, dann ist die Nova-Schnittstelle eine gute Wahl. Stehen dagegen Docker und Konsorten im Mittelpunkt, dann ist Magnum eindeutig der bessere Partner.

Das Projekt an sich ist noch recht jung und starken Änderungen unterworfen. Eine Teilschuld daran tragen aber die Linux-Container selbst. Dort bewegt sich ebenfalls viel und Magnum ist gewissermaßen das Opfer dieser Entwicklungen. Mit Adrian Otto hat das Container-Projekt innerhalb von Open Stack keinen Namenlosen als Förderer. Wünschenswert wären deutliche Zeichen für die Integration von Rocket und LXC [19].