© altomedia, 123RF

Bei der Deutschen Bahn treibt der IT-Dienstleister DB Systel die Containerisierung von Applikationen mittels Open Shift voran. Ein Verantwortlicher berichtet über seine Erfahrungen.

Im März 2013 stellte die kleine, damals noch unbekannte Firma Dotcloud ein System für die Containervirtualisierung vor, das sich durch eine konkrete Vorstellung davon auszeichnete, wie die IT-Zukunft mit Devops-Mitteln zu gestalten sei. Bald darauf nannte sich die Firma um, sie heißt seitdem Docker Inc. und ihre Container erobern landein landaus die Rechenzentren.

Auch mein Arbeitgeber, die DB Systel, der IT-Dienstleister der Deutschen Bahn, erkannte früh ihr Potenzial. So gründete im Herbst 2014 eine Handvoll Enthusiasten eine Inhouse-Community und begann sich Gedanken über den Einsatz von Docker bei der Bahn zu machen. Sie setzten die ersten Buildpipelines auf, und Projekte begannen Docker als Plattform zu verwenden.

Bald schon zeigten sich jedoch große Probleme: Wie behält man bei Hunderten oder gar Tausenden Containern den Überblick? Wie verbessert man die Stabilität der Buildpipelines? Wie lassen sich Monitoring und Logfile-Management realisieren? Auf der Suche nach Antworten begaben sich die Admins der Bahn ein Jahr später auf die Suche nach einem Management- und Orchestrierungstool.

Die Alternativen

Da die DB Systel bereits mit Docker arbeitete, lag die Verwendung von Swarm [1] als Orchestrierungsschicht nahe. Tatsächlich gelang der Einstieg damit relativ einfach, und vorhandene Container beziehungsweise Compose-Dateien ließen sich nahtlos weiterverwenden. Allerdings zeigten sich auch Instabilitäten. Am meisten Sorgen machte uns aber ein drohender Vendor-Lock-in. Außerdem war es schwierig, einen geeigneten Wartungspartner zu finden. Daher haben wir uns entschlossen, neben Docker Swarm noch Apache Mesos und Kubernetes anzuschauen.

Apache Mesos [2] klang vielversprechend und war bereits sehr erfolgreich bei vielen Firmen auch in sehr großen Installationen im Einsatz. Allerdings handelt es sich bei Mesos um einen universellen Clustermanager, den der Anwender erst aufwändig mit einem weiteren Produkt, Marathon, für die Verwendung mit Containern vorbereiten muss. Das aber steigerte die ohnehin schon nicht geringe Komplexität noch einmal erheblich. So wunderte es uns nicht, dass uns die gesamte Installation als sehr komplex und gespickt mit Fallen erschien.

Zwar konnten wir mit Hilfe der Community fast alle Probleme ausräumen, aber Zweifel an der Handhabbarkeit im täglichen Betrieb blieben. Außerdem gestaltete sich auch bei Mesos die Suche nach einem geeigneten Wartungspartner recht schwierig.

Zu der Zeit wurde gerade ein weiteres Orchestrierungstool bekannt und berühmt: Kubernetes [3]. Ab 2014 von Google programmiert, wurde das Tool bereits ein Jahr später der unter dem Dach der Linux Foundation neu gegründete Cloud Native Computing Foundation [4] gespendet. Die Installation gestaltete sich einfach, und wegen der Abstraktionsfähigkeit, der Features und der technischen Ausgereiftheit entwickelte sich bei uns bald eine Präferenz für Kubernetes.

Auf der Suche nach einen potenziellen Wartungspartner nahmen wir auch die Kubernetes-Distribution Open Shift von Red Hat [5] unter die Lupe und führten im Frühjahr 2016 die ersten Gespräche mit dem amerikanischen Linux-Distributor. Es zeigte sich, dass mit Open Shift alle relevanten Betriebsführungsaspekte wie Sicherheit, Stabilität, Monitoring, Logfile-Management und so weiter gelöst waren und mit Red Hat ein professioneller Wartungspartner für alle in Open Shift verwendeten Softwarekomponenten zur Verfügung stand.

Diese Punkte waren uns sehr wichtig, da wir zum einen nicht über genügend personelle Ressourcen verfügten, um selber ein Produkt (weiter) zu entwickeln. Zum anderen wollten wir unbedingt einen Ansprechpartner für alle verwendeten Komponenten, um im Ernstfall nicht zwischen den Stühlen zu sitzen.

Red Hat verwendet offenbar sehr viele Ressourcen darauf, zusammen mit einer riesigen Community die Entwicklung von Open Shift kontinuierlich voranzutreiben. Gerade auch hinsichtlich Sicherheit, Mandantenfähigkeit und Usability – alles Punkte, die in Kubernetes fehlen oder nur sehr schwach ausgeprägt sind. Zudem ist es Firmenpolitik von Red Hat, dass seine Softwareprodukte stets Open Source sind. Damit erledigt sich faktisch auch das Problem eines Vendor-Lock-in, denn es gibt zahlreiche weitere Anbieter mit Distributionen auf der Basis von Open Shift und ein Wechsel wäre problemlos möglich.

So fiel die Entscheidung für Open Shift (Abbildung 1) im Sommer 2016 und ein erster Workshop für den Aufbau wurde organisiert. Allerdings war er wegen mangelnder Kompetenz des Beraters, Sprachbarrieren, überzogener Erwartungen und der unterschätzten Komplexität der DB-Infrastruktur ein großer Reinfall. Fast wäre damit das Thema Open Shift beerdigt worden und es kostete mich viel Kraft, die Scherben zusammenzukehren und einen Neustart zu initiieren.

Abbildung 1: Open Shift vereint zahlreiche nützliche Features für Kubernetes in einer Distribution.

Glücklicherweise konnte ich meinen damaligen Chef von der Notwendigkeit überzeugen und begann zusammen mit einem Kollegen den Aufbau eines ersten Test- und Entwicklungsclusters, der im Herbst 2016 online ging.

Die Entwickler waren von Anfang an begeistert und stellten unisono eine massive Beschleunigung ihrer Arbeit fest. Trotzdem galt es umzudenken, denn es ließen sich beispielsweise nun keine privilegierten Ports mehr verwenden. Damit schieden aber geschätzt 90 Prozent aller Container vom Dockerhub aus der engeren Auswahl aus. Schließlich sorgten hier zahlreiche dokumentierte Usecases und Anwenderschulungen für Abhilfe.

Im Laufe der Zeit reifte die Erkenntnis, dass andere Firmen ähnliche Erfahrungen machen würden und dass es äußerst hilfreich wäre, könnte man sich über die anfallenden Probleme austauschen. So haben wir zusammen mit Red Hat eine Open-Shift-Anwender-Community gegründet [6]. Was mit knapp 30 Teilnehmern am 22. September 2016 begann, ist inzwischen zu einem sehr wichtigen, regelmäßigen Erfahrungsaustausch mit mehr als 150 Teilnehmern angewachsen. Und auch 2019 wird die DB wieder mindestens ein Treffen der Open-Shift-Anwender organisieren.

Nachdem die Geschäftsführung der DB Systel beschlossen hatte, die Rechenzentren des Unternehmens zu verkaufen und alle Applikationen komplett in die Cloud zu migrieren, bauten wir im Sommer 2017 die ersten produktiven Open-Shift-Cluster in AWS auf. Und seit dem 1. Januar 2018 laufen diese auch mit höchstem Servicelevel.

Neben dem Tagesgeschäft stand das Jahr 2018 klar unter dem Motto, wie wir für unsere Kunden den Einstieg in Open Shift und die tägliche Arbeit so einfach wie möglich gestalten können. Aus dieser Überlegung entstand BOSS (Bahn Open Shift Self Service), ein Portal, das es jedem DB-Mitarbeiter in Selbstbedienung ermöglicht, Projekte zu verwalten, Berechtigungen zu vergeben, Verrechnungsdaten einzusehen und so weiter (Abbildung 2). BOSS stieß beim letzten Anwendertreffen auf so großes Interesse, dass wir daran arbeiten, es unter einer Open-Source-Lizenz freizugeben.

Abbildung 2: Das Self-Service-Portal der Bahn für Container, eine Eigenentwicklung.

Außerdem entstand ein System für die Verrechnung der genutzten Ressourcen. Es basiert nicht allein auf dem Verbrauch an CPU, RAM und Storage, sondern bezieht auch verwendete Services mit ein, etwa das Logfile-Management. Das wurde notwendig, nachdem einzelne Applikationen es mit ihren Logfiles auf bis zu 50 GByte Indexgröße pro Tag in Elasticsearch brachten und damit die Infrastruktur massiv belasteten.

Und natürlich hat sich Open Shift in der Zwischenzeit weiterentwickelt – und wir haben dazugelernt. So planen wir, 2019 alle Cluster nach einer neuen Methode (angepasstes AWS Quickstart) neu aufzubauen. Auch wirft Open Shift 4.0 bereits seine Schatten voraus. Es bleibt also auch weiterhin spannend.

Security und Compliance

Zwei wichtige Themen sind hier aber noch genauer zu betrachten: Security und Compliance. Speziell das Thema Sicherheit spielt bei der Deutschen Bahn eine sehr große Rolle. Red Hat betreibt nach meiner Ansicht viel Aufwand, um die Sicherheit von Open Shift zu erhöhen. Beispielsweise hat der Anbieter mit SE-Linux-Regeln und vielen weiteren Maßnahmen Kubernetes mandantenfähig gemacht, die Ausführung von Containern mit Rootberechtigung unterbunden und ein filigranes User-Berechtigungskonzept implementiert. Diese und viele weitere Maßnahmen haben die Sicherheit der Plattform massiv verbessert. Aber woher bekommt man gute und vor allem sichere Containerimages?

Mit Docker-Containern ist es ähnlich wie mit Schiffscontainern: Sie sind praktisch, einfach zu benutzen, man kann alles darin transportieren und sie haben innerhalb weniger Jahre die Welt disruptiv verändert. Aber häufig weiß man nicht so genau, was eigentlich drinsteckt. Wen wundert es also, dass ein findiger Angreifer dies ausnutzte, um in beliebten Containern eine Malware zum Schürfen einer Cryptowährung zu platzieren.

Dass diese Container aber fünf Millionen Mal vom Dockerhub heruntergeladen und wer weiß wie oft ausgeführt wurden, darüber staunt man dann doch [7]. Und obwohl bereits im September 2017 einem Anwender die Schadsoftware aufgefallen war und er sie an Dockerhub meldete, geschah nichts. Der Angreifer mit dem Namen »docker123321« konnte fleißig weitere Images manipulieren und auf Dockerhub verfügbar machen.

Mit Open Shift ist der Anwender nicht in Gefahr, auf so etwas hereinzufallen. In den Subscriptions ist die Erlaubnis enthalten, alle zertifizierten Basisimages von Red Hat zu verwenden [8]. Die prüft der Hersteller permanent hinsichtlich ihrer Sicherheit und baut sie gegebenenfalls neu. Wenn dann die Anwender noch den Trigger »rebuild on new image« gesetzt haben (Abbildung 4), wird automatisch immer die letzte Version verwendet. Die Sicherheit ist deutlich erhöht.

Abbildung 4: Jede Änderung des zugrunde liegenden Basis-Image löst automatisch einen Rebuild aus.

Ein weiteres sehr wichtiges Thema im Enterprise-Umfeld ist Compliance. Unter welcher Lizenz steht eigentlich ein Container? Besteht er wirklich aus reiner Open-Source-Software? Welche Lizenzbedingungen sind bei seinem Einsatz zu beachten?

Bereits die erste Frage ist nur unglaublich kompliziert zu beantworten. Ich möchte das am Beispiel des Linux-Kernels verdeutlichen. Unter welcher Lizenz steht der Linux-Kernel? Viele werden sofort mit GPL 2 antworten. So wird es auch auf der offiziellen Webseite [9] angegeben. Wer aber einen Compliance-Scanner wie Fossology [10] anwirft, kommt zu einem ganz anderen Ergebnis: Im offiziellen Kernel sind Dateien mit über 90 unterschiedlichen Lizenzen enthalten.

Ein weiteres Beispiel ist Open SSL [11]. Laut eigener Webseite stehen die Open-SSL-Versionen vor 3.0 unter einer dualen Lizenz, der Open SSL License und der Original SSLeay License. Allerdings fördert Fossology ein anderes Bild zu Tage und listet insgesamt 19 Lizenzen auf – nach Prüfung und Bereinigung der False-Positive-Meldungen.

In einem Container können Tausende Dateien stecken, die wiederum aus zahlreichen Dateien zusammenkompiliert sind, und die Lizenzbedingungen für jede einzelne Datei sind zu beachten. Somit wird klar, dass man entweder das Copyright vorsätzlich ignorieren kann oder einen sehr aufwändigen Clearingprozess benötigt. Jetzt ließe sich einwenden, dass die Lizenzbedingungen ja nur beim Distributen, also der Weitergabe der Software, zu beachten sind. Das stimmt, allerdings stellt bereits die Weitergabe der Software an eine DB-Tochter ein Distributen dar, da die Software dabei auf eine andere Rechtsperson übergeht.

Außerdem gibt es Open-Source-Lizenzen, beispielsweise die AGPL [12], bei denen die Nutzer der Software eine Downloadmöglichkeit für den Quelltext selbst dann erhalten müssen, wenn die Software nur auf einem Server als Dienst betrieben wird. Das umfasst nicht nur die Sourcen, sondern das Gesamtwerk inklusive aller eventuell enthaltenen Geschäftsgeheimnisse. Neben der rein moralischen Verpflichtung, sich beim Einsatz von Open-Source-Software an die Spielregeln zu halten, hat sich in den letzten Jahren auch das Abmahnen und die Geltendmachung von Schadensersatz bei Verstößen zu einem profitablen Geschäftsmodell entwickelt [13].

Was also tun? Jeden Container vorab einer intensiven Prüfung unterziehen? Das dürfte kaum realistisch sein, da selbst Experten mit einem sehr guten Toolstack mehrere Tage bis Wochen für das Clearing eines einzelnen Containers veranschlagen. Man kann versuchen das Clearing zu automatisieren. Wie es geht, wurde in zahlreichen Vorträgen auf dem diesjährigen Bitkom-Forum Open Source gezeigt [14].

Ausweg: Basisimages

Aber es geht auch einfacher. Als Open- Shift-Kunde von Red Hat haben wir Zugriff auf zertifizierte Basisimages. Das bezieht sich nicht nur auf die Sicherheit, sondern explizit auch auf die Compliance. Red Hat bietet allen Kunden eine Open-Source-Versicherung [15] für die angebotene Software. Die permanenten Scan- und Prüfprozesse stellen sicher, dass Sicherheits- und Compliance-Probleme zeitnah entdeckt und behoben werden. Und sollte einem Kunden von Red Hat durch die Verwendung der Software ein finanzieller Schaden entstehen, dann haftet Red Hat dafür. Somit sind Open-Shift-Kunden sicher, wenn sie Basisimages der Plattform verwenden. Sie müssen “nur” die Compliance ihrer eigenen Software sicherstellen.

Diese zertifizierten Images sind auch die Basis für Source-to-Image (Abbildung 3), einer Technologie, bei der Open Shift aus einem Image und dem Kundencontent on Demand ein neues Image baut und startet. Der Admin wählt aus einem Servicekatalog ein geeignetes Image, etwa einen Apache-, Tomcat- oder Jboss-Server, und gibt im folgenden Dialog die Git-Adresse seines Content ein.

Abbildung 3: Source-to-Image, eine Technologie, die aus einem sicheren Basisimage und dem Content des Kunden neue Images generiert.

Danach wird von Open Shift der Content aus Git ausgecheckt und deployt, das neue Image in die Registry gepuscht, Firewall und Load Balancer werden konfiguriert und ein neuer Pod auf der Basis des gerade erstellten Image gestartet. Dieser Workflow lässt sich sehr einfach automatisieren, sodass jeder Git-Commit automatisch einen Rebuild auslöst und die neue Version sofort getestet werden kann (Abbildung 4).

Während für Entwickler und neue Projekte diese Änderung in der Arbeitsweise sehr einfach zu bewerkstelligen ist, haben sich Admins und Altprojekte zuerst etwas schwer damit getan. Nicht jedem war der Umgang mit Git geläufig und Altprojekte wurden häufig in einem proprietären Paketformat ausgeliefert.

So hängt es stark von der Anwendungsarchitektur ab, wie hoch der Migrationsaufwand ausfällt. Manche Projekte lassen sich problemlos innerhalb eines Tages auf Open Shift migrieren, für andere wiederum ist der Aufwand signifikant höher, gerade wenn kein geeignetes Basisimage zur Verfügung steht und der Anwender erst eigene Images bauen muss.

Zudem ist es sehr oft von Vorteil, auch die Architektur zu ändern, um alle Vorteile der Containerisierung und von Open Shift auszunutzen. Das betrifft etwa die Zerlegung eines großen Monolithen in mehrere kleinere Teile, um die Startgeschwindigkeit der Pods zu erhöhen und somit die Autoskalierung besser nutzen zu können. Ungeachtet des zuweilen erhöhten Aufwands zeigt die Erfahrung, dass es keine unüberwindbaren Hürden gibt und die Vorteile die Migrationskosten bei Weitem übersteigen.

Am Ende stellt sich natürlich die Frage nach der Wirtschaftlichkeit von Open Shift. Leider ist die aber auch nur sehr schwer zu beantworten. Zum einen muss man ganz klar feststellen: Inhouse-Open-Shift lohnt sich nur, wenn man sehr, sehr viele Container betreiben will. Der Overhead für den Betrieb eigener Cluster ist einfach sehr hoch.

Aber bei einem Cluster mit 180 Kundenprojekten und knapp 800 Containern liegen die Plattformkosten inklusive der Kosten für die Betriebsführung (BF) bei ungefähr zwei Dritteln im Vergleich zu AWS nativ. Mit steigender Auslastung wird sich dieser Wert sicherlich noch verbessern, da die Plattform skaliert und die hohen BF-Kosten relativ gleich bleiben.

Viel wichtiger sind aber eine Reihe weiterer Aspekte, beispielsweise die Hochverfügbarkeit. Auch wenn mein Projekt nur aus einem monolithischen Jboss besteht, Open Shift wird dafür sorgen, dass mein Pod läuft – selbst wenn ein Workernode oder gar eine ganze AWS Availability Zone ausfällt. Zwar kann ich das auch mit AWS-Bordmitteln erreichen, allerdings muss ich dafür über entsprechendes Know-how verfügen, und es ist relativ aufwändig.

Ein weiterer wichtiger Punkt ist Geschwindigkeit. Durch das sehr gute API ist Open Shift hervorragend für den Aufbau von Buildpipelines vorbereitet – sei es durch einfache Webhooks, Jenkins oder auch Gitlab CI. Damit lässt sich die Entwicklung massiv beschleunigen. Somit ist Open Shift ein gutes Werkzeug, um mit immer knapper werdenden Entwicklerressourcen zurechtzukommen.

Fazit

Dass die Entscheidung, auf Open Shift als Containerplattform zu setzen, richtig war, wird uns nicht nur von unseren Anwendern und durch wachsende Kundenzahlen bestätigt, sondern jüngst auch von einer Studie [16]. Dieser Studie zufolge ist Red Hat Open Shift nicht nur der Marktführer, sondern grenzt sich in sieben der zehn untersuchten Kriterien stark positiv von den Konkurrenten (Docker, IBM, Mesosphere, Pivotal, Platform9, Rancher Labs, Suse) ab, in den anderen drei Kriterien ist Open Shift gleichgestellt.