Zum Hauptinhalt springen

Arbeiten mit Container-Image-Manifest-Listen

· 6 Minuten Lesezeit

podman logo

Arbeiten mit Container-Image-Manifest-Listen

Von Chris Evich GitHub

In diesem Artikel werde ich Podman, Buildah, und Skopeo Container-Tools verwenden, um ein Image zu erstellen, das mehrere Architekturen unter einem einzigen "Namen" unterstützt.

Einfach ausgedrückt ist eine Manifest-Liste nur eine Sammlung von Images mit einigen zusätzlichen Metadaten. Während im Prinzip jede Menge von Images in einer Manifest-Liste sein kann, ist die beabsichtigte Verwendung die Unterbringung von Multi-Plattform- und/oder Multi-Arch- Images. Ansonsten sehen und fühlen sich Manifest-Listen größtenteils wie reguläre Container- Images an. Sie können sie pullen, taggen und ausführen, wie Sie es erwarten würden, mit nur wenigen Ausnahmen.

Zweieinhalb Dinge werden Sie wahrscheinlich überraschen:

  • Manifest-Listen zu Registries pushen
  • Manifest-Listen aus dem lokalen Speicher entfernen.
  • Der podman tag Befehl ist für Manifest-Listen in v3.4 defekt, aber funktioniert in Buildah v1.23.1.

Aufgrund der Art und Weise, wie Image-Name-Referenzen intern verarbeitet werden, sollten Sie nicht die üblichen podman push und podman rmi Unterbefehle verwenden. SIE WERDEN NICHT DAS TUN, WAS SIE ERWARTEN! Stattdessen sollten Sie podman manifest push --all <src> <dest> und podman manifest rm <name> verwenden (ähnlich für buildah). Diese werden die Manifest-Liste selbst pushen/entfernen anstatt der Inhalte. Ähnlich für das Taggen, wenn Sie Podman v3.4 verwenden, nutzen Sie stattdessen den buildah tag Befehl.

Großartig, also klingen Manifest-Listen fantastisch; ich kann sie pullen und ausführen. Ich kann sie mit podman manifest rm löschen, mit podman manifest push --all <src> <dest> pushen und mit Buildah taggen, aber wie kann ich sie erstellen?

Einfacher Modus

Die einfachste Möglichkeit, eine Multi-Arch-Manifest-Liste zu erstellen, besteht darin, Emulation zu aktivieren, um alle nicht-nativen RUN-Anweisungen zu unterstützen. Dies wird durch die Installation des qemu-user-static-Pakets (oder eines Äquivalents) für Ihre Distribution erreicht. Stellen Sie auch sicher, dass der zugehörige systemd-binfmt.service aktiviert/gestartet ist. Nicht alle Distributionen unterstützen diese, also springen Sie zu den nächsten Abschnitten für Details zu anderen Methoden, falls erforderlich.

Angenommen, die Emulation ist vorhanden, schauen wir uns dieses Beispiel Containerfile an:

FROM registry.access.redhat.com/ubi8:latest
RUN uname -a

Das Erstellen eines Multi-Arch-Manifests dafür kann mit einem Build-Befehl gemacht werden. Dies ist dank Funktionen neuerer Versionen von Buildah (v1.23 und später) und Podman (v3.4 und später) möglich:

$ platarch=linux/amd64,linux/ppc64le,linux/arm64,linux/s390x
$ buildah build --jobs=4 --platform=$platarch --manifest shazam .

Die hier verwendeten Schlüsseloptionen sind:

  • --manifest - Fügt das resultierende Image in die benannte Manifest-Liste (shazam) hinzu, erstellt sie, falls sie noch nicht existiert.
  • --platform - Akzeptiert eine kommagetrennte Liste von platform/architecture Tupeln (linux/amd64,linux/ppc64le,linux/arm64,linux/s390x).
  • --jobs - Optional, bewirkt, dass die Builds parallel unter Verwendung der angegebenen Anzahl von Threads (4) ausgeführt werden. D.h., der Build ist viel schneller fertig.

Hinweis: Sogar dieses einfache Containerfile und der Build-Befehl werden ziemlich viel Ausgabe produzieren. Angenommen, es ist erfolgreich, können Sie den folgenden Befehl verwenden, um die Architekturen zu untersuchen:

$ skopeo inspect --raw containers-storage:localhost/shazam | \
jq '.manifests[].platform.architecture'

Ähnlich kann skopeo inspect verwendet werden, um Manifest-Listen auf Registry-Servern zu untersuchen - tauschen Sie einfach containers-storage: gegen docker:// aus. Dies ist sehr nützlich, um zu bestimmen, ob ein Basis-Image eine Manifest-Liste ist, und wenn ja, für welche Architektur die Images erstellt wurden. Das Abfragen von Metadaten auf diese Weise erfordert nicht das Herunterladen aller Daten, daher ist es ziemlich schnell.

Schließlich und wie am Anfang erwähnt, ist das Pushen und Entfernen von Manifest- Listen besonders. Sie müssen manifest push oder manifest rm Unterbefehle verwenden. Andernfalls wird Podman auf den Inhalt statt auf die Manifest-Liste selbst reagieren. Dann müssen Sie beim Push sowohl die Quelle als auch das Ziel angeben. Ein etwas konstruiertes Beispiel könnte sein:

$ buildah tag localhost/shazam quay.io/example/shazam
$ podman manifest rm localhost/shazam
$ podman manifest push --all quay.io/example/shazam docker://quay.io/example/shazam

Wenn Sie nicht sowohl die Quelle als auch das Push-Ziel angeben, erhalten Sie eine Fehlermeldung. Falls Sie sich fragen, das --all Argument ist erforderlich. Dies teilt Podman mit, die Manifest-Liste UND den Inhalt zu pushen, was fast immer das ist, was Sie tun möchten. Wenn Sie die --all Option nicht verwenden, wird nur die native Architektur ohne Warnung oder andere Hinweise gesendet.

Cheat-Modus

Im Fall von öffentlichen Automatisierungsdiensten, wo Bequemlichkeit und einfache Wartung wesentlich sind, gibt es eine Reihe von Container-Images, die qemu-user-static für Sie aktivieren und konfigurieren. Diese Images müssen im --privileged Modus ausgeführt werden, aber werden die Einrichtung im Automatisierungssystem sehr einfach machen (Docs). Einmal eingerichtet, ist die Image-Build-Methode genau dieselbe wie im obigen Abschnitt.

Das gesagt, dies ist keine Befürwortung, und Sie müssen Ihre eigene angemessene Sorgfalt walten lassen. Ich erwähne es nur in diesem Artikel, denn wenn ich es nicht tue, wird es jemand mit Sicherheit zur Sprache bringen. Es ist wahrscheinlich eine gute Einrichtung für kleine, unkritische Fälle. Aber dies wird wahrscheinlich ein "No-Go" sein, wo Herkunft und Sicherheit kritisch sind. Also, wenn das auf Sie zutrifft, fahren Sie mit dem nächsten Abschnitt fort.

Sicherer Modus

In hochsicheren, abgeschotteten Produktionsumgebungen mit kommerziell unterstützten Distributionen ist zusätzliche Sicherheit oft wichtiger als die Bequemlichkeit der Emulation. Zusätzlich, wenn der Build einfach zu komplex, emulationslangsam ist oder mehrere inkompatible Plattformen (d.h. Windows und Darwin) umfasst, dann ist es möglicherweise einfach nicht praktikabel.

In diesen Fällen müssen Sie im Wesentlichen die Builds separat durchführen, die Images auf einem System sammeln und sie dann alle in einer Manifest- Liste als separaten Schritt kombinieren.

Zum Beispiel, nehmen wir an, dass Sie das shazam Image auf mehreren Linux-Hosts erstellt, jeden mit seinem Architekturnamen getaggt und sie zum quay.io/example/shazam Repository gepusht haben. Die Kombination in eine Manifest-Liste könnte so aussehen:

$ REPO=quay.io/example/shazam
$ podman manifest create $REPO:latest
$ for IMGTAG in amd64 s390x ppc64le arm64; do \
podman manifest add $REPO:latest docker://$REPO:IMGTAG; \
done
$ podman manifest push --all $REPO:latest docker://$REPO:latest

Hinweis: Für den manifest add Unterbefehl kommt der Name der Ziel-Manifest-Liste zuerst, dann das hinzuzufügende Image. Im obigen Beispiel wird der Befehl innerhalb der Schleife das plattform-getaggte Image (Metadaten) herunterladen und es in die neue Manifest-Liste hinzufügen. Es ist keine separate pull Operation erforderlich, und Podman wird automatisch die konstituierende Architektur und Plattforminformationen herausfinden. Falls nicht, gibt es Optionen, sie manuell anzugeben während der manifest add Operation. Schließlich, im Falle eines Unfalls, finden Sie einen manifest remove Unterbefehl (gleiche Argumentreihenfolge wie manifest add).

Fazit

Während unzählige zusätzliche Details in den Man-Pages verfügbar sind, sollte dieses grundlegende Wissen 90% Ihrer Bedürfnisse abdecken. Mit diesen wesentlichen Tricks in der Hand ist die Produktion Ihrer eigenen Multi-Arch- und/oder Multi-Plattform-Manifest-Listen nur eine Frage der Übung (oder einiger neuer Bash-Skripte).

Bitte denken Sie auch daran, auf die Tooling-Versionen zu achten, da mehrere Bugs und Mängel in früheren Editionen vorhanden sind. In diesem Zusammenhang, wenn Sie seltsames oder unerwartetes Verhalten antreffen, wenden Sie sich bitte an die Upstream-Community für Unterstützung.