Buildah und Podman Beziehung

Von Tom Sweeney GitHub

Kubernetes-Installationen können komplex sein mit mehreren Runtime-Abhängigkeiten und Runtime-Engines. CRI-O wurde entwickelt, um eine leichtgewichtige Runtime für Kubernetes bereitzustellen, die eine Abstraktionsschicht zwischen dem Cluster und der Runtime hinzufügt, die verschiedene OCI-Runtime-Technologien ermöglicht. Jedoch haben Sie immer noch das Problem von Daemon-Abhängigkeiten in Ihrem Cluster für Builds - d.h. wenn Sie den Cluster für Builds verwenden, benötigen Sie immer noch einen Docker-Daemon.

Hier kommt Buildah ins Spiel. Buildah ermöglicht es Ihnen, einen Kubernetes-Cluster ohne Docker-Daemon sowohl für Runtime als auch für Builds zu haben. Ausgezeichnet. Aber was ist, wenn etwas schief geht? Was ist, wenn Sie Troubleshooting oder Debugging von Containern in Ihrem Cluster durchführen möchten? Buildah ist nicht wirklich dafür gebaut, was Sie brauchen ist ein Client-Tool für die Arbeit mit Containern und das, was einem in den Sinn kommt, ist Docker CLI - aber dann sind Sie wieder beim Daemon.

Hier kommt Podman ins Spiel. Podman ermöglicht es Ihnen, alle Docker-Befehle ohne Daemon-Abhängigkeit auszuführen. Mit Podman können Sie Container in Ihrem Kubernetes-Cluster ausführen, erstellen (es ruft Buildah unter der Haube dafür auf), modifizieren und debuggen. Mit beiden Projekten zusammen haben Sie eine umfassende Lösung für Ihre OCI-Container-Image- und Container-Bedürfnisse.

Buildah und Podman sind zwei sich ergänzende Open-Source-Projekte, die auf den meisten Linux-Plattformen verfügbar sind und beide Projekte befinden sich auf GitHub.com mit Buildah hier und Podman hier. Sowohl Buildah als auch Podman sind Kommandozeilen-Tools, die mit OCI-Images und -Containern arbeiten. Die beiden Projekte sind verwandt, unterscheiden sich aber in ihrer Spezialisierung.

Buildah spezialisiert sich auf das Erstellen von OCI-Images. Buildah's Befehle replizieren alle Befehle, die in einem Dockerfile zu finden sind. Buildah's Ziel ist es auch, eine niedrigere Level-Coreutils-Schnittstelle zum Erstellen von Container-Images bereitzustellen, die es Menschen ermöglicht, Container ohne ein Dockerfile zu erstellen. Buildah's anderes Ziel ist es, Ihnen zu ermöglichen, andere Skriptsprachen zum Erstellen von Container-Images zu verwenden, ohne einen Daemon zu benötigen.

Podman spezialisiert sich auf alle Befehle und Funktionen, die Ihnen helfen, diese OCI-Container-Images zu verwalten und zu modifizieren, wie das Ziehen und Taggen. Es ermöglicht Ihnen auch, diese Container zu erstellen, auszuführen und zu verwalten. Wenn Sie einen Befehl in der Docker CLI ausführen können, können Sie denselben Befehl in der Podman CLI ausführen. Tatsächlich können Sie einfach 'podman' als Alias für 'docker' auf Ihrem Rechner setzen und Sie können dann Container-Images und Container erstellen, erstellen und verwalten, ohne dass ein Daemon vorhanden ist, genau wie Sie es immer getan haben.

Obwohl Podman unter der Haube Buildah's Build-Funktionalität verwendet, um ein Container-Image zu erstellen, haben die beiden Projekte Unterschiede. Der Hauptunterschied zwischen Podman und Buildah ist ihr Konzept eines Containers. Podman ermöglicht es Benutzern, traditionelle Container zu erstellen und die Absicht dieser Container ist es, über den gesamten Container-Lebenszyklus kontrolliert zu werden (pausieren, checkpoint/restore, etc.). Während Buildah-Container wirklich nur erstellt werden, um Inhalte zum Container-Image hinzuzufügen. Jedes Projekt hat eine separate interne Darstellung eines Containers, die nicht geteilt wird. Aus diesem Grund können Sie Podman-Container nicht von Buildah aus sehen oder umgekehrt. Jedoch ist die interne Darstellung eines Container-Images zwischen Buildah und Podman dieselbe. Daher kann jedes Container-Image, das von einem erstellt, gezogen oder modifiziert wurde, vom anderen gesehen und verwendet werden.

Einige der Befehle zwischen den beiden Projekten überschneiden sich erheblich, haben aber in einigen Fällen leicht unterschiedliche Verhaltensweisen. Die folgende Tabelle veranschaulicht die Befehle mit einigen Überschneidungen zwischen den Projekten.

Befehl	Podman Verhalten	Buildah Verhalten
build	Ruft buildah bud auf	Stellt den build-using-dockerfile (bud) Befehl bereit, der Docker's build-Befehl emuliert.
commit	Committed einen Podman-Container in ein Container-Image. Funktioniert nicht mit einem Buildah-Container. Einmal committed kann das resultierende Image von Podman oder Buildah verwendet werden.	Committed einen Buildah-Container in ein Container-Image. Funktioniert nicht mit einem Podman-Container. Einmal committed kann das resultierende Image von Buildah oder Podman verwendet werden.
mount	Mountet einen Podman-Container. Funktioniert nicht mit einem Buildah-Container.	Mountet einen Buildah-Container. Funktioniert nicht mit einem Podman-Container.
pull und push	Zieht oder schiebt ein Image aus einer Container-Image-Registry. Funktional dasselbe wie Buildah.	Zieht oder schiebt ein Image aus einer Container-Image-Registry. Funktional dasselbe wie Podman.
run	Führt einen Prozess in einem neuen Container auf dieselbe Weise wie docker run aus.	Führt den Container auf dieselbe Weise wie der RUN-Befehl in einem Dockerfile aus.
rm	Entfernt einen Podman-Container. Funktioniert nicht mit einem Buildah-Container.	Entfernt einen Buildah-Container. Funktioniert nicht mit einem Podman-Container.
rmi, images, tag	Äquivalent in beiden Projekten.	Äquivalent in beiden Projekten.
containers und ps	ps wird verwendet, um Podman-Container aufzulisten. Der containers-Befehl existiert nicht.	containers wird verwendet, um Buildah-Container aufzulisten. Der ps-Befehl existiert nicht.

Eine schnelle und einfache Möglichkeit, den Unterschied zwischen den beiden Projekten zusammenzufassen, ist, dass der buildah run-Befehl den RUN-Befehl in einem Dockerfile emuliert, während der podman run-Befehl den docker run-Befehl in der Funktionalität emuliert.

Buildah ist ein effizienter Weg, OCI-Images zu erstellen, während Podman es Ihnen ermöglicht, diese Images und Container in einer Produktionsumgebung mit vertrauten Container-CLI-Befehlen zu verwalten und zu warten. Zusammen bilden sie eine starke Grundlage zur Unterstützung Ihrer OCI-Container-Image- und Container-Bedürfnisse. Das Beste daran ist, sie sind beide Open-Source-Projekte und Sie sind mehr als willkommen, zu einem oder beiden Projekten beizutragen. Hoffe, Sie dort zu sehen!