Ed Burns: "Container waren zur rechten Zeit am rechten Ort"

Erfolge von Docker und Kubernetes

heise Developer: Auf dem JavaLand leitest du zusammen mit Oliver Szymanski einen Workshop über Docker und Kubernetes. Was sind die Hauptvorteile der Verwendung von Containern anstelle klassischer virtueller Maschinen?

Burns: Der erste Vorteil ist Heterogenität. Bei virtuellen Maschinen verwenden die meisten aktuellen Unternehmensanwendungen eine breite Palette von Standard- und meist Open-Source-Techniken: Prometheus, Grafana, Kibana – alle möglichen Cloud-Modelle werden primär als Docker-Container verteilt und dann mit Kubernetes orchestriert. Das bietet die Freiheit, den eigenen Code als Teil der Geschäftslogik und spezifischen Unternehmensanwendungen zu nehmen und zu containerisieren. Zudem können bereits containerisierte Techniken einbezogen werden, die alle Unternehmen heute verwenden.

Es gibt aber auch einige Herausforderungen bei der gezielten gemeinsamen Verwendung von Java und Containern, da sich die beiden Techniken zu sehr unterschiedlichen Zeiten entwickelt haben. Heutige Container entstanden in den letzten sechs Jahren, Java Virtual Machines hingegen Mitte der 90er-Jahre. Es gilt, Vorkehrungen zu treffen, damit diese beiden weitgehend zusammenarbeiten. Das geschieht, indem man die Metriken, Telemetrie- und Speicherverwaltungsparameter, die die virtuelle Maschine anpassen, mit den Aktionen der Docker-Container und vor allem der Kubernetes-Umgebung synchronisiert. So vermeidet man, dass die virtuelle Maschine unerwartet abstürzt, weil ihr der Heap-Speicherplatz ausgeht und sie immer wieder von Kubernetes neu gestartet wird, obwohl die Anwendung eigentlich nur das tut, was sie normalerweise tut. Werden die Parameter nicht korrekt übergeben, kratzen sich Anwender am Kopf, weil sie nicht wissen, was sie tun sollen.

heise Developer: Mit der Einführung von Docker hat sich die Containerisierung durchgesetzt. Was unterscheidet Docker von früheren Container-Tools?

Burns: Ich bin sehr stolz darauf, so lange bei Sun gearbeitet zu haben, denn in vielerlei Hinsicht war Sun ein sehr technikgetriebenes Unternehmen. Bei einer der frühen Containerlösungen war unsere Herangehensweise, Probleme zu finden und dann zu lösen. Die Geschäftsseite versuchte, einen Weg zu finden, das zu monetarisieren und zu nutzen, während die technische Integrität hochgehalten wurde.

Vieles, was wir heute haben, gab es bereits damals. Für die Containerisierung gab es Solaris Zones, für das Cloud Computing selbst gab es das, was wir Grid Computing nannten – das hatten wir bereits 2004. Um also auf die Frage zurückzukommen, was Docker auszeichnet, und darüber werde ich in der Keynote sprechen: Die Technik und ihre Schöpfer waren zur rechten Zeit am rechten Ort. Wenn du eine wirklich großartige Idee hast, die anderen Dinge um sie herum aber noch nicht in Kraft getreten sind, setzt sich diese Idee nicht durch. Im Fall von Docker glaube ich also, dass es die Allgegenwart von GNU/Linux war, bei deren Etablierung im Wesentlichen Google geholfen hat, und dann der Aufstieg von Cloud-Plattformen, die einen gemeinsamen Anwendungsspeichermechanismus benötigten, den Docker zur Verfügung stellte.

Ein sehr großer Mehrwert von Docker ist die Dockerfile-Sprache, in der du beschreiben kannst, wie deine Container aufgebaut sind. Ein weiteres wirklich wichtiges Feature ist die Popularität des Docker Hub. Bei Docker handelt es sich um einen dieser Fälle, in denen eine bereits vorhandene Idee aufgegriffen, besonders gut umgesetzt und mit einer sehr guten Marketingleistung gekoppelt wurde. Die Docker-Leute wussten, welche Konferenzen sie aufsuchen mussten – Developer Relations war ein wichtiger Faktor –, und sie haben einfach sichergestellt, dass das Produkt die Leute überzeugt.

Alle an einem Strang

heise Developer: Zu den Unterstützern von Docker zählen große Unternehmen wie Microsoft, Red Hat, IBM, Cisco und Google. Wie wichtig war deren Unterstützung für den Erfolg von Docker?

Burns: Das war ebenfalls wichtig. Ursprünglich waren die erwähnten Namen eher skeptisch und warteten ab, ob sich die Technologie durchsetzen würde. Aber zusätzlich zu den bereits erwähnten Bemühungen versuchte Docker, Teil eines offenen Standards zu sein. Es gibt die Open Container Initiative (OCI), die Teil der Linux Foundation ist, wo die anderen konkurrierenden Containertechnologien, insbesondere rkt, sich verpflichteten, den OCI-Standard für das Dateisystem und den Container selbst einzuhalten. Während sie sich in Bezug auf Laufzeitumgebungen und die Art der Virtualisierungstechnologie unterschieden, einigte man sich auf einen gewissen Standard. Das erleichterte den genannten Big Players die Entscheidung, mit an Bord zu kommen.

Das ist eine Erfahrung, die ich schon früh in meiner Karriere gemacht habe: Es entsteht ein Kompromiss zwischen einem Unternehmen, das versucht, eine proprietäre Technologie zu monetarisieren, und einem anderen, das versucht, andere Leute dazu zu bringen, sie zu benutzen, ohne dass sie sich zu sehr darüber Sorgen machen müssen mitzumachen.

heise Developer: Was macht Kubernetes so wichtig für die Orchestrierung von Container-Tools wie Docker?

Burns: Das Kubernetes-Projekt begann bei Google und den Leuten, die es ursprünglich entwickelt hatten – Brendan Burns, mit dem ich im Rahmen meines "Secrets of the Rockstar Programmers"-Projekts gesprochen habe, und seine Kollegen Joe Beda und Craig McLuckie. Burns verließ Google und ging zu Microsoft, wo er für Kubernetes warb. Das ist der übliche Lauf: Microsoft sagt sich, hey, dieses Ding ist erfolgreich, lasst uns die Hauptperson einstellen, ihn involvieren, Azure aufzubauen und vor allem natürlich unser aktuelles Produktportfolio.

Es war also eine Container-Orchestrierung erforderlich, um den gesamten IT-Betrieb zu kodieren, von der Geschäftslogik über die Laufzeitumgebungen bis hin zum DevOps-Teil, der die Telemetrie bereitstellt und es ermöglicht, die Systeme bei Bedarf zu überwachen und angemessen zu behandeln, während die Nachfrage steigt und fällt. Es gab eine Notwendigkeit und dafür verschiedene Angebote. Mesosphere und Kubernetes waren zwei der großen Namen, aber das Gleiche: Bedeutende Investitionen wurden durch das Kubernetes-Projekt getätigt – dabei gebührt Google viel Anerkennung, weil es Kubernetes den Weg freigemacht hat, um sich auf einige der Dinge zu konzentrieren, über die ich in meiner Keynote spreche: eine starke Community, verantwortungsvolle Führung und eine Kerntechnologie, die die Probleme der Menschen löst. Ich denke, das war das Geheimrezept für den Erfolg von Kubernetes.

Pro und contra Container

heise Developer: Welche weiteren neuen Möglichkeiten bieten Docker und Kubernetes?

Burns: Zum Leidwesen einiger der großen traditionellen On-Premises-Lizenzangebote ermöglicht es Unternehmen, ihren bestehenden Stack zu übernehmen und zu migrieren. Es gibt verschiedene Ebenen von "Lift and Shift", aber im Grunde genommen kann der gesamte Geschäftsbetrieb so weit verschlüsselt werden, dass man ihn in eine Commodity-Cloud-Umgebung einbindet und damit einige Kosteneinsparungen erzielt.

Aufgrund meiner Geschichte mit WebLogic und On-Premises Legacy – Monolith, wie einige es spöttisch nennen –, habe ich zudem eine besondere Sichtweise. Weitere neue Möglichkeiten sind mehr Flexibilität und Agilität. Ich kann nun mehrmals täglich eine neue Version meines Stacks einführen, wohingegen es zuvor Monate brauchte, um ein Upgrade auf den Monolithen durchzuführen. Als Entwickler möchte ich den schnellsten Weg, um den Code zu ändern, zu kompilieren, einzusetzen und zu sehen, dass die Änderungen wirksam werden. Aber ich möchte dies auf eine sichere Weise tun, die nichts Vorheriges gefährdet. Daher zählen kontinuierliche Integration und Lieferpraktiken zu den Reifegradfaktoren, die aktiviert werden müssen.

Es gäbe also kein Cloud-basiertes Entwicklungs- und Bereitstellungsmodell ohne ein Sicherheitsnetz, das eine gute kontinuierliche Integrations- und Bereitstellungspraxis bietet. Zusammenfassend lässt sich sagen, Kosteneinsparungen und mehr Agilität sind die beiden großen Möglichkeiten.

heise Developer: Ein Bedenken, das mit Containern einhergeht, ist Sicherheit. Eine beliebte Lösung ist SELinux, das auf dem FLASK-Konzept der NSA basiert – eine Tatsache, die für einige Anwender abschreckend sein könnte. Was ist dein Standpunkt zu diesem Thema?

Burns: Wenn man versucht, Docker in seiner Produktionsumgebung zu verwenden, muss man erkennen, dass man das nicht kostenlos erhält, sondern auf jede Schicht seines Stacks achten muss – beispielsweise bei der Verwendung des Basis-Images von Alpine Linux als Docker-Image. Docker hat ein Vererbungsprinzip: Wenn du deine Docker-Images definierst, kannst du sagen, dass du dieses bestehende Image, zum Beispiel die Alpine Linux Distribution, mitnehmen und einen Haufen zusätzliches Material darüberlegen möchtest. Du erbst also alles, was Alpine Linux bereits hat.

Es ist nicht sicher, einfach zu sagen, gib mir das – du musst dir ansehen, was der Docker Hub hat. Docker hat es ein wenig einfacher gemacht, die Sicherheit zu überprüfen: Ein farbkodiertes Diagramm zeigt die bestehende CVE-Schwachstellen-Datenbank und die bekannten Patches zu diesen Schwachstellen. Hat das Image alle aktuellen Patches? Du kannst tatsächlich sehen, welche es gibt, und es gibt dir eine sehr klare, leicht verständliche Beschreibung der Schwachstelle für jedes Image. Du musst das nur abhängig von deinem Basis-Image überprüfen und sehen, ob es hat, was es braucht.

Wenn du die SELinux-FLASK-Geschichte nicht magst, gibt es ein paar Alternativen. Du könntest dir das Docker Image ansehen und dich fragen, wovon es abhängig ist, und dich dann anstatt auf ein SELinux-Gerät auf ein niedrigeres Fundament verlassen und es selbst aufbauen. Wenn du also einen Image Published Docker Hub hast, kannst du genau sehen, was darin enthalten ist, und sogar das Dockerfile, das verwendetet wurde, um das Image zu erstellen. Das ist eines der Dinge, die zum Erfolg von Docker beigetragen haben: Transparenz anstelle von Undurchsichtigkeit. Sie konnten sich das leisten, weil sie kein Systemanbieter waren. Im Gegensatz zu anderen Anbietern versuchten sie nicht, ihr eigenes Betriebssystem oder ihre eigene Hardware zu verkaufen.