Wenn wir uns die LEGO® Produkte genau ansehen, sehen wir, dass sie alle aus den gleichen Bausteinen bestehen. Die Zusammensetzung dieser Blöcke ist jedoch das entscheidende Unterscheidungsmerkmal dafür, ob wir eine Burg oder ein Raumschiff bauen. Bei Podman und seinen Schwesterprojekten Buildah, Skopeo und CRI-O ist es ziemlich ähnlich. Statt aus recyceltem Plastik bestehen die Bausteine für unsere Container-Tools jedoch aus Open-Source-Code. Durch die gemeinsame Nutzung dieser Bausteine können wir felsenfeste Container-Tools der Enterprise-Klasse bereitstellen. Funktionen werden schneller ausgeliefert, Fehler werden schneller behoben und der Code ist kampferprobt. Und, nun ja, anstatt Freude in Spielzimmer zu bringen, bringen die Container-Tools Freude in Rechenzentren und Workstations.
Der grundlegendste Baustein für unsere Container-Tools ist die Container-/Speicherbibliothek, die Container und Container-Images lokal speichert und verwaltet. Eine Ebene höher finden wir die Container/Image-Bibliothek. Wie der Name schon sagt, befasst sich diese Bibliothek mit Container-Images und ist unglaublich leistungsfähig. Es ermöglicht uns, Bilder zu ziehen und zu verschieben, Bilder zu manipulieren (z. B. die Ebenenkomprimierung zu ändern), Bilder zusammen mit ihrer Konfiguration und ihren Ebenen zu inspizieren und Bilder zwischen sogenannten Bildtransporten zu kopieren. Ein Transport kann sich auf einen lokalen Containerspeicher, eine Containerregistrierung, ein tar-Archiv und vieles mehr beziehen. Dan Walsh hat einen großartigen Blogbeitrag über die verschiedenen Transporte geschrieben, den ich sehr zum Lesen empfehle.
Die Bildbibliothek unterstützt auch mehrere Konfigurationsdateien, darunter zweifellos die registries.conf ist für die überwiegende Mehrheit der Benutzer die wichtigste. Ich möchte diesen Blogbeitrag der registries.conf widmen Konfigurationsdatei, erklären die verschiedenen Optionen und Regler und wie wir sie in der Produktion verwenden können.
Containerregistrierungen mit registries.conf verwalten
Die registries.conf Die Konfiguration ist immer dann im Spiel, wenn wir ein Bild verschieben oder ziehen. Oder allgemeiner gesagt, wann immer wir uns an eine Containerregistrierung wenden. Das ist eine einfache Faustregel. Der systemweite Speicherort ist /etc/containers/registries.conf , aber wenn Sie das für einen einzelnen Benutzer ändern möchten, können Sie eine neue Datei unter $HOME/.config/containers/registries.conf erstellen .
Lassen Sie uns also direkt darauf eingehen. In den folgenden Abschnitten gehen wir einige Beispiele durch, die die verschiedenen Konfigurationsoptionen in der registries.conf erläutern . Die Beispiele sind reale Szenarien und können eine Inspirationsquelle für die Lösung Ihres individuellen Anwendungsfalls sein.
Nach Kurznamen ziehen
Menschen sind faul, und ich bin da keine Ausnahme. Es ist viel bequemer, einen podman pull ubi8 auszuführen statt podman pull Registry.access.redhat.com/ubi8:latest . Ich vergesse immer wieder, welches Image in welcher Registry lebt, und es gibt viele Images und viele Registrys da draußen. Es gibt Docker Hub und Quay.io sowie Registrierungen für Amazon, Microsoft, Google, Red Hat und viele andere Linux-Distributionen.
Docker ging auf unsere Faulheit ein, indem es immer zum Docker Hub auflöste. Ein docker pull alpine wird zu docker.io/library/alpine:latest aufgelöst und docker pull repo/image:tag wird in docker.io/repo/image:tag aufgelöst (beachten Sie das angegebene Repo). Podman und seine Geschwisterprojekte wollten Benutzer nicht an die Verwendung nur einer Registrierung binden, sodass kurze Namen in mehr als docker.io aufgelöst werden können, und wie Sie vielleicht erwarten, können wir dies in der registries.conf wie folgt:
unqualified-search-registries = ['registry.fedoraproject.org', 'registry.access.redhat.com', 'registry.centos.org', 'docker.io']
Das obige Snippet stammt direkt aus der registries.conf in Fedora 33. Es ist eine Liste von Registrierungen, die in der angegebenen Reihenfolge kontaktiert werden, wenn ein Kurznamenbild abgerufen wird. Wenn das Image nicht in der ersten Registrierung gefunden werden kann, versucht Podman, es aus der zweiten Registrierung abzurufen und so weiter. Buildah und CRI-O folgen derselben Logik, beachten Sie jedoch, dass Skopeo immer auf docker.io normalisiert.
[ Das könnte Ihnen auch gefallen: Was ist die nächste Linux-Workload, die Sie containerisieren möchten? ]
Bilder suchen
Ähnlich wie im vorherigen Abschnitt über das Ziehen wird nach Bildern häufig nach Namen gesucht. Bei einer Podman-Suche , weiß ich normalerweise nicht oder habe einfach vergessen, in welcher Registry das angegebene Image gespeichert ist. Wenn Sie Docker verwenden, können Sie nur im Docker Hub suchen. Podman gibt den Benutzern mehr Freiheit und ermöglicht die Suche nach Bildern in jeder Registrierung. Und wenig überraschend registries.conf hat eine Lösung.
Ähnlich wie beim Pullen werden die unqualified-search-registries werden auch bei der Verwendung eines Kurznamens mit podman search verwendet . Ein podman search foo sucht nach Bildern mit dem Namen foo in allen Registern für uneingeschränkte Suche.
Große Unternehmen verfügen in der Regel über lokale Containerregistrierungen. Die Integration solcher Registrierungen in Ihren Arbeitsablauf ist so einfach wie das Hinzufügen zur Liste der Registrierungen für uneingeschränkte Suche.
Kurznamen-Aliase
Neuere Versionen von Podman, Buildah und CRI-O werden mit einer neuen Methode zur Auflösung von Kurznamen ausgeliefert, hauptsächlich durch die Verwendung von Aliasnamen. Aliase sind eine einfache TOML-Tabelle [aliases] in der Form "name" ="value" , ähnlich wie Bash-Aliase funktionieren. Wir pflegen zusammen mit der Upstream-Community unter github.com/containers/shortnames eine zentrale Aliasliste . Wenn Sie ein Bild besitzen und einen Alias haben möchten, können Sie gerne eine Pull-Anfrage öffnen oder sich an uns wenden.
Einige Distributionen, wie RHEL8, planen, ihre eigenen Listen mit Kurznamen zu versenden, um Benutzern zu helfen und sie daran zu hindern, versehentlich Bilder aus der falschen Registrierung zu ziehen.
Eine detaillierte Erläuterung der Funktionsweise von Kurznamen-Aliassen würde diesen Blogbeitrag erheblich erweitern. Wenn Sie also interessiert sind, lesen Sie bitte einen früheren Blogbeitrag zu Kurznamen-Aliassen.
Konfigurieren einer lokalen Containerregistrierung
Das Ausführen einer lokalen Containerregistrierung ist weit verbreitet. Ich habe ständig einen laufen, damit ich Bilder zwischenspeichern und neue Funktionen wie automatische Updates in Podman entwickeln und testen kann. Die Bandbreite in meinem Heimbüro ist begrenzt, daher schätze ich die schnellen Pushs und Pulls. Da alles lokal läuft, brauche ich mich nicht um die Einrichtung von TLS für die Registry zu kümmern. Das bedeutet, dass eine Verbindung zur Registrierung über HTTP statt über HTTPS hergestellt wird. Podman ermöglicht Ihnen dies, indem Sie --tls-verify=false angeben in der Befehlszeile, wodurch die TLS-Überprüfung übersprungen und unsichere Verbindungen zugelassen werden.
Ein alternativer Ansatz zum Überspringen der TLS-Überprüfung über die Befehlszeile ist die Verwendung der registries.conf . Dies kann bequemer sein, insbesondere für automatisierte Skripte, bei denen wir Befehlszeilen-Flags nicht manuell hinzufügen möchten. Werfen wir einen Blick auf das Konfigurations-Snippet unten.
[[registry]]
location="localhost:5000"
insecure=true
Das Format der registries.conf ist TOML. Die doppelten geschweiften Klammern von [[registry]] zeigen an, dass wir eine Liste (oder Tabelle) von [registry] angeben können Objekte. In diesem Beispiel gibt es nur eine Registrierung, in der der Speicherort (d. h. seine Adresse) auf localhost:5000 festgelegt ist . Dort wird normalerweise eine lokale Registrierung ausgeführt. Immer wenn containers/image eine Verbindung zu einer Containerregistrierung mit diesem Speicherort herstellt, sucht sie nach deren Konfiguration und handelt entsprechend. In diesem Fall wird die Registrierung als unsicher konfiguriert und die TLS-Überprüfung wird übersprungen. Podman und die anderen Container-Tools können jetzt mit der lokalen Registrierung kommunizieren, ohne dass die Verbindungen abgelehnt werden.
Blockieren einer Registrierung, eines Namespace oder Images
Falls Sie verhindern möchten, dass Benutzer oder Tools aus einer bestimmten Registrierung abrufen, können Sie wie folgt vorgehen.
[[registry]]
location="registry.example.org"
blocked=true
Der blocked=true verhindert Verbindungen zu dieser Registrierung oder blockiert zumindest das Abrufen von Daten daraus.
Es ist jedoch überraschend üblich, dass Benutzer nur bestimmte Namespaces oder einzelne Images blockieren, nicht jedoch die gesamte Registrierung. Nehmen wir an, wir möchten verhindern, dass Benutzer Bilder aus dem Namespace registry.example.org/namespace ziehen . Die registries.conf sieht nun so aus:
[[registry]]]
location="registry.example.org"
prefix="registry.example.org/example"
blocked=true
Ich habe gerade einen neuen Konfigurationsknopf eingeführt:prefix . Ein Präfix weist an, nur dann die angegebene Konfiguration auszuwählen, wenn wir versuchen, ein Bild abzurufen, das mit dem spezifischen Präfix übereinstimmt. Wenn wir beispielsweise einen Podman-Pull-Registry.example.org/example/image:latest ausführen würden , würde das angegebene Präfix übereinstimmen und Podman würde daran gehindert, das Bild abzurufen. Wenn Sie ein bestimmtes Bild blockieren möchten, können Sie es wie folgt einstellen:
prefix="registry.example.org/namespace/image"
Die Verwendung eines Präfixes ist ein sehr leistungsfähiges Werkzeug, um alle Arten von Anwendungsfällen zu erfüllen. Es kann mit allen Reglern einer [Registry] kombiniert werden . Beachten Sie, dass die Verwendung eines Präfixes optional ist. Wenn nichts angegeben ist, wird das Präfix standardmäßig auf den (obligatorischen) Ort.
Spiegelungsregistrierungen
Nehmen wir an, wir führen unsere Workload in einer Air-Gap-Umgebung aus. Alle unsere Server sind vom Internet getrennt. Dafür gibt es viele Gründe. Wir laufen möglicherweise am Rand oder in einer äußerst sicherheitsrelevanten Umgebung, die uns verbietet, uns mit dem Internet zu verbinden. In diesem Fall können wir keine Verbindung zur ursprünglichen Registrierung herstellen, sondern müssen eine Registrierung ausführen, die den Inhalt des lokalen Netzwerks widerspiegelt.
Ein Registrierungsspiegel ist eine Registrierung, die kontaktiert wird, bevor versucht wird, von der ursprünglichen abzurufen. Es ist ein häufiger Anwendungsfall und eine der ältesten Funktionsanfragen im Container-Ökosystem.
[[registry]]
location="registry.access.redhat.com"
[[registry.mirror]]
location="internal.registry.mirror"
Wenn Sie mit dieser Konfiguration das Universal Base Image über podman pull ubi8 ziehen , würde das Image aus dem Mirror statt aus der Containerregistrierung von Red Hat gezogen.
Beachten Sie, dass wir mehrere Spiegel angeben können, die in der angegebenen Reihenfolge kontaktiert werden. Sehen wir uns kurz an, was das bedeutet:
[[registry]]
location="registry.example.com"
[[registry.mirror]]
location="mirror-1.com"
[[registry.mirror]]
location="mirror-2.com"
[[registry.mirror]]
location="mirror-3.com"
Nehmen wir an, wir versuchen, das Image registry.example.com/myimage:latest abzurufen . Spiegel werden in der angegebenen Reihenfolge (d. h. von oben nach unten) kontaktiert, was bedeutet, dass Podman zuerst versuchen würde, das Bild von mirror-1.com abzurufen . Wenn das Bild nicht vorhanden ist oder der Abruf aus anderen Gründen fehlschlägt, kontaktiert Podman mirror-2.com und so weiter. Wenn alle Mirror-Pulls fehlschlagen, kontaktiert Podman die Haupt-registry.example.com .
Beachten Sie, dass Mirrors auch insecure unterstützen Knopf. Wenn Sie die TLS-Überprüfung für einen bestimmten Spiegel überspringen möchten, fügen Sie einfach insecure=true hinzu .
Remapping-Referenzen
Wie wir oben untersucht haben, ein Präfix wird verwendet, um eine bestimmte [Registry] auszuwählen in der registries.conf . Während Präfixe ein wirksames Mittel sind, um das Abrufen bestimmter Namespaces oder bestimmter Bilder zu blockieren, können sie auch verwendet werden, um ganze Bilder neu zuzuordnen. Ähnlich wie bei Mirrors können wir ein Präfix verwenden, um aus einer anderen Registrierung und einem anderen Namespace zu ziehen.
Um zu veranschaulichen, was ich mit Neuzuordnung meine , nehmen wir an, dass wir in einer Umgebung mit Luftspalt laufen. Wir können nicht auf Containerregistrierungen zugreifen, da wir vom Internet getrennt sind. Unsere Workload verwendet Images von Quay.io, Docker Hub und der Containerregistrierung von Red Hat. Während wir einen netzwerklokalen Spiegel pro Registrierung haben könnten, könnten wir auch nur einen mit der folgenden Konfiguration verwenden.
[[registry]]
prefix="quay.io"
location="internal.registry.mirror/quay"
[[registry]]
prefix="docker.io"
location="internal.registry.mirror/docker"
[[registry]]
prefix="registry.access.redhat.com"
location="internal.registry.mirror/redhat"
Ein podman pull quay.io/buildah/stable:latest wird jetzt stattdessen internal.registry.mirror/quay/buildah/stable:latest ziehen . Das abgerufene Image bleibt jedoch quay.io/buildah/stable:latest da die Neuzuordnung und Spiegelung für Podman und die anderen Container-Tools transparent erfolgen.
Wie wir im obigen Snippet sehen können, internal.registry.mirror ist unser netzwerklokaler Spiegel, den wir verwenden, um Images im Auftrag von Quay.io, Docker Hub und der Containerregistrierung von Red Hat abzurufen. Images jeder Registrierung befinden sich in separaten Namespaces in der Registrierung (z. B. „quay“, „docker“, „redhat“) – ein einfacher, aber leistungsstarker Trick, um Images beim Pullen neu zuzuordnen. Sie fragen sich vielleicht, wie wir den internen Spiegel mit den Bildern aus den drei Registern vorbelegen können. Ich empfehle nicht, dies manuell zu tun, sondern skopeo sync zu verwenden stattdessen. Mit skopeo sync , kann ein Systemadministrator problemlos alle Images auf ein USB-Laufwerk laden, dieses zu einem Air-Gap-Cluster bringen und den Spiegel vorab laden.
Es gibt unzählige Anwendungsfälle, in denen eine solche Neuzuordnung hilfreich sein kann. Wenn Sie beispielsweise während Tests eine andere Registrierung verwenden, kann es praktisch sein, transparent aus einer anderen (Test- oder Staging-)Registrierung als in der Produktion zu ziehen. Es sind keine Codeänderungen erforderlich.
Tom Sweeney und Ed Santiago nutzten das Remapping, um eine kreative Lösung zu entwickeln, um die Ratenbegrenzungen von Docker Hub anzugehen. Ende November 2020 begann Docker Hub damit, die Anzahl der Pulls pro Benutzer in einem bestimmten Zeitraum zu begrenzen. Zuerst waren wir besorgt, weil große Teile unserer Testsysteme und der kontinuierlichen Integration Docker-Hub-Images verwendeten. Aber mit einer einfachen Änderung in der registries.conf Auf unseren Systemen haben Tom und Ed eine großartige Lösung gefunden. Das hat uns die manuelle und langwierige Aufgabe erspart, alle Bilder, die sich auf docker.io beziehen, in unseren Tests zu ändern.
Erweiterte Konfigurationsverwaltung über Drop-On-Konfigurationsdateien
Die Verwaltung von Konfigurationen ist eine Herausforderung. Unsere Systeme werden ständig aktualisiert, und mit den Updates können Konfigurationsänderungen einhergehen. Möglicherweise möchten wir neue Registrierungen hinzufügen, neue Spiegel konfigurieren, vorherige Einstellungen korrigieren oder die Standardkonfiguration von Fedora erweitern. Es gibt viele Beweggründe, und zwar für bestimmte registries.conf unterstützt es über sogenannte Drop-In-Konfigurationsdateien.
Beim Laden der Konfiguration wird die Datei containers/image Die Bibliothek lädt zuerst die Hauptkonfigurationsdatei unter /etc/containers/registries.conf und dann alle Dateien in /etc/containers/registries.conf.d Verzeichnis in alphanumerischer Reihenfolge.
Verwenden einer solchen Drop-in-registries.conf Dateien ist einfach. Platzieren Sie einfach eine .conf Datei im Verzeichnis, und Podman erhält die aktualisierte Konfiguration. Beachten Sie, dass Tabellen in der Konfiguration zusammengeführt werden, während einfache Knöpfe überschrieben werden. Das bedeutet in der Praxis, dass die [[registry]] Tabelle kann einfach um neue Register erweitert werden. Wenn bereits eine Registrierung mit demselben Präfix vorhanden ist, wird die Registrierungseinstellung überschrieben. Gleiches gilt für die [aliases] Tisch. Einfache Konfigurationsknöpfe wie unqualifizierte Suchregistrierungen werden immer überschrieben.
[ Erste Schritte mit Containern? Schauen Sie sich diesen kostenlosen Kurs an. Containerisierte Anwendungen bereitstellen:Eine technische Übersicht. ]
Schlussfolgerung
Die registries.conf ist ein Kernbaustein unserer Container-Tools. Es ermöglicht die Konfiguration aller Arten von Eigenschaften bei der Kommunikation mit einer Containerregistrierung. Wenn Sie daran interessiert sind, die Konfiguration genauer zu studieren, können Sie entweder eine man container-registries.conf erstellen Lesen Sie die Manpage auf Ihrem Linux-Rechner oder besuchen Sie die Upstream-Dokumentation.