Das Docker-Projekt wird 10! Ein Rückblick auf ein Jahrzehnt mit Containern
17. März 2023
0 Min. LesezeitAm 15. März 2023 jährte sich Solomon Hykes’ berühmter PyCon-Kurzvortrag zum zehnten Mal, in dem er der Welt Docker vorstellte.
Werfen wir einen Blick darauf, was sich alles verändert hat, und hören wir von einigen Menschen, die Geschichten über ihren Weg in die containerisierte Welt erzählen, in der wir heute leben. Ich habe mein kleines schwarzes Buch mit Kontakten aus den Bereichen Container und Cloud Native aufgeschlagen und sie gebeten, von ihren ersten Begegnungen mit Docker und von besonderen Erlebnissen aus den zehn Jahren zu erzählen, seit wir Moby und Molly zum ersten Mal kennengelernt haben.
Hallo wowrld!
2013 wurde Docker der Welt vorgestellt. Für viele Entwickler war es der erste Kontakt mit den Konzepten von Cgroups, Namespaces und anderen Linux-Technologien, die dazu dienen, Prozesse zu „isolieren“. Wie die Docker-Leute gerne sagen, haben sie Container-Technologie „demokratisiert“ und ihre Nutzung vereinfacht – ganz ohne Abschluss in Linux-Systemadministration.
Umwerfend und magisch
Als ich Menschen nach ihren ersten Erfahrungen mit Docker fragte, fielen bestimmte Adjektive immer wieder: magisch, umwerfend und „Aha-Moment“.
Stellen Sie sich vor: Portland, Oregon, 2013, auf der Oreilly OpenSource Conference. Docker war erst ein paar Monate zuvor als Open-Source-Projekt gestartet und gewann bereits in verschiedenen IT-Communitys an Popularität: Open Source, Cloud, DevOps und mehr. Es war der letzte Konferenztag, und ich besuchte am frühen Freitagmorgen eine Session über dieses neue Ding namens Docker! Der Vortragende war Solomon Hykes, der direkt in die Konzepte der Container-Schicht eintauchte und die Möglichkeiten sowie die zugrunde liegenden Technologien erläuterte. Zum Abschluss zeigte er eine Demo. Wenn ich mich richtig erinnere, startete er innerhalb von Sekunden 5, 10, 15, 20! apache/httpd-Container. Selbst für das kleine, verschlafene Publikum an diesem Morgen – und besonders für mich – war das atemberaubend ... Ich hatte sofort das Gefühl, Zeuge eines Paradigmenwechsels zu werden, und wollte alles darüber wissen!
Ich weiß, dass Docker nicht als Erstes die zugrunde liegenden Technologien zusammenführte, um isolierte Prozesse und Container zu schaffen. Doch die damals gezeigte – und bis heute erhaltene – Benutzerfreundlichkeit war magisch.
- Nirmal Mehta, Principal Specialist SA bei AWS
Ich erinnere mich an meine erste Nutzung von Docker, nachdem ich zuvor eine VM eingerichtet hatte, um nginx mit Tools wie Ansible und Chef auszuführen. Eine Stunde lang erstellte ich ein Playbook, richtete es für die gestartete VM ein und wartete dann, bis die Installation durchgelaufen war. Anschließend führte ich den Docker-Befehl zum Starten von nginx aus – und weniger als 30 Sekunden später lief der Prozess in dieser magisch isolierten Umgebung. Das war der Moment, der meine Entdeckungsreise auslöste: Was war da gerade passiert und wie funktionierte Docker?
- Brandon Mitchell, Solutions Architect bei BoxBoat, einem IBM-Unternehmen
Docker zu entdecken war, als würde man magische Kräfte entdecken. Ähnlich war es, als Virtualisierung Server ablöste und mir die Möglichkeit gab, VMs in physischer Infrastruktur zu bündeln und diese besser auszulasten. Docker fühlte sich an, als würde man in eine weitere Traumebene hinabsteigen – jetzt konnte ich Anwendungen in VMs bündeln und die Hardware noch besser nutzen.
- Adrian Goins, ehemaliger Developer Advocate bei Rancher/SUSE
Anfang 2015 bat mich mein Arbeitgeber, Docker-Experte zu werden. Ich wusste kaum etwas darüber, abgesehen von ein paar Beiträgen auf der Orange-Website, und fing an, damit zu experimentieren. Wie alle begann ich mit dem klassischen Docker-Hello-World-Beispiel für Nginx. Mein „Aha-Moment“ kam sofort. Als langjähriger Systemadministrator erkannte ich in der Prozessisolierung einen gewaltigen Fortschritt. Von da an richtete ich meinen gesamten beruflichen Fokus auf Container aus. Ich hatte das Glück, die US-Regierung dabei zu unterstützen, Container in zahlreichen Behörden einzuführen. Eineinhalb Jahre später konnte ich meine Docker-Reise glücklicherweise fortsetzen und dem Unternehmen beitreten.
- Andy Clemenko, Field Engineer bei Rancher Government Solutions
Das Weltuntergangsszenario
David Flanagan, der Docker bereits im ersten Jahr nutzte, erkannte schnell, wie die Technologie Bereitstellungen in seinem Unternehmen revolutionieren könnte.
Zum ersten Mal hörte ich 2013 bei Solomons PyCon-Demo von Docker. Damals arbeitete ich als Entwicklungsleiter für ein britisches Radio- und Zeitschriftenunternehmen und versuchte, das Unternehmen ins 21. Jahrhundert zu bringen ... digitale Transformation, Sie wissen schon. Das größte Problem war die Skalierung. Wir hatten sogar ein „Weltuntergangsszenario“: „Was machen wir, wenn Lemmy von Motörhead stirbt?“ Unsere Auslastung war äußerst vorhersehbar – bis sie es nicht mehr war. Nachrichten lassen sich nicht vorhersagen, und man muss so schnell wie möglich in Echtzeit skalieren.
Wir hatten bereits eine Weile Vagrant und VMs verwendet, doch sie schnell zu skalieren, war mühsam. Wir mussten frühzeitig überprovisionieren und nach dem „Ereignis“ schnell wieder zurückskalieren, um Kosten zu senken. Als wir Docker sahen, ging uns ein Licht auf. Allerdings ... gab es damals noch kein „docker build“. Kurz darauf folgte der Befehl, und Docker führte den bis heute verwendeten Slogan ein: „Build. Ship. Run“. Das Team löste nicht nur das Laufzeitproblem, sondern machte auch die Entwicklererfahrung beim Erstellen von Container-Images unglaublich einfach und ermöglichte deren Verteilung („Ship“). Kubernetes und Cloud Native verdanken dem frühen dotCloud-Team sehr viel – ganz gleich, welche Container-Runtime wir heute verwenden.
- David Flanagan, Gründer der Rawkode Academy
Das Grid stabilisieren
Auch ich nutze Docker seit den allerersten Tagen und – wenn ich so frei sein darf – so lief es bei mir.
Ende 2013 begann ich, mit Docker zu experimentieren und es in unseren CI-Pipelines einzusetzen. Unsere Aufgabe war es, für jeden Commit einer großen E-Commerce-Webanwendung Hunderte von funktionalen End-to-End-Tests auszuführen. Während der Spitzenzeiten liefen oft mehr als 2.000 Browser-Instanzen über VM-basierte Selenium2-Grids. Ein ständiges Ärgernis waren fehlerhafte Testergebnisse aufgrund von Stabilitätsproblemen im Grid. Wir starteten und beendeten fortlaufend Instanzen in der Cloud und probierten im Laufe der Jahre zahlreiche Strategien aus, um die Startzeiten zu verkürzen, die Stabilität zu verbessern und Kosten zu senken. Wir testeten sogar Spot-Instances und lieferten uns in verschiedenen Regionen regelrechte Bieterschlachten!
Wir hatten Docker bereits für die Webanwendung und die Test-Suite-Controller ausprobiert. Mein Aha-Moment kam jedoch, als mir klar wurde, dass ich ein Image mit Browser und xvfb erstellen und sofort starten konnte. So konnten wir stabile Selenium-Grids mit so vielen Browsern betreiben, wie auf einen einzelnen Knoten passten! (Unsere Stabilitätsprobleme im Grid rührten meist daher, dass ein Knoten nicht genügend Browser ausführen konnte. Daher brauchten wir viele kleine Knoten mit wenigen Browsern auf jedem.) Das funktionierte so gut, dass wir die Cloud-Instanzen größtenteils aufgeben und die Grids mit nur wenigen lokalen VMs betreiben konnten – und so Tausende Dollar pro Woche sparten.
- Eric Smalling, Senior Developer Advocate bei Snyk
Die breite Masse überzeugen
Wer neu in der Entwicklung von Unternehmenssoftware ist, hält die Vorteile von Containern und des dazu entstandenen Ökosystems vielleicht für selbstverständlich. Doch in den ersten fünf oder sechs Jahren war die Zukunft von Docker alles andere als sicher.
Die Ergebnisse sprechen für sich
Veränderungen fallen Menschen oft schwer, doch die greifbaren Vorteile von Docker überzeugten schnell:
Ich hatte schon öfter neue, glänzende Technologien eingeführt. Deshalb lag stets ein gewisser Frust in der Luft, wenn es hieß: „Dave hat wieder ein neues Spielzeug.“ Außerdem nutzte der Großteil meines Teams Macs, und die Leute waren definitiv nicht begeistert von mir!
Docker war bei uns jedoch größtenteils serverseitig im Einsatz. Boot2docker gab es noch nicht, deshalb blieb das Team für die Entwicklung bei Vagrant. Schließlich führten wir Docker auch in dieser Umgebung ein, als sich die Vorteile von selbst zeigten. Das Team erkannte, wie sehr es unsere Deployment-Pipeline vereinfachte, und ließ sich überzeugen.
Es war schwer, dagegen zu argumentieren, als unsere Deployments statt 40 Minuten nur noch etwa 3 Minuten dauerten!
- David Flanagan
Als ich Docker zum ersten Mal begegnete, arbeitete ich schon lange genug als Softwareentwickler, um zu wissen, wie schwierig es sein kann, neue Teammitglieder mit all den benötigten Tools auszustatten. Auch die Einführung neuer Frameworks und Programmiersprachen in die Entwicklungsumgebung – um alles leichter zu machen – war oft mühsam, denn die übliche Reaktion der meisten Entwickler war ein genervtes Augenrollen.
Docker machte uns das Leben so viel leichter: Wir mussten dem Team nur dieses eine magische Tool beibringen, und alle profitierten sofort davon, ohne sich mit der aufwendigen Installation und Konfiguration auseinandersetzen zu müssen. Das war ein großer Moment der Befreiung für Entwickler: keine Tools mehr auf dem streng überwachten Rechner installieren, keinen Anträgen mehr hinterherlaufen und sich keine Gedanken mehr über Lizenzen machen. Wenn es ein Image gab, konnte man loslegen.
- Sevi Karakulak, Engineering Lead bei Container Solutions
Nicht „enterprise-tauglich“
Der Begriff „enterprise-tauglich“ ist subjektiv und kann für jedes Unternehmen, mit dem Sie zu tun haben, etwas anderes bedeuten. Matt Bentley erinnert sich an eine interessante Interpretation davon: Als Solutions Engineer bei Docker musste er in den Anfangstagen darauf eingehen, wie „attraktiv“ Docker war – oder in diesem Fall eben nicht.
… dem Kunden gefiel Docker als Technologie, und auch das Produkt Docker Trusted Registry gefiel ihm. Doch solange wir nichts hatten, das über eine API und die Befehlszeile hinausging, würde die Führungsebene es niemals als enterprise-tauglich ansehen.
Der Kunde musste sich die Produkte intern vorführen lassen. Hätte ich gezeigt, wie ich mit einer in Jenkins integrierten CI/CD-Pipeline Code übernehme, ihn in einem Container erstelle und teste, ihn bereitstelle und das Image weitergebe, hätte der Kunde es nicht verstanden. Enterprise-taugliche Lösungen hatten schließlich ansprechende Benutzeroberflächen.
- Matt Bentley, Manager, Solutions Engineering bei VMware
Häufig wurde auch die relative Unreife des Projekts als Grund für Bedenken genannt. Obwohl es die zugrunde liegenden Technologien schon viele Jahre gab, war es für viele ein Schritt zu weit, auf ein Open-Source-Projekt zu setzen, das aus einem Startup hervorgegangen war, mit Comic-Maskottchen und einer Hausschildkröte, die Deployments ausführte.
2015 begann ich, mich mit Docker zu beschäftigen. Aufgrund des Potenzials, das ich darin sah, schlug ich vor, es zur Modernisierung in Betracht zu ziehen, statt die ältere, teure Lösung eines Anbieters weiterzuverwenden. Der Kunde entschied sich dagegen. Er sagte, man sei sich nicht sicher, was die Container-Technologie angehe und ob es sie während der fünfjährigen Vertragslaufzeit überhaupt noch geben würde.
- Rachel LeeKin, Containers Specialist SA bei AWS
Selbstverschuldete Probleme
Manchmal war es nicht die größte Herausforderung, ein Team von Containern zu überzeugen, sondern ihm beizubringen, sie richtig einzusetzen.
Anfangs war es schwer, meine Kunden davon zu überzeugen ... Wer sich darauf einließ, erkannte nicht immer die Vorteile oder wusste, wie man einen Container nutzt. Ich erinnere mich an einen Kunden, dessen Container manuell geöffnet wurden, um darin die Anwendung oder ihre Abhängigkeiten neu zu kompilieren. Anschließend wurde der Container wie ein Code-Repository committet. Die Container im Betrieb waren riesig und wahrscheinlich sogar anfälliger als die ursprüngliche Infrastruktur ohne Container.
- Adrian Goins
Das Interesse wächst
Im Laufe der Jahre erkannten immer mehr Menschen das Potenzial von Containern – insbesondere, als die Orchestrierungssysteme ausgereifter wurden, auch wenn sie eigene Herausforderungen mit sich brachten. Adrian Mouat (@adrianmouat | @adrianmouat@hachyderm.io), Autor und ebenfalls einer der ursprünglichen Docker Captains, erinnert sich an die ersten DockerCon-Konferenzen und die rege Betriebsamkeit, als immer mehr Menschen erste Schritte wagten und Unternehmen Lösungen für ihre Anforderungen anboten.
Eine Sache ist mir besonders in Erinnerung geblieben: 2014 fragten die Vortragenden (mich eingeschlossen): „Wer verwendet Docker?“ Ein Wald von Händen ging nach oben. „Wer verwendet Docker in der Produktion?“ Fast alle Hände gingen wieder nach unten.
Trotzdem war es erstaunlich, wie viele Menschen Docker bereits in der Produktion einsetzten, bevor Version 1.0 erschien (Oktober 2014) und Docker für produktionsreif erklärt wurde.
Früher verwendeten wir Schifffahrtsmetaphern und sprachen darüber, wie Docker das Problem „aber auf meinem Rechner funktioniert es“ löste – leider kam Kubernetes und schuf dasselbe Problem erneut.
Als ich bei Container Solutions war, halfen wir bei der Organisation der ersten Docker Con EU im NEMO Science Center. Die Begeisterung war unglaublich; allen war klar, dass sie am Anfang von etwas Großem standen. CoreOS war dabei (und stellte Rocket vor!), Alexis Richardson trieb das Weave-Netzwerk voran, Luke Marsden leitete ClusterHQ und den Flocker-Datenmanager, und Timo Derstappen leistete Großartiges mit Giant Swarm. Überall waren Enterprise-Unternehmen, die einfach herauszufinden versuchten, was zum Teufel da vor sich ging.
- Adrian Mouat, Product Manager bei Chainguard
Ich sah Solomons Vortrag auf der PyCon 2013 und versuchte 2014, mit Docker unsere Node.js-Tests zu verbessern – aber ich verstand es einfach nicht. Ich versuchte immer wieder, einen ganzen Server in ein Container-Image zu packen (und scheiterte), und die Vernetzung war für mich völlig undurchschaubar. Es war ein riesiger Stapel neuer Automatisierungszauberei und Konzepte, sodass ich aufgab und sechs Monate später zurückkehrte. Diesmal machte es Klick und traf mich wie ein Zug. Die Kombination aus dem Erstellen von Images, ihrer Speicherung in Registries und dem Starten von Containern daraus haute mich um – und ich blickte nie zurück.
- Bret Fisher, DevOps-Typ und Erfinder von Docker Mastery
Die Orchestrierungssysteme
Wenn Dockers Ankündigung auf der PyCon 2013 der Funke war, der das Feuer entfachte, dann waren Container-Orchestrierungsplattformen die Winde, die den Waldbrand anfachten. Mesosphere, Rancher, Swarm, Nomad und Kubernetes waren die „Killer-Apps“, die Containern zum Durchbruch verhalfen. Über die Vor- und Nachteile der einzelnen Plattformen wurden ganze Bücher geschrieben, doch ihre Bedeutung für die breite Einführung von Containern lässt sich kaum überschätzen.
Kubernetes ist heute die dominierende Plattform, aber es gibt weiterhin eine sehr treue Community von Swarm-Nutzern, und auch Nomad erfreut sich in bestimmten Kreisen großer Beliebtheit. Mesos gab es bereits vor Docker, und ich bin sicher, dass es noch immer eine beachtliche Zahl von Nutzern hat. Für manche wirkte Kubernetes übermäßig komplex, doch wie sein Marktanteil zeigt, haben sich die meisten schließlich dafür entschieden.
Als Kubernetes aufkam, hasste ich es. Es war eine weitere Abstraktionsebene, die keinen großen zusätzlichen Nutzen brachte … bis sie es doch tat. Dann liebte ich es, denn nun konnte ich aus Servern mit ihren VMs und Containern ein kleines Rechenzentrum machen. Dass ein Prozess rund um die Uhr auf das Ganze aufpasste, bedeutete, dass ich mich anderen Dingen widmen konnte.
- Adrian Goins
Kubernetes ist inzwischen der De-facto-Standard für die Bereitstellung von Containern. Interessant ist jedoch, die Entwicklung dieses Bereichs zu beobachten und zu sehen, wie viele Abstraktionsebenen darum herum entstehen.
Als klar wurde, dass Orchestrierungssysteme für die Einführung von Containern im großen Maßstab entscheidend sein würden, dachte ich, dass es Raum für mehrere erfolgreiche große Orchestrierungssysteme geben würde. Jedes war auf seine Weise gut und hatte meiner Meinung nach ideale Anwendungsfälle. An Swarm gefiel mir, dass ich jemanden, der einfache „docker run“-Befehle verstand oder eine leicht verständliche Docker-Compose-Datei erstellen konnte, in wenigen Minuten einen Swarm-Service bereitstellen lassen konnte. Die Einfachheit der Docker-CLI und von Tools wie Docker Compose war brillant: Wer Container auf einem einzelnen Host mit einem dieser Tools starten konnte, musste nicht viel dazulernen, um Container zu orchestrieren. Heute arbeitet die Branche daran, Kubernetes vor Entwicklerinnen und Entwicklern zu abstrahieren, weil es zu viel Aufmerksamkeit von der Entwicklung abzog und auf die Orchestrierung lenkte. Zeit, die Entwicklerinnen und Entwickler für Orchestrierung aufwenden, bedeutet weniger Zeit, um mit den Anwendungen, an denen sie arbeiten, geschäftlichen Mehrwert zu schaffen.
- Matt Bentley
Karriere- und lebensverändernd
Was alle gemeinsam hatten, die ich für diesen Artikel kontaktiert habe: Das Docker-Projekt und die darum entstandene Community haben die Karrieren und tatsächlich auch den Lebensunterhalt vieler Menschen verändert.
Ich wusste, dass dies die nächste Evolutionsstufe der Infrastruktur war. Ich war besessen davon und richtete meine gesamte Karriere auf Container aus.
- Bret Fisher
Von diesem Tag an richtete ich meinen gesamten beruflichen Fokus auf Container aus … Bis heute setze ich mich dafür ein, die US-Regierung auf ihrem Weg zu Containern zu beraten und weiterzubringen. Es ist beeindruckend, dass sich eine so transformative Technologie seit zehn Jahren bewährt.
- Andy Clemenko
Je mehr ich lernte, desto mehr begeisterten mich die Möglichkeiten der Containerisierung. Schließlich begann ich, Docker zu unterrichten, und entschied mich, meine berufliche Laufbahn auf Container und anschließend Kubernetes auszurichten. Heute kann ich mit Sicherheit sagen: Docker hat mein Leben verändert.
- Sevi Karakulak
Snyk liebt Open Source
Wir würdigen das Docker-Projekt für ein Jahrzehnt wegweisender Arbeit. Davon zeugen die eindrucksvollen Erfahrungsberichte der hier zitierten Personen ebenso wie die Millionen Entwicklerinnen und Entwickler weltweit, die täglich Container erstellen, ausliefern und ausführen.
Snyk wurde 2015 mit dem Ziel gegründet, Entwicklerinnen und Entwickler dabei zu unterstützen, sicher Code zu schreiben und Open-Source-Software zu verwenden – einschließlich der Container, in die sie diese packen. Da wir fest an die Stärke und Bedeutung des Open-Source-Entwicklungsmodells glauben, stellen wir einzelnen Entwicklerinnen und Entwicklern unsere Scan-Tools seit dem ersten Tag kostenlos zur Verfügung.
Starten Sie mit Capture-the-Flag
Erfahren Sie in unserem virtuellen On-Demand-Workshop für Einsteiger, wie Sie Capture-the-Flag-Challenges lösen.
Mitwirkende
Vielen Dank an alle, die zu diesem Artikel beigetragen haben!
Nirmal Mehta Principal Specialist Solutions Architect bei AWS; Docker Captain 2016–heute. | Brandon Mitchell Solutions Architect bei BoxBoat, einem Unternehmen von IBM; Docker Captain 2018–heute; Maintainer der OCI image-spec. |
Adrian Goins Ehemaliger Developer Advocate bei Rancher/SUSE; Content Creator und Pilot; langjähriger Rancher/SUSE Advocate. | David Flanagan Gründer von Rawkode Academy; Gründer der KubeHuddle Conference. |
Andy Clemenko Field Engineer bei Rancher Government Solutions; ehemaliger Docker SA und SE. | Rachel Leekin Containers Specialist Solutions Architect bei AWS. |
Matt Bentley Manager für Solutions Engineering bei VMware. | Adrian Mouat Product Manager bei Chainguard; Docker Captain 2016–heute; Autor von Using Docker (O'Reilly Media, 2016). |
Sevi Karakulak Engineering Lead bei Container Solutions. |