© Volodymyr Krasyuk, 123RF

Open Stack bildet zwar einen eigenen Kosmos, kann aber den Container-Trend nicht ignorieren. Anwender wollen beide Technologien kombinieren – hier kommen Projekte wie Magnum, Kolla oder Zun ins Spiel. Das Linux-Magazin hat nachgeschaut, wo es bei der Zusammenarbeit noch knirscht.

Die meisten IT-Anwender nutzen Container à la Docker [1], Rocket [2] oder LXD [3] als Plattform zum Prozessieren von Daten. Auch Cloudlösungen wie Open Stack [4] müssen früher oder später mit Containern umgehen, zurzeit gibt es dafür mehrere Möglichkeiten.

Die naheliegendste besteht darin, die Containertechnologie innerhalb von Open Stack zu verankern. Sie bedient sich solcher Projekte wie Magnum [5] oder Zun [6]. Zunächst weniger offensichtlich ist der umgekehrte Fall: Hier dient die Containertechnik dazu, Open Stack zu betreiben, befindet sich also außerhalb der Cloud. In diesen Zusammenhang gehört das Projekt Kolla [7].

Übrigens: Die Idee, Container als grundlegende Infrastruktur zu verwenden, findet man auch im Projekt GIFEE (Google’s Infrastructure for Everyone Else, [8]). Aus diesem Umfeld kommen auch einige Anstöße für die jüngsten Entwicklungen zum Thema Open Stack auf Containern. Wer will, kann also Container oberhalb von Open Stack oder unterhalb betreiben, und sogar Kombinationen aus beiden sind möglich. Der vorliegende Artikel stellt Container-relevante Open-Stack-Projekte kurz vor, erläutert deren Zielstellung und ihr Zusammenspiel.

Zun

Das Projekt Zun existiert erst seit zirka einem Jahr. Sein Ziel ist die Bereitstellung einer Schnittstelle zum Verwalten von Containern als native Open-Stack-Komponenten, genauso wie beispielsweise Cinder, Neutron oder auch Nova. Es tritt damit die Nachfolge der inzwischen eingestellten Arbeiten an Nova-Docker [9] an. Genau genommen ist Zun eine Weiterentwicklung.

Nova-Docker war eine einfache Methode, um Container in Open Stack zu integrieren. Die Verwaltung erfolgte analog zu virtuellen Maschinen. Diese Abkürzung der Integration brachte aber den Nachteil, dass die Vorzüge der Containertechnik weitgehend außen vor blieben. Docker & Co. sind nun mal keine VMs. Hier kommt nun Zun ins Spiel. Es erlaubt die Verwaltung von Containern als solchen und trotzdem als Bestandteil des Open-Stack-Gesamtwerks.

Das beinhaltet die nahtlose Integration mit anderen Komponenten wie Keystone oder Glance. Dazu kommt die Abstraktion von der jeweils verwendeten Containertechnologie. Der Anwender muss sich nicht mit der Komplexität von Docker versus Rocket versus LXD auseinandersetzen. Diese Abstraktion ist zweifelsfrei ambitioniert. Zun startet daher zunächst bei den Grundlagen – dem simplen Anlegen, Aktualisieren und Löschen von Containern. In der Dokumentation stößt man in diesem Zusammenhang gelegentlich auf den Begriff CRUD (Create, Read, Update, Delete).

01 $ zun run --name pingtest alpine ping -c 4 8.8.8.8
02
03 $ zun list
04  +--------------------------------------+----------+--------+---------+-----------------------------+
05  | uuid                                 |name      | image  | status | task_state | address    | prt|
06  +--------------------------------------+----------+--------+---------+-----------+------------+----+
07  | 36adtb1a-6371-521a-0fa4-a8c204a9e7df | pingtest | alpine | Stopped | None      | 172.17.5.8 | [] |
09  +--------------------------------------+----------+--------+---------+-----+-----+------------+----+
10
11 $ zun logs test
12  PING 8.8.8.8 (8.8.8.8): 56 data bytes
13  64 bytes from 8.8.8.8: seq=0 ttl=40 time=31.113 ms
14  64 bytes from 8.8.8.8: seq=1 ttl=40 time=31.584 ms
15 [...]
16 $
17 $ zun delete pingtest

In Abbildung 1 ist die Architektur von Zun und seine Integration in Open Stack schematisch dargestellt. Zun selbst besteht aus zwei Komponenten. Das ist zunächst das Zun-API, das zur Kommunikation und Interaktion mit dem Anwender dient. Im Hintergrund werkelt Zun-Compute, das über Treiber mit den anderen Open-Stack-Komponenten interagiert und die Ressourcen für Docker & Co. verwaltet, also etwa die Kommunikation mit Glance zum Bereitstellen der notwendigen Abbilder oder mit Neutron für das Netzwerk übernimmt. Hier übernimmt ein weiteres Projekt eine wichtige Rolle: Kuryr [10]. Es bildet quasi die Brücke zwischen den Netzwerk-Welten von Open Stack auf der einen und Containern auf der anderen Seite.

Abbildung 1: Architektur von Zun und die Integration in Open Stack.

Die Zielgruppe von Zun sind Open-Stack-Anwender, die neben Blech und virtuellen Maschinen auch Container benutzen wollen. Die Anforderungen sind recht niedrig. Der Anwender braucht keine besondere Verwaltungssoftware für die Container selbst oder für die darunterliegenden Hosts. Der oben genannte CRUD-Ansatz ist vollkommen ausreichend.

Magnum

Andere Lösungen legen ihren Fokus gerade auf die Verwaltung der Container. Dabei heißen die üblichen Verdächtigen Kubernetes [11], Docker Swarm [12] und Apache Mesos [13]. Kann Open Stack ebenfalls helfen? Ja – und Magnum heißt die entsprechende Antwort. Die Wurzeln von Magnum liegen laut Git-Repository im Jahr 2014. Die erste Veröffentlichung erfolgte 2015. Die ursprüngliche Mission von Magnum lag zwischen CaaS (Container as a Service) und COaaS (Container Orchestration as a Service) mit Schwerpunkt auf Letzterem.

Ziel von Magnum ist es, eine Verwaltungsplattform für Container mit Hilfe von Open Stack [14] bereitzustellen. Die Cloud stellt einfache Mittel und Wege zur Verfügung, um beispielsweise einen Kubernetes-Cluster zu generieren. Ein älterer Artikel zu Magnum [15] ist nicht mehr hundertprozentig kompatibel mit der neuen Ausrichtung des Projekts. Wie Zun zielt auch Magnum darauf, bestimmte Komponenten aus der Containerwelt auf natürliche Weise ins Open-Stack-Gesamtbild einzubetten. Hier geht es nun um so genannte COEs (Container Orchestration Engines).

Im Vergleich zu älteren Architkturversionen von Magnum fällt auf, dass viele Bestandteile wegfallen. Die Konstrukte Container, Pod und Service interessieren in der neuen Ausrichtung nicht mehr. Jetzt sind Cluster (vormals Bay) und Cluster-Vorlage (vormals Bay-Modell) die zentralen Bausteine. Aus Open-Stack-Sicht kommt noch Heat dazu.

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 $

Fängt der Anwender auf der grünen Wiese an, gilt es zunächst, die Cluster-Vorlage zu erstellen. Wichtige Angaben sind hier die zu verwendende Orchestrierungssoftware und die Abbilder für die Generierung der Server. Der Teufel steckt hier allerdings im Detail. Bei Bedarf kann Magnum auch eine private Registratur für das Ablegen der Container-Abbilder verwenden. Dann muss der Benutzer zusätzliche Angaben zur Größe des Datenspeichers machen und welcher Treiber für den Zugriff nötig ist.

Andere Spezifikationen betreffen die Netzwerkadressen der zu verwendenden DNS-Server oder auch Angaben, wie die Container Daten nicht-flüchtig ablegen können. Für die ersten Schritte lohnt es sich, hier auf die mitgelieferten Vorlagen zurückzugreifen.

Mit dieser Vorlage kann der Benutzer dann den tatsächlichen Cluster mit Open-Stack-Mitteln und auf der zugeordneten Infrastruktur anlegen. Hinter den Kulissen werkeln zwei Programme. Da ist einmal der Magnum-API-Server. Er organisiert die Schnittstelle nach außen: Er nimmt Anfragen entgegen und gibt entsprechend Auskunft. Für Ausfallsicherheit oder einfache Skalierung besteht die Möglichkeit, mehrere API-Server gleichzeitig laufen zu lassen.

Anfragen an die Schnittstelle leitet der Prozess an die zweite Magnum-Komponente – den so genannten Conductor – weiter. Der interagiert mit entsprechenden Orchestrierungsinstanzen.

01 $ ps auxww|grep -i magnu
02 stack17987 0.1 1.2 224984 49332 pts/35S+15:450:19 /usr/bin/python /usr/bin/magnum-api
03 stack18984 0.0 1.4 228088 57308 pts/36S+15:450:06 /usr/bin/python /usr/bin/magnum-conductor
04 $
05 $

Mancher fragt sich nun vielleicht, welchen Mehrwert Magnum für den Anwender bringt. Tatsächlich lassen sich Kubernetes oder Mesos oder Docker Swarm komplett ohne Open Stack betreiben. Magnum zielt auf jene Anwender, die ihre Container innerhalb der freien Wolke verwalten wollen.

Dabei kann Open Stack über die reine Infrastruktur hinaus echten Mehrwert liefern: Durch die Keystone-Integration ergeben sich auf ganz natürliche Weise Mandantenfähigkeit und andere Sicherheitsmechanismen. Designbedingt ist es nicht möglich, Container verschiedener Open-Stack-Kunden auf einem Host laufen zu lassen. Diskussionen, ob dem Hypervisor oder dem Docker-Host zu trauen ist, sind damit nahezu hinfällig.

Mit Zun und Magnum lassen sich Container individuell oder als Teil eines Ganzen mit Bordmitteln von Open Stack verwalten. Es stellt sich allerdings die Frage, ob sich dies auch kombinieren lässt. Die Antwort lautet: Ja, aber …

Zwischenfazit

Im strengen Sinne gibt es keine direkte Verbindung zwischen Magnum und Zun. Der Vermittler zwischen beiden Open-Stack-Projekten sind die COEs, also die Containerverwaltung. Neben Docker & Co. kann diese auch das von Zun bereitgestellte API ansteuern. Die möglichen Operationen sind dann natürlich auf den kleinsten gemeinsamen Nenner der Container-Implementierungen beschränkt – aber mehr kann Container as a Service nach Open-Stack-Art sowieso nicht liefern.

Das Mischen von Zun und Magnum ist allerdings nicht zu empfehlen. Beide Projekte bedienen unterschiedliche Zielgruppen, die Kombination ist eher von akademischem Interesse. Geht es um die Verwendung einzelner Container als native Open-Stack-Ressource, dann ist Zun die richtige Wahl. Beispiele wären isolierte Tests oder Entwicklungen, die höchstens eine Handvoll Docker-Instanzen benötigen. Soll Open Stack aber als Basis für komplexere Anwendungen dienen – inklusive eines Managements des Lebenszyklus und der Infrastruktur um die Container herum –, dann ist Magnum die bessere Wahl.

Kolla

Bisher waren Anwender die Zielgruppe des Artikels, die neben klassischen physikalischen oder virtuellen Rechnern auch auf Docker & Co. zurückgreifen wollen. In jüngerer Zeit gibt es ein verstärktes Interesse an Containern als Basis für die gesamte Verwaltung der freien Open-Source-Wolke.

Genau genommen gibt es sogar zwei Strömungen. Eine sieht die Container-Technik an sich als Grundgerüst für den Betrieb von Open Stack. Das Projekt Kolla passt da sehr gut. In der Containerwelt hat sich der Aufmerksamkeitsfokus aber schon längst auf die Verwaltung von Docker & Co. verschoben. Die schon zuvor genannten Kubernetes, Mesos oder Docker Swarm sind damit in den Scheinwerferkegel gewandert.

Das ist die Basis für die zweite Strömung von Open Stack oberhalb von Containern. Hier spricht der Fachmann dann beispielsweise von Open Stack auf Kubernetes. Ein bekanntes Projekt ist Stackanetes [16] aus der Zusammenarbeit von Core OS und Google. Im Folgenden dreht sich alles um Kolla, da es ein Open-Stack-Projekt ist und auf diesen speziellen Anwendungsfall abzielt.

Abbildung 2 zeigt die Architektur des Container-Unterbaus für Open Stack. Das Projekt selbst ist dabei gar nicht so neu. Die ersten Einträge im Git-Repository reichen in das Jahr 2014 zurück – Kolla ist damit sogar älter als Magnum. Hintergrund waren Unzulänglichkeiten in den bis dahin verwendeten Methoden zur Aktualisierung von Open Stack ohne Ausfallzeiten für den Nutzer. Auf der Projekt-Seite [17] finden Leser drei entsprechende Anwendungsfälle.

Abbildung 2: Die Architektur von Kolla in einer schematischen Darstellung.

Nummer eins ist die Aktualisierung des Gesamtkonstrukts Open Stack. Das entspricht also dem Wechsel von einer Version der freien Cloud auf die nächste. Als Kolla entstand, entsprach dieser Ansatz dem Standard und war eigentlich die einzige Methode, um Open Stack auf den aktuellen Stand zu bringen. Die beiden anderen Anwendungsfälle beziehen sich auf einzelne Komponenten von Open Stack – sprich: die Aktualisierung oder das Downgrading derselben.

Der Gedankensprung zur Verwendung von Docker & Co. ist nun nicht mehr so groß. Das Containerisieren von Open Stack ist allerdings nicht trivial und erfordert einige Vorüberlegung. Welche Dienste sind fundamental, damit andere Dienste oder das Grundgerüst funktionieren? In welcher Reihenfolge sind die einzelnen Dienste zu instanzieren? Ist es ratsam, bestimme Komponenten fest zu verdrahten, um die Installation und den Betrieb zu vereinfachen? Ist eine Container-Verwaltungssoftware empfehlenswert oder gar nötig?

Das Design von Kolla beruht auf zwei Komponenten: einzelnen Containern und Containersätzen. Beide müssen besonderen Anforderungen genügen, die unter [17] genau dokumentiert sind. Kolla definiert so genannte Top-Level-Container. Diese entsprechen den Grunddiensten von Open Stack.

Alle Kontrollinstanzen, beispielsweise der Neutron-Server oder die Glance-Registratur, gehören zur Gruppe Open Stack Control. Unter Open Stack Storage findet man Cinder oder auch Swift. Eine genauere Auflistung bietet Tabelle 1.

Für den tatsächlichen Betrieb kann der Anwender auf vorgefertigte Container-Abbilder des Projekts zurückgreifen oder diese selbst bauen [18]. Zum gegenwärtigen Zeitpunkt wird nur Docker als Container-Technologie getestet und unterstützt. Die Abbilder selbst können sowohl im öffentlichen Docker-Hub oder in einer privaten Registratur liegen.

Für die eigentliche Installation von Open Stack sind prinzipiell zwei Wege vorstellbar. Erstens das Austeilen und Starten/Stoppen der Container-Instanzen zu Fuß. In Zeiten der Automatisierung sicherlich nicht erstrebenswert. Die Alternative ist die Verwendung einer Verwaltungssoftware. Innerhalb von Kolla gibt es zwei Möglichkeiten: Kubernetes ([11], [19]) und Ansible ([20], [21]). Die zugehörige Infrastruktur muss der Anwender zunächst selber einrichten.

Bei Ansible ist man damit deutlich schneller am Ziel als beim Aufsetzen eines Kubernetes-Clusters. Das ist allerdings noch keine Wertung. Ansible kommt eher aus dem Bereich Konfigurationsverwaltung und deckt viele Anwendungsfälle außerhalb der Containerwelt ab. Kubernetes hingegen betrachtet das Beherrschen von Docker & Co. als seine Hauptaufgabe. Was der Benutzer am Ende verwenden sollte, richtet sich stark nach den Gegebenheiten der IT-Landschaft, in der Kolla laufen soll. Der Autor dieses Artikels entscheidet sich jedenfalls in vielen Fällen eher für Kubernetes.

Was am Ende übrig bleibt

Wer Container und Open Stack verbinden möchte, kommt an den Projekten Zun, Magnum und Kolla nicht vorbei. Während Zun und Magnum eher auf die Anwender von Open Stack zielen, ist Kolla mehr für Admins der freien Open-Source-Wolke gedacht. In jedem Fall kommt der Container-Fan aber auf seine Kosten. Zum Thema Open Stack auf Containern lohnt es sich zudem, sich auch außerhalb von Open Stack umzuschauen – Stichwort: Stackanetes.