Eines der Probleme bei der Computerprogrammierung besteht darin, dass dieselben Namen ständig für unterschiedliche Zwecke verwendet werden. Zum Beispiel der Begriff Namespace wird auf vielfältige Weise verwendet. Ich bin oft verwirrt, wenn Leute über Namespaces in Kubernetes sprechen. Einige Leute hören den Begriff beispielsweise und denken an virtuelle Cluster, aber wenn ich ihn höre, denke ich an die Linux-Namespaces, die mit Pods und Containern verwendet werden. Ebenso Bild kann sich auf ein VM-Image, ein Container-Image oder ein OCI-Image beziehen, das in einer Containerregistrierung gespeichert ist.
[ Das könnte Ihnen auch gefallen: 7 unterhaltsame Funktionen für Linux-Container/Image-Transporte ]
Aber in der Welt der Container gibt es keinen überstrapazierteren Begriff als Container .
Kürzlich hat ein Benutzer ein Podman-Problem erstellt und seine Frustration über diese Terminologie zum Ausdruck gebracht:
Unklare Terminologie:Bild vs. Container
Mein Verständnis ist, dass das Bild eine schreibgeschützte Vorlage ist, während der Container eine Lese-Schreib-Sache ist. Stets. Wenn also etwas ein Container ist, dann betrachten es sowohl Podman als auch Buildah als Container. Wenn etwas ein Bild ist, betrachten sowohl Podman als auch Buildah es als Bild.
Ich rufe buildah von --name abc scratch auf. buildah-Bilder und Podman-Bilder haben die gleiche Ausgabe und sie betrachten das Neue nicht als Bild.
Podman-Container ls zeigt nichts an, also ist das neue Ding aus Podman-Perspektive kein Container.
buildah container gibt jedoch das neue Ding zurück, sodass das neue Ding ein Container ist (mit CONTAINER NAME=abc , IMAGE NAME=scratch , BUILDER=*=yes IMAGE ID ="").
Das neue Ding ist also ein Container aus der Buildah-Perspektive, aber kein Container aus der Podman-Perspektive. Das ist völlig verwirrend.
Bitte erläutern Sie den Unterschied zwischen Containern in Bezug auf Buildah und Containern in Bezug auf Podman.
Ich denke an Container als Ausführen von Prozessen innerhalb einer Umgebung oder etwas, das für die Ausführung vorbereitet ist. Im Gegensatz dazu Bilder sind festgeschriebene Container, die bereit sind, mit anderen geteilt zu werden, um neue Container zu erstellen.
Die Container-Engines, mit denen wir arbeiten – Podman, Buildah, CRI-O und Skopeo – haben alle dasselbe Image-Konzept.
Images werden in Containern/Image definiert und in verschiedenen Speichern oder Transporten gespeichert, z. B. Containerregistrierungen, Docker-Archive, OCI-Archive, Docker-Daemon und Container/Speicher. Ich habe in einem früheren Artikel über diese Lagerarten oder Transporte geschrieben.
Die meisten Leute stellen sich Bilder vor, die in Containern/Speichern oder Containerregistrierungen platziert sind. Für den Rest dieser Beschreibung konzentrieren wir uns auf Container/Speicher.
Übrigens ist Skopeo nicht wirklich eine Container-Engine, da es kein Container-Konzept hat. Stattdessen befasst sich Skopeo nur mit Container-Images und verschiebt sie zwischen verschiedenen Containerspeichertypen.
Container/Lagerbehälter
Die Container-/Speicherbibliothek bietet auch ein eigenes Konzept eines Speichercontainers. Lagerbehälter sind im Grunde noch nicht festgeschriebene Zwischenlagerinhalte. Stellen Sie sich dies als Dateien auf der Festplatte und etwas JSON vor, das den Inhalt beschreibt.
Podman, Buildah und CRI-O verwenden alle Speichercontainer . Alle drei Container-Engines haben auch zusätzliche Daten, die für sie spezifisch sind.
Buildah-Container
Buildah-Container enthalten zusätzlichen Inhalt, der sich auf die verschiedenen Befehle bezieht, aus denen das Containerfile oder Dockerfile besteht.
Beispielsweise werden Workingdir, Env-Variablen und andere Daten verwendet, um ein Container-Image zu erstellen.
Podman-Container
Podman verfügt über einen eigenen Datenspeicher für Daten, die sich auf einen Podman-Container beziehen. In der Podman-Datenbank sind viel mehr Daten gespeichert als in der Buildah-Datenbank. Sie können sich die Buildah-Datenbank als Teilmenge der Podman-Datenbank vorstellen.
CRI-O-Container
CRI-O hat auch einen eigenen Datenspeicher, um seine Container zu beschreiben.
Alle drei Tools haben sich unterschiedlich entwickelt und haben unterschiedliche Vorstellungen und Anforderungen an die eigenen Container.
Beispielsweise haben sich CRI-O-Container in Abhängigkeit von einem einzigen Daemon entwickelt, der sie steuert. Der Schwerpunkt liegt auf der Leistung und der Notwendigkeit, Hunderte/Tausende von Antworten pro Sekunde an den Kubernetes CRI weiterzugeben. Da CRI-O weiß, dass es der einzige ist, der sich mit dem Datenspeicher befasst, kann es die Speicherung der Informationen im Arbeitsspeicher nutzen. CRI-O muss sich nicht um andere Prozesse kümmern, die ohne sein Wissen hereinkommen und die Container ändern.
Podman hingegen muss mit mehreren Benutzern seiner Container gleichzeitig umgehen. Es muss sich mehr auf das Sperren des Dateisystems verlassen und sicherstellen, dass Hunderte von ausführbaren Podman-Dateien zuverlässig denselben Datenspeicher gemeinsam nutzen können. Wir haben darüber gesprochen, den Datenspeicher von Podman schließlich mit CRI-O zusammenzuführen, damit CRI-O und Podman besser zusammenarbeiten können, aber im Laufe der Zeit sind wir der Meinung, dass das Risiko/Nutzen-Verhältnis die Zusammenführung nur schwer rechtfertigen wird.
Buildah wurde auch als eigenständiges Tool entwickelt. Die Betreuer haben sich gedrängt, das unnötige Gewicht und die Komplexität des Podman-Datenspeichers für wenig bis gar keinen zusätzlichen Nutzen zu übernehmen. Buildah-Container haben einen Zweck:Erstellen eines Container-Images, während es bei den meisten Podman-Containern eher um das Ausführen von Anwendungen und Diensten geht. Buildah-Container enthalten nicht alle Informationen, die Podman benötigen würde.
Wie würde Podman mit einem Container umgehen, der mit der buildah from scratch erstellt wurde Befehl?
Wir müssten diese teilweise erstellten Container immer noch anders behandeln. Daher sieht Podman sie als gleichwertig an oder wird sogar standardmäßig in podman ps aufgeführt Befehl würde die Benutzer verwirren.
Kompatibilität
Podman kann tatsächlich mit diesen Containern arbeiten.
Die neuesten Versionen von Podman können jetzt die auf dem System verfügbaren Speichercontainer auflisten:
$ podman ps -a --external | grep buildah
578edf9430ee scratch buildah 13 days ago storage working-container Sie können diese Container mounten und unmounten:
# podman mount working-container
/home/dwalsh/.local/share/containers/storage/overlay/a4f596beaabdc78efc7694a67d690097e327aa12bbc59165d011e62b646e93c0/merged
# podman unmount working-container
working-container Sie können auch diese Container entfernen:
$ podman rm working-container
working-container
Sie können diese Container auch mit podman build erstellen . Natürlich werden diese Container nur temporär während des Builds erstellt. Da diese Buildah-Container nicht dieselben Daten wie ein Podman-Container haben, kann Podman sie nicht starten und stoppen, und podman ps zeigt sie nicht an, wenn sie ausgeführt werden.
Podman hat auch eine ähnliche Fähigkeit, mit CRI-O-Containern zu arbeiten.
[ Lernen Sie die Grundlagen der Verwendung von Kubernetes in diesem kostenlosen Spickzettel. ]
Abschluss
Wenn es um den Begriff Container geht , der Kontext ist oft kritisch. Es ist wichtig, den Unterschied zwischen den Verwendungen zu verstehen. Wenn es um unsere Container-Tools geht, teilen wir die meisten zugrunde liegenden Inhalte, Speicher und Bibliotheken. Aber es gibt legitime Gründe, warum jedes Tool leicht unterschiedliche Konzepte oder Definitionen oder ihre Container hat.