Es ist klar, dass die Leidenschaften rund um Red Hat derzeit einen völlig anderen und sehr globalen
Fokus haben , aber wir sprechen immer noch über unsere eigenen - lokal und angewendet aus der Welt der Container. Seit Anfang dieses Jahres arbeitet Red Hat aktiv an einem Ersatz für Docker namens
Podman (oder
libpod ). Aus irgendeinem Grund haben sie immer noch nicht über dieses Projekt im Hub geschrieben, aber jetzt ist es ein sehr geeigneter Zeitpunkt, ihn kennenzulernen, seine Ursprünge kennenzulernen und über Perspektiven nachzudenken. Lass uns gehen!
CRI-O als Hintergrundgeschichte
Wenn Sie sich die moderne Welt der Linux-Container ansehen, ist es leicht zu erkennen, dass das Thema des heutigen Artikels nur eine der Phasen der langfristigen Strategie von Red Hat ist. Eine anschauliche Bestätigung dafür ist
das CRI-O-Projekt , das wir
vor etwa einem Jahr geschrieben haben. Kurz gesagt, CRI-O ist eine Implementierung des Kubernetes CRI (Container Runtime Interface) zum Starten von Container-Laufzeiten, die mit dem OCI-Standard kompatibel sind (Open Container Initiative). Noch kürzer ist dies ein Ersatz für Docker als Laufzeit für Kubernetes.
(Eine technisch ähnliche Initiative für K8s von Docker Inc ist Cri-Containerd , über die wir auch geschrieben haben . Im selben Artikel wird die Leistung dieser beiden Lösungen verglichen.)Die Geschichte von CRI-O ist so, dass während OCI Standards für Container vorbereitete (
Laufzeitspezifikation und
Bildspezifikation )
[was jedoch auch unter Beteiligung von Red Hat geschah] , ein neues Projekt namens OCID erstellt und im Kubernetes-Inkubator in RH platziert wurde ( Open Container Initiative Daemon), der später [von OCI angefordert] in CRI-O umbenannt wurde. Sein Zweck war "die Implementierung einer Standardschnittstelle für die Laufzeitumgebung für Container in Kubernetes", und die Förderung in den "technischen Massen" wurde im Rahmen eines größeren Projekts Red Hat durchgeführt, um ein Betriebssystem für Container zu erstellen -
Project Atomic .
Kappen mit dem CRI-O-Logo auf der KubeCon + CloudNativeCon North America 2017In der Vergangenheit ist CRI-O auf
Version 1.0 gereift,
hat Unterstützung in Minikube erhalten, und seine letzte Errungenschaft kann als
Übernahme der Standard-Containerschnittstelle in
das Kubic-Projekt angesehen werden , das insbesondere von der Wettbewerbsgemeinschaft (für Red Hat) entwickelt wurde. Linux-Distribution - openSUSE.
Zurück zum Thema des Artikels: Podman war ursprünglich Teil von CRI-O.
Das Aussehen und die Essenz von Podman
Die offizielle Ankündigung des Podman-Projekts (der Name steht für "Pod Manager")
fand im Februar dieses Jahres statt:
„Podman (früher bekannt als kpod) existiert seit letztem Sommer. Anfangs war es Teil des CRI-O- Projekts. Wir haben podman einem separaten Projekt zugewiesen - libpod . Wir wollten, dass sowohl Podman als auch CRI-O in ihrem eigenen Tempo wachsen. Beide funktionieren sowohl einzeln (als unabhängige Versorgungsunternehmen) als auch zusammen hervorragend. “
Aus diesem Grund wurde die Ankündigung selbst als „
Wiedereinführung“ bezeichnet . Und die erste öffentliche Veröffentlichung von Podman -
v0.2 - fand 2 Wochen vor dieser Ankündigung statt. Was ist die Essenz von Podman?
Podmans Ziel ist es, eine Konsolenschnittstelle zum Starten von Containern außerhalb des Orchestrierungssystems bereitzustellen. Es ist bemerkenswert, dass gestartete Container zu speziellen Gruppen mit gemeinsamen Namespaces kombiniert werden können, d. H. pods - dieses konzept ist dank kubernetes bereits bekannt geworden. Das Projekt folgt der Ideologie der UNIX-Befehle, bei denen jedes Dienstprogramm nur eines tut, aber gut. Ein weiteres wichtiges Detail, das die Entwickler unermüdlich hervorheben, wurde bereits oben in der Ankündigung zitiert: Podman kann sowohl mit CRI-O als auch unabhängig verwendet werden.
Im Allgemeinen besteht die Hauptidee von Podman darin, Kubernetes-Benutzern, die CRI-O als Container-Laufzeit auswählen, ein Analogon zur Docker CLI-Konsolenschnittstelle bereitzustellen (für die Interaktion mit Containern und Images, die in Clustern ausgeführt werden):
„Podman implementiert 38 der 40 in Docker 1.13 definierten Docker-CLI-Befehle (zum Zeitpunkt der Ankündigung im Februar - ca. Übersetzung ). Einige davon haben wir jedoch nicht speziell wiederholt. Zum Beispiel im Zusammenhang mit Docker Swarm - stattdessen empfehlen wir für Pods / Container, die eine Orchestrierung erfordern, die Verwendung von Kubernetes. Außerdem wurden einige Befehle für Docker-Plugins, z. B. Volume-Plugins und für das Netzwerk, nicht implementiert. Eine vollständige Liste der Podman-Befehle und ihrer Entsprechungen in Docker finden Sie auf der Seite Podman Usage Transfer . “
Ein Fragment der Vergleichstabelle für die Befehle Docker und Podman: Die meisten sind gleich, es gibt jedoch auch UnterschiedeHinter dieser sichtbaren Identität in der Benutzeroberfläche verbirgt sich jedoch ein grundlegender Unterschied in der Architektur: Wenn die Docker-CLI mit dem Docker-Dämon kommuniziert, um Befehle auszuführen, ist Podman ein eigenständiges Dienstprogramm, für dessen Arbeit keine Dämonen erforderlich sind.
Zumindest aufgrund dieses architektonischen Unterschieds wäre es richtiger, Podman nicht mit Docker als solchem zu vergleichen, sondern mit crictl, einem Konsolendienstprogramm von
cri-tools (es wird insbesondere für die
Integration von Containerd in Kubernetes verwendet). Und es gibt funktionale Unterschiede: Podman kann gestoppte Container neu starten und bietet auch die Verwaltung von Container-Images. (Einen detaillierteren Vergleich finden Sie im
OpenShift-Blog .)
Mit der
Veröffentlichung von Fedora 28 Atomic Host (im Mai) wurde Podman zum Standard-Containerverwaltungstool für diese Linux-Distribution. Und erst kürzlich, im September, auf der Linux-Konferenz All Systems Go! In Berlin stellte Dan Walsh, der Leiter des Red Hat Container Engineering-Teams, Podman einem noch breiteren Publikum vor - eine Aufzeichnung der Aufführung ist hier zu sehen (aber nur die Präsentation
hier ).
Podman Präsentation bei All Systems Go! 2018Technische Hinweise
Die neueste Podman-Version ist
v0.10.1.3 (vom 18. Oktober) und die neueste
Version mit neuen Funktionen ist
v0.10.1 (12. Oktober), die mehrere neue Teams und zusätzliche Flags enthält.
Podman-Code ist in Go geschrieben und wird unter der kostenlosen Apache-Lizenz 2.0 vertrieben. Ready-to-Install-Pakete sind für Fedora Version 27 und höher verfügbar (es gibt auch
eine Installationsanleitung für Ubuntu). Zu den abhängigen Komponenten, mit denen Podman arbeiten kann, gehören Dienstprogramme für Linux-Container wie
runc und
conmon sowie
CNI-Netzwerk-Plugins .
Sowohl das Starten des Containers mit Podman als auch das anschließende Arbeiten damit ähneln dem üblichen
docker Verwendungsszenario:
$ sudo podman run -dt -e HTTPD_VAR_RUN=/var/run/httpd -e HTTPD_MAIN_CONF_D_PATH=/etc/httpd/conf.d \ -e HTTPD_MAIN_CONF_PATH=/etc/httpd/conf \ -e HTTPD_CONTAINER_SCRIPTS_PATH=/usr/share/container-scripts/httpd/ \ registry.fedoraproject.org/f27/httpd /usr/bin/run-httpd $ sudo podman ps ... $ sudo podman inspect -l ... $ sudo podman logs --latest 10.88.0.1 - - [07/Feb/2018:15:22:11 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:30 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:30 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:31 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:31 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" $ sudo podman top <container_id> UID PID PPID C STIME TTY TIME CMD 0 31873 31863 0 09:21 ? 00:00:00 nginx: master process nginx -g daemon off; 101 31889 31873 0 09:21 ? 00:00:00 nginx: worker process
Für eine praktische Einführung in Podman können Sie auch das entsprechende Katacoda-Online-Skript verwenden: „
Container ohne Docker - Starten von Containern mit Podman und Libpod .“
Besonders hervorzuheben ist das
Pypodman- Projekt, das sich in der aktiven Entwicklung befindet und eine von Python geschriebene Schnittstelle für die Remote-Ausführung von Podman-Befehlen bietet.
Nicht nur Podman: Libpod und das Ökosystem
Zusammen mit Podman wurde in dem Artikel wiederholt das libpod-Projekt erwähnt. Was ist der Unterschied?
Wenn wir über das "vollständige" Projekt von Red Hat sprechen, dann heißt es tatsächlich libpod und
wird auf GitHub mit diesem Namen
gehostet . Heute ist libpod als "Bibliothek für Anwendungen positioniert, die mit dem von Kubernetes populären Konzept der Containerherde arbeiten müssen". Und Podman selbst ist ein Dienstprogramm, das Teil der libpod-Bibliothek ist.
Wenn wir zu einer breiteren Sichtweise der Container zurückkehren, hat Red Hat eine eigene Vision, die mit einer ganzen Reihe von Dienstprogrammen für alle Gelegenheiten zum Leben erweckt wird. Die meisten von ihnen konzentrieren sich auf Repositories mit dem sprechenden Namen
github.com/containers , und dies allein zeigt die offensichtlichen Ambitionen des Unternehmens
(einige dieser Projekte befanden sich
übrigens früher unter github.com/projectatomic ) .
Die Ansichten von Red Hat zur Standardisierung und Entwicklung des Container-Ökosystems sind direkt in der README des libpod-Projekts enthalten:
Über fast alle diese Projekte (runc, container / image, container / storage, CNI, conmon) haben wir bereits im
CRI-O-Review geschrieben . Eine wichtige Ergänzung war jedoch seitdem ein Dienstprogramm zum
Erstellen von Container-Images namens
buildah . Darüber hinaus hat Red Hat bereits vorgefertigte Antworten auf einige andere Anforderungen der modernen Containerwelt, wie z. B.
udica zum Generieren von
SELinux- und
skopeo- Sicherheitsprofilen für die Arbeit mit Remote-Image-Registern.
Zusammenfassen
So wie Red Hat nicht nur hinter seiner Unternehmensplattform für OpenShift-Container steht, sondern auch aktiv am Leben des zugrunde liegenden Open Source-Projekts Kubernetes teilnimmt, verwirklicht das amerikanische Unternehmen seine Sicht auf die moderne IT-Infrastruktur auf einer grundlegenderen Ebene - Die Container selbst, die DevOps- und SRE-Ingenieure sind so besorgt um ihre Orchestrierung. Podman und libpod sind wichtige Komponenten des gesamten Ökosystems, das Red Hat in der Containerwelt mit offenen Standards aufbaut. Wenn Sie sich ansehen, was gerade passiert, dann sieht der am Anfang des Artikels erwähnte Vertrag mit IBM, der als Initiative zur Bildung eines führenden Anbieters von Lösungen im Bereich Hybrid Clouds vorgestellt wird, in der gesamten Branche noch interessanter aus ...
Schließlich schlage ich vor dem Erscheinen dieses Artikels eine kleine Umfrage zum Wissen der Leser der Habra über das Podman-Projekt vor. Vielen Dank für Ihre Teilnahme!
PS
Lesen Sie auch in unserem Blog: