Containerd vs. Docker: Container-Laufzeiten verstehen

Im Container-Ökosystem kommt es oft zu Verwirrung, wenn Entwickler Docker (eine umfassende Plattform) mit containerd vergleichen, das eigentlich nur eine spezielle Laufzeitkomponente ist. Dieser Vergleich ist so, als würde man ein komplettes Auto mit seinem Motor vergleichen: Beide sind wichtig, aber sie haben unterschiedliche Aufgaben auf verschiedenen Ebenen. 

In diesem Leitfaden werde ich die Beziehung zwischen diesen beiden Technologien erklären und dabei ihre Architekturen, die Integration von Kubernetesn sowie die spezifischen Szenarien untersuchen, in denen jedes Tool seine Stärken ausspielt. Egal, ob du Container lokal erstellst oder Produktions-Kubernetes-Cluster verwaltest – zu wissen, wann du Docker und wann containerd verwenden solltest, kann deine Infrastrukturentscheidungen echt beeinflussen.

Am Ende dieses Artikels wirst du genau wissen, wie Docker und containerd sich ergänzen und wie du das richtige Tool für deine speziellen Bedürfnisse auswählst, egal ob es um schnelle lokale Entwicklung oder große Produktionsbereitstellungen geht.

Wenn du noch keine Erfahrung mit Containerisierung hast, empfehle ich dir, unseren Kurs „Konzepte der Containerisierung und Virtualisierung“ zu besuchen.

Was ist Docker?

Docker hat die Softwareentwicklung total verändert, indem es Containerisierung für normale Entwickler zugänglich und praktisch gemacht hat. Als umfassende Plattform bietet Docker alles, was man zum Erstellen, Ausliefern und Ausführen von containerisierten Anwendungen braucht.

Für Leute, die gerade erst anfangen,ist dieser praktische Leitfaden zu Containerneine super Einführung in Docker und Container.

Eine umfassende Containerplattform

Docker ist eine All-in-One-Containerplattform namens „ “ und bietet ein integriertes Toolset, das den größten Teil des Container-Lebenszyklus abdeckt. Im Grunde packt Docker Anwendungen mit allen ihren Abhängigkeiten in portable, eigenständige Images, die in jeder Umgebung konsistent laufen, vom Laptop eines Entwicklers bis hin zu Produktionsservern.

Dieser umfassende Ansatz hat Docker zum Branchenstandard für lokale Entwicklung und Entwicklererfahrung gemacht. Einige der wichtigsten Vorteile sind:

• Umfangreiches Ökosystem: Docker Hub hat Millionen von vorgefertigten Images, von Datenbanken bis hin zu Webservern, und macht komplizierte Installationsschritte überflüssig.
• Universelle Tragbarkeit: Ein Container, der auf macOS erstellt wurde, läuft genauso auf Linux oder Windows, wenn Docker installiert ist.
• Entwickler im Fokus: Abstrakte Infrastrukturunterschiede, damit Entwickler sich auf ihre Anwendungen konzentrieren können, statt sich mit der Komplexität der Bereitstellung zu beschäftigen.
• Schnelle Einarbeitung: Neue Teammitglieder können Entwicklungsumgebungen in wenigen Minuten statt in Stunden einrichten.

Wichtige Teile und Ablauf

Die Architektur von Docker besteht aus mehreren miteinander verbundenen Teilen, die nahtlos zusammenarbeiten. 

Die Docker-CLI ist die Benutzeroberfläche, über die Entwickler Befehle eingeben. Wenn du einen Befehl wie „ docker run “ ausführst, redet die CLI mit dem Docker-Daemon (dockerd), der als zentraler Dienst Container, Images, Netzwerke und Volumes verwaltet.

Für Windows- und macOS-Nutzer macht Docker Desktop das Container-Management mit einer grafischen Oberfläche noch einfacher, sodass auch Leute, die nicht so gut mit Befehlszeilentools klarkommen, damit arbeiten können. Diese integrierte Umgebung hat alles, was man für die lokale Entwicklung braucht, von Kubernetes-Unterstützung bis hin zur Volume-Verwaltung.

Der typische Arbeitsablauf läuft so ab: 

1. Entwickler erstellen Images mit Dockerfiles.
2. Sie schicken sie an Registrierungsstellen wie Docker Hub.
3. Schließlich werden die Images als Container auf jedem Docker-fähigen Host ausgeführt. 

Was viele Entwickler nicht wissen, ist, dass Docker Container nicht direkt ausführt. Stattdessen überlässt „ dockerd “ die eigentliche Containerausführung „containerd“, das als separater Prozess im Hintergrund läuft.

Durch dieses modulare Design, bei dem Docker „containerd“ für Low-Level-Operationen nutzt, kann sich jede Komponente auf das konzentrieren, was sie am besten kann: Docker hat eine super Entwickler-freundliche Oberfläche und ein cooles Ökosystem, während containerd sich um die Details der Containerausführung kümmert.

Egal, ob du gerade erst mit Docker anfängst oder den nächsten Schritt machen willst, schau dir unsere 10 Docker-Projektideen für alle Niveaus an.

Was ist Containerd?

Nachdem wir uns den umfassenden Plattformansatz von Docker angesehen haben, schauen wir uns jetzt containerd an, die spezielle Laufzeitumgebung, die die Containerausführung sowohl innerhalb von Docker als auch im gesamten Ökosystem ermöglicht.

Eine Container-Laufzeitumgebung nach Industriestandard

Containerd ist eine leichte, branchenübliche Kern-Container-Laufzeitumgebung, die von der Cloud Native Computing Foundation (CNCF) anerkannt wurde, was zeigt, dass sie ausgereift, zuverlässig und weit verbreitet ist. Containerd war ursprünglich Teil von Docker, wurde aber 2017 rausgenommen und der CNCF gespendet, damit es in einem größeren Ökosystem genutzt werden kann.

Im Gegensatz zu den vielen Funktionen von Docker ist der Funktionsumfang von containerd bewusst eingeschränkt: Es kümmert sich um die wichtigsten Vorgänge im Container-Lebenszyklus wie Starten, Stoppen, Anhalten und Löschen und macht die Übertragung und Speicherung von Images. Dieser fokussierte Ansatz macht containerd super stabil und effizient, was für Produktionsumgebungen echt wichtig ist.

Stell dir containerd wie „Rohrleitungen“ vor: eine Infrastruktur, die dafür gemacht ist, in größere Systeme eingebaut zu werden, statt direkt von Menschen benutzt zu werden. Große Plattformen wie Kubernetes, AWS Fargate und Google Kubernetes Engine nutzen alle containerd, um Container auszuführen, auch wenn die Leute über ihre eigenen Schnittstellen mit diesen Plattformen interagieren.

Architektur und Design

Um zu verstehen, warum containerd in Produktionssystemen so weit verbreitet ist, müssen wir uns seine Architekturprinzipien genauer anschauen.

Die Architektur von Containerd zeigt, wie man modulare Designprinzipien richtig umsetzt. Containerd wurde nach den Standards der Open Container Initiative (OCI) entwickelt und sorgt für Kompatibilität im ganzen Container-Ökosystem. Das heißt, dass jedes OCI-konforme Image mit containerd läuft, egal mit welchem Tool es erstellt wurde.

Die Architektur besteht aus ein paar wichtigen Schichten:

• gRPC-API-Schicht: Bietet ein Client-Server-Modell, bei dem mehrere Clients (Docker, Kubernetes, benutzerdefinierte Tools) mit einer einzigen Containerd-Instanz quatschen.
• Containerd-Daemon: Hält den Status laufender Container im Auge, kümmert sich um die Speicherung von Images über Snapshotters und koordiniert die Vernetzung über Plugins.
• Laufzeitumgebung: Eine leichte, OCI-konforme Laufzeitumgebung, die direkt mit Linux-Kernel-Funktionen zusammenarbeitet, Namespaces erstellt, cgroups einrichtet und Containerprozesse startet.
• Modulare Plugins: Benutzerdefinierte Snapshotters für spezielle Speicher, alternative Laufzeiten (gVisor, Kata Containers) und Netzwerk-Plugins können eingebaut werden, ohne dass man containerd ändern muss.

Wenn containerd einen Container starten muss, startet es runc, das die eigentliche Arbeit erledigt: isolierte Namespaces erstellen, cgroups für Ressourcenbeschränkungen einrichten und den Containerprozess starten. 

Diese Trennung der Aufgaben macht containerd super erweiterbar. Unternehmen können fast alles anpassen, ohne den Kerncode von containerd anzufassen.

Containerd vs. Docker – Die wichtigsten Unterschiede

Nachdem wir jetzt wissen, was die einzelnen Tools machen, schauen wir mal, wie sie sich in der Praxis unterscheiden, von der Architektur bis zu den Integrationsmustern.

Container-Laufzeitumgebung vs. Plattform

Der Hauptunterschied liegt im Umfang und Zweck. 

Docker nutzt eine zentralisierte Daemon-Architektur, in der „ dockerd “ viele verschiedene Sachen koordiniert, wie zum Beispiel:

• Imageaufbau
• Containerausführung
• Vernetzung
• Volumenverwaltung

Dieses All-in-One-Design macht die Entwicklerarbeit einfacher, bringt aber durch mehrere Abstraktionsebenen auch mehr Aufwand mit sich.

Containerd konzentriert sich dagegen nur auf die Ausführung von Containern. Es hat keine Funktionen zum Erstellen von Images, keine Orchestrierungsfunktionen und keine grafische Benutzeroberfläche. Für die Vernetzung hat Docker die „ Libnetwork “ direkt in seinen Daemon eingebaut, während containerd auf externe CNI-Plugins (Container Network Interface) setzt, die je nach Bedarf ausgetauscht werden können.

Dieser Unterschied in der Architektur wirkt sich auf die Leistung aus. In Umgebungen mit hoher Fluktuation, wo Container oft starten und stoppen, wie zum Beispiel bei automatisch skalierenden Kubernetes-Clustern, kann das schlanke Design von containerd zu schnelleren Startzeiten und weniger Ressourcenverbrauch führen. Durch den geringeren Overhead braucht containerd weniger Speicher und CPU, was bei großem Umfang echt wichtig ist.

Kubernetes-Integration

Apropos Kubernetes: Die Beziehung zwischen Container-Laufzeiten und Orchestrierungsplattformen hat sich stark verändert, vor allem, wie Kubernetes mit containerd verbunden ist.

Die Beziehung zwischen Kubernetes und Container-Laufzeiten hat sich mit Kubernetes 1.24, das 2022 rausgekommen ist, ziemlich verändert. In dieser Version wurde „Dockershim“ rausgeschmissen, eine Kompatibilitätsschicht, die es Kubernetes ermöglichte, Docker als Container-Laufzeitumgebung zu nutzen.

Dockershim war von Anfang an als vorübergehende Lösung gedacht. Als Kubernetes die Container Runtime Interface (CRI) einführte, um die Kommunikation mit Laufzeitumgebungen zu standardisieren, konnte Docker das nicht direkt umsetzen, weil Docker schon vor dem CRI-Design da war. Dockershim hat zwischen Kubernetes und Docker übersetzt und dabei eine eigentlich unnötige Übersetzungsschicht eingebaut.

Moderne Kubernetes-Versionen reden direkt über CRI mit containerd, wodurch die Docker-Übersetzungsschicht komplett wegfällt. Diese Vereinfachung bringt echte Vorteile:

• Geringere Latenz: Direkte Kommunikation macht Übersetzungsaufwand im Containerbetrieb überflüssig
• Verbesserte Stabilität: Weniger bewegliche Teile bedeuten weniger mögliche Fehlerquellen.
• Bessere Leistung: Der optimierte Laufzeit-Stack ist besonders gut für große Installationen.
• Einfacheres Debuggen: Die direkte CRI-Integration macht die Fehlerbehebung einfacher.

Für Kubernetes-Nutzer ist diese Änderung echt unauffällig. Docker-Images bleiben voll kompatibel, weil sie den OCI-Standards entsprechen. Das heißt, dass die Kubernetes-Cluster jetzt besser laufen, weil sie direkt containerd nutzen, während Entwickler weiterhin Docker lokal zum Erstellen und Testen verwenden können.

Wenn du dir nicht sicher bist, welche Vor- und Nachteile die Verwendung von Kubernetes hat, schau dir diesen Vergleich zwischen Docker Compose und Kubernetes an.

Imageaufbau und -management

Die Laufzeitintegration ist zwar für die Orchestrierung super wichtig, aber der Arbeitsablauf der Entwickler hängt stark davon ab, wie jedes Tool die Erstellung und Speicherung von Images handhabt. Beim Image-Building gibt's einen ziemlichen Unterschied zwischen Docker und containerd. 

Docker hat ein integriertes Build-System mit Dockerfiles und BuildKit, mit dem Entwickler komplexe mehrstufige Builds mit Caching, Parallelisierung und coolen Features wie Build-Geheimnissen und SSH-Agent-Weiterleitung erstellen können.

Containerd hat von Haus aus keinen nativen Bild-Build-Workflow. Um Images mit containerd zu erstellen, brauchen Entwickler externe Tools. Zu den Optionen gehören die Ausführung von BuildKit als separater Daemon und die Verwendung von buildctl für Befehlszeilen-Builds oder die Verwendung von nerdctl, einer Docker-kompatiblen CLI, die BuildKit integriert.

Auch die Speichermechanismen haben unterschiedliche Ansätze. Die Volume-Verwaltung von Docker bietet eine Abstraktion, die für Entwickler intuitiv ist, mit benannten Volumes, die Daten unabhängig vom Lebenszyklus der Container speichern. Containerd nutzt ein eher einfaches Snapshot-System, bei dem verschiedene Snapshot-Treiber eingebunden werden können, um mehrschichtige Dateisysteme je nach den Anforderungen des zugrunde liegenden Speichers unterschiedlich zu verarbeiten.

Dieser Unterschied zeigt, für wen die Tools gedacht sind: 

• Docker macht die Arbeit für Entwickler einfacher, weil es schon ein paar praktische Funktionen hat.
• Containerd bietet flexible Bausteine, die Plattformentwickler nach ihren spezifischen Bedürfnissen zusammenstellen können.

CLI, Entwicklererfahrung und nerdctl

Abgesehen von der Architektur und den Funktionen wird die tägliche Entwicklererfahrung am direktesten von der Befehlszeilenschnittstelle geprägt, die jedes Tool bietet. Die Arbeit mit der Befehlszeile zeigt die unterschiedlichen Designphilosophien am deutlichsten. 

Die CLI von Docker ist echt bekannt für ihre Benutzerfreundlichkeit. Befehle wie „ docker run “, „ docker build “ und „ docker logs “ sind einfach zu verstehen, gut erklärt und für Menschen gemacht. Die CLI hat coole Standardeinstellungen, klare Fehlermeldungen und viele Optionen, die die meisten Anwendungsfälle abdecken.

Containerd kommt mit „ ctr “, einer minimalistischen Befehlszeilenschnittstelle, die nur zum Debuggen und Testen der grundlegenden Funktionen von containerd gedacht ist. Das Tool „ ctr “ ist absichtlich nicht so entwicklerfreundlich. Es fehlen gängige Funktionen wie Port-Mapping-Abkürzungen, automatische Neustartrichtlinien und die Integration mit Credential Helpers. Es ist für Containerentwickler gedacht, nicht für App-Entwickler.

Die Lücke mit nerdctl schließen

Diese Lücke in der Benutzerfreundlichkeit hat zur Entwicklung von „ nerdctl “ geführt, einer Docker-kompatiblen CLI für containerd. nerdctl zu benutzen fühlt sich genauso an wie Docker zu benutzen – gleiche Befehlssyntax, gleiche Flags, gleicher Workflow, aber mit containerd als zugrunde liegender Laufzeitumgebung. Das macht „ nerdctl “ zu einer super Lösung für Teams, die in Entwicklungsumgebungen von Docker zu containerd wechseln wollen.

In der Praxis arbeiten Entwickler selten direkt mit containerd. Wenn's doch mal nötig ist, bietet nerdctl die vertraute Oberfläche, die sie erwarten, während Plattformbetreiber und Administratoren die APIs von containerd programmgesteuert über Orchestrierungssysteme wie Kubernetes nutzen.

Um die Unterschiede in der Praxis zu zeigen, hier ein Vergleich der gängigen Container-Operationen in den drei CLI-Tools:

Hinweis: ctr hat keine Portzuordnung (-p) und braucht Host-Netzwerk (--net-host), um Dienste freizugeben. Es werden auch nicht automatisch Bilder geladen.

Die wichtigsten Unterschiede im Überblick

Bevor wir zu Empfehlungen für bestimmte Anwendungsfälle kommen, lass uns noch mal die Unterschiede zusammenfassen, die wir bisher besprochen haben. Die folgende Tabelle zeigt die wichtigsten funktionalen Unterschiede zwischen Docker und containerd und hebt ihre unterschiedlichen Funktionen und Zielgruppen hervor:

Warum Docker wählen?

Nachdem wir jetzt die technischen Unterschiede geklärt haben, schauen wir uns mal praktische Szenarien an, in denen jedes Tool seine Stärken hat. Auch wenn Containerd in Produktionsumgebungen immer beliebter wird, ist Docker immer noch die beste Wahl für bestimmte Szenarien, in denen die Entwicklererfahrung und umfassende Tools am wichtigsten sind.

Für lokale Entwicklung und Prototyping

Docker ist super, wenn du eine „All-in-One”-Lösung zum Schreiben und Testen von Code brauchst. Dank der integrierten Toolchain können Entwickler innerhalb von Minuten von Null auf hundert Container ausführen, ohne mehrere Komponenten zusammenbauen oder komplizierte Netzwerke einrichten zu müssen.

Das Docker-Ökosystem bietet echt große Vorteile für die Produktivität:

• Docker Hub: Millionen von sofort einsatzbereiten Bildern für Datenbanken, Nachrichtenwarteschlangen und Webserver
• Docker Compose: Definiere Multi-Container-Anwendungen in einer einzigen YAML-Datei und starte ganze Entwicklungsumgebungen mit einem einzigen Befehl.
• Docker Desktop GUI: Visuelle Containerverwaltung, Durchsuchen von Volumes, Anpassen von Ressourcenbeschränkungen und integrierte Kubernetes-Unterstützung
• Niedrigere Einstiegshürde: Grafische Tools und einfache Befehle machen Container auch für Entwickler zugänglich, die noch nicht mit der Technologie vertraut sind.

Für Teams, die Docker Desktop nutzen, bietet die GUI zusätzliche Vorteile, die das Onboarding und die täglichen Arbeitsabläufe echt beschleunigen.

Für komplexe Build-Pipelines

Über die Entwicklung hinaus sind die Build-Funktionen von Docker die perfekte Wahl für anspruchsvolle Workflows zur kontinuierlichen Integration und Bereitstellung.

Das integrierte BuildKit von Docker hat coole Funktionen, die für moderne CI/CD-Pipelines echt wichtig sind. Mehrstufige Builds machen die Bildgrößen kleiner, ohne dass die Dockerfiles unlesbar werden. Die Caching-Mechanismen von BuildKit nutzen Ebenen intelligent über verschiedene Builds hinweg wieder, was die Build-Zeiten in Continuous-Integration-Umgebungen echt verkürzt.

Die meisten Automatisierungsplattformen, wie GitHub Actions, GitLab CI, Jenkins und andere, haben ausgereifte, bewährte Docker-Integrationen. Diese Integrationen kümmern sich reibungslos um Authentifizierung, Caching und Bildveröffentlichung. 

Auch wenn andere Tools ähnliche Ergebnisse liefern können, ist die Allgegenwärtigkeit von Docker ein großer Vorteil, weil Lösungen und Hilfe bei Problemen leicht verfügbar sind.

Warum Containerd wählen?

Containerd ist super in Produktionsszenarien, wo Minimalismus, Leistung und Stabilität wichtiger sind als die Bequemlichkeit integrierter Tools.

Für Produktions-Kubernetes-Cluster

Die Verwendung von containerd als Laufzeitumgebung für Kubernetes-Knoten bringt echt messbare Vorteile:

• Geringere Gemeinkosten: Wenn man den Docker-Daemon loswird, braucht man weniger Ressourcen pro Knoten und kann bei großem Umfang richtig sparen.
• Verbesserte Stabilität: Weniger bewegliche Teile bedeuten weniger mögliche Fehlerquellen in deiner Infrastruktur.
• Geringere Angriffsfläche: Weniger Code zum Überprüfen und weniger potenzielle Sicherheitslücken
• Einfacheres Debuggen: Durch die direkte CRI-Integration wird die Dockershim-Übersetzungsschicht weggelassen, was die Fehlerbehebung einfacher macht.
• Bessere Leistung: Der optimierte Laufzeit-Stack macht die Startzeiten und Reaktionsfähigkeit von Containern besser.

Der CNCF-Abschlussstatus von Containerd zeigt, dass es ausgereift und zuverlässig ist. Große Cloud-Anbieter wie AWS, Google Cloud und Azure haben containerd für ihre verwalteten Kubernetes-Angebote standardisiert und zeigen damit, dass sie davon überzeugt sind, dass es für kritische Infrastrukturen einsatzbereit ist.

Für spezielle, minimalistische Umgebungen

Kubernetes ist zwar der häufigste Anwendungsfall in der Produktion, aber die Leichtigkeit von containerd macht es auch für Einsatzszenarien interessant, wo Docker nicht so gut passt.

Edge-Computing- und IoT-Geräte laufen oft mit echt knappen Ressourcen. Das schlanke Design von Containerd macht es in diesen Umgebungen einsetzbar, in denen der komplette Stack von Docker zu teuer wäre. Jedes Megabyte Speicher und jeder CPU-Zyklus zählt, wenn man auf eingebetteter Hardware läuft.

Fortgeschrittene Sicherheitsszenarien profitieren von der modularen Laufzeitarchitektur von containerd. Unternehmen können Sandbox-Laufzeiten für Aufgaben integrieren, die zusätzliche Sicherheitsgrenzen brauchen. Beispiele sind:

• gVisor: sorgt für starke Kernel-Isolation
• Kata Containers: lässt Container in schlanken VMs laufen

Diese Integrationen lassen sich ohne große Änderungen in containerd einbinden.

Umstieg von Docker auf Containerd

Es ist wichtig zu wissen, wann man welches Tool benutzt, aber genauso wichtig ist es, zu wissen, wie man zwischen ihnen hin und her wechselt. Der Wechsel von Docker zu containerd in bestehenden Umgebungen braucht eine sorgfältige Planung, aber der Prozess ist gut dokumentiert und einfach.

Kubernetes-Knoten migrieren

Die Schritte, um Kubernetes-Knoten von Docker zu containerd zu migrieren, laufen nach einem Standardmuster ab:

1. Den Knoten absperren: Verhindere, dass neue Pods geplant werden (kubectl cordon )

2. Leere die vorhandenen Behälter: Verschieb die Workloads auf andere Knoten (kubectl drain )

3. Aktualisiere die Kubelet-Konfiguration: Zeige auf den CRI-Socket von containerd unter /run/containerd/containerd.sock

4. CNI-Plugins checken: Stell sicher, dass die notwendigen Netzwerk-Plugins für containerd installiert sind.

5. Kubelet neu starten: Registriere dich mit der neuen Laufzeitumgebung und schließ dich wieder dem Cluster an.

Wenn du die Migration erst mal auf Nicht-Produktionsknoten testest, kannst du Probleme, die mit der Umgebung zusammenhängen, erkennen, bevor du Änderungen im ganzen Cluster machst. Um häufige Fehler zu vermeiden, solltest du die folgenden bewährten Vorgehensweisen beachten:

• Änderungen am Protokollpfad: Docker und containerd haben unterschiedliche Standard-Speicherorte für Protokolle, also pass deine Protokollierungsinfrastruktur entsprechend an.
• Installiere fehlende CNI-Plugins: Containerd braucht CNI-Plugin-Binärdateien für die Vernetzung; die sind nicht immer standardmäßig installiert.
• Pass auf Unterschiede beim Bildziehen auf: Die Authentifizierungs- und Registrierungskonfigurationen müssen vielleicht angepasst werden.
• Pass auf bei falschen Speichertreibern: Stell sicher, dass deine persistenten Volumes mit dem Snapshotter von containerd kompatibel sind.

Die Unterschiede in der CLI verstehen

Sobald deine Infrastruktur migriert ist, müssen Entwickler ihre täglichen Arbeitsabläufe an die neue Laufzeitumgebung anpassen.

Für Entwickler, die mit Docker-Befehlen vertraut sind, bietet nerdctl eine fast identische Erfahrung. Befehle wie „ nerdctl run “, „ nerdctl build “ und „ nerdctl compose up “ funktionieren genauso wie ihre Docker-Entsprechungen, was den Übergang echt einfach macht.

Für die Fehlersuche ist es wichtig zu wissen, wie man Docker-Debugging-Workflows auf containerd anwendet. Wenn du „ docker inspect “ zum Überprüfen eines Containers verwenden würdest, liefert „ ctr containers info “ ähnliche Infos, allerdings in einem anderen Format. Genauso zeigt „ ctr tasks list “ laufende Container an.

Die meisten Entwickler finden, dass man mit „ nerdctl ” die Syntax von „ ctr ” für alltägliche Aufgaben nicht mehr lernen muss. Die Low-Level- ctr -Schnittstelle ist immer noch nützlich, wenn du Probleme mit der Laufzeitumgebung lösen musst oder direkt mit den APIs von containerd arbeitest.

Fazit

Die Beziehung zwischen Docker und containerd ist ein super Beispiel für ein gelungenes modulares Design in der Software-Infrastruktur. Docker ist immer noch das beste Tool für Leute, die Code schreiben, weil es eine integrierte Erfahrung, ein umfassendes Ökosystem und entwicklerfreundliche Schnittstellen bietet, die das Erstellen von containerisierten Anwendungen produktiv (und angenehm) machen.

Containerd ist super als Laufzeitumgebung für Maschinen, die Code ausführen, undbietet die Stabilität, Leistung und Einfachheit, die man für Produktionsorchestrierungsplattformen braucht. Dass die Docker Engine im Hintergrund containerd nutzt, zeigt, dass sich die beiden Tools eher ergänzen als konkurrieren.

Für die meisten Unternehmen empfehle ich einen pragmatischen Ansatz: Nutzt Docker weiterhin auf den Laptops der Entwickler, wo die Tools die Entwicklungsabläufe beschleunigen, aber denkt darüber nach, die Kubernetes-Cluster in der Produktion direkt auf Containerd umzustellen, um von den betrieblichen Vorteilen wie geringeren Overhead-Kosten und vereinfachten Laufzeit-Stacks zu profitieren.

Egal, ob du dich für die umfassende Plattform von Docker oder die fokussierte Laufzeitumgebung von containerd entscheidest – beide sind wichtige Teile des modernen Container-Ökosystems und jeweils für verschiedene Phasen des Anwendungslebenszyklus optimiert.

Um weiterzulernen, solltest du dich unbedingt für unseren Lernpfad „Containerisierung und Virtualisierung mit Docker und Kubernetes” anmelden.