IBM Cloud Docs
Über Container Registry

Über Container Registry

Verwenden Sie IBM Cloud® Container Registry, um private Container-Images in einer hoch verfügbaren und skalierbaren Architektur zu speichern und auf sie zuzugreifen.

Von IBM Cloud Container Registry wird ein hoch verfügbares, skalierbares und verschlüsseltes Multi-Tenant-Registry für private Images bereitgestellt, das von IBM gehostet und verwaltet wird. Sie können Container Registry verwenden, indem Sie Ihren eigenen Image-NamespaceEine Sammlung von Repositorys, die Images in einer Registry speichern. Ein Namensbereich ist einem IBM Cloud -Konto zugeordnet, das mehrere Namensbereiche enthalten kann. einrichten und Container-Images in Ihren Namespace verschieben.

Das Diagramm zeigt, wie IBM Cloud Container Registry mit Bildern interagiert.
So interagiert Container Registry mit Bildern

Jeder Container, den Sie erstellen, basiert auf einem Docker-Image. Ein Image wird aus einem DockerfileEine Textdatei, die Anweisungen für den Build eines Docker-Images enthält. erstellt, einer Datei, die Anweisungen zur Erstellung des Images enthält. Eine Dockerfile kann in ihren Anweisungen auf Buildartefakte verweisen, die separat gespeichert werden, wie z. B. eine App, die Konfiguration der App und ihre Abhängigkeiten. Bilder werden in der Regel in einem Register gespeichert, das entweder für die Öffentlichkeit zugänglich ist (öffentliches Register) oder mit eingeschränktem Zugang für eine Gruppe von Benutzern eingerichtet wird (privates Register). Wenn Sie Container Registry verwenden, können ausschließlich Benutzer mit Zugriff auf Ihr IBM Cloud-Konto auf Ihre Images zugreifen.

Wenn Sie Images mit einer Push-Operation an Container Registry übertragen, profitieren Sie von den integrierten Vulnerability Advisor-Funktionen, die nach potenziellen Sicherheitsproblemen und Sicherheitslücken suchen. Von Vulnerability Advisor werden gefährdete Pakete in bestimmten Docker-Basisimages überprüft und nach bekannten Sicherheitslücken in den Einstellungen der App-Konfigurationen gesucht. Falls Sicherheitslücken gefunden werden, werden die Informationen zu den Sicherheitslücken bereitgestellt. Anhand dieser Informationen können Sie die Sicherheitsprobleme beheben, sodass Container von anfälligen Images nicht bereitgestellt werden.

In der folgenden Tabelle finden Sie eine Übersicht über die Vorteile der Verwendung von Container Registry.

Container Registry vorteile
Nutzen Beschreibung
Hoch verfügbare und skalierbare private Registry. Richten Sie Ihren eigenen Image-Namensraum in einer mandantenfähigen, hochverfügbaren, skalierbaren, verschlüsselten privaten Registry ein, die von IBM gehostet und verwaltet wird.

Speichern Sie Ihre privaten Docker Bilder und teilen Sie sie mit Nutzern in Ihrem IBM Cloud Konto.
Einhaltung von Sicherheitsbestimmungen für Images mit Vulnerability Advisor. Vorteil des automatischen Scannens von Images in Ihrem Namensbereich

Prüfen Sie die betriebssystemspezifischen Empfehlungen, um potenzielle Schwachstellen zu beheben und Ihre Container vor Kompromittierung zu schützen.
Kontingente für Speicher und Pull-Datenverkehr. Profitieren Sie von kostenlosem Speicher und Pull-Datenverkehr für Ihre privaten Images, bis Sie Ihr kostenloses Kontingent aufgebraucht haben.

Festlegen angepasster Kontingente für Speicher und Pull-Datenverkehr pro Monat, um ein Überziehen Ihres bevorzugten Zahlungsbetrags zu vermeiden

Servicepläne

Sie können zwischen einem kostenfreien Serviceplan und einem Standardserviceplan von Container Registry wählen, um Ihre Docker-Images zu speichern und für Benutzer in Ihrem IBM Cloud-Konto zur Verfügung zu stellen.

Der Serviceplan von IBM Cloud Container Registry legt die Speicherkapazität und den Umfang des Pull-Datenverkehrs fest, die/den Sie für Ihre privaten Images verwenden können. Der Serviceplan ist Ihrem IBM Cloud-Konto zugeordnet. Die Begrenzungen für den Speicher und den Pull-Datenverkehr für Images gelten für alle Namensbereiche, die Sie in Ihrem Konto einrichten.

Dienstpläne sind auf die spezifische Registrierungsinstanz (eine der regionalen Registraturen oder die globale Registrierung) beschränkt, mit der Sie gerade arbeiten. Die Planeinstellungen müssen für Ihr Konto in jeder Registry-Instanz separat verwaltet werden. Weitere Informationen finden Sie unter Regionen.

In der folgenden Tabelle sind die verfügbaren IBM Cloud Container Registry-Servicepläne und ihre Merkmale aufgeführt. Weitere Informationen dazu, wie die Abrechnung funktioniert und was geschieht, wenn Sie die Grenzwerte des Serviceplans überschreiten, finden Sie unter Kontingente und Abrechnung.

Container Registry pläne
Merkmale Kostenfrei Standard
Beschreibung. Testen von Container Registry zum Speichern und gemeinsamen Verwenden von Docker-Images. Dieser Plan ist der Standardserviceplan, wenn Sie Ihren ersten Namensbereich in Container Registry einrichten. Bei diesem Serviceplan profitieren Sie von einer unbegrenzten Speichernutzung und einem unbegrenzten Pull-Datenverkehr bei der Verwaltung der Docker-Images für alle Namensbereiche in Ihrem IBM Cloud-Konto.
Speicherkapazität für Images. 500 MB Uneingeschränkt
Pull-Datenverkehr. 5 GB pro Monat Uneingeschränkt
Abrechnung. Falls Sie die Grenzwerte für den Speicher oder den Pull-Datenverkehr überschreiten, können Sie keine Push- oder Pull-Operationen für Images in Bezug auf Ihren Namensbereich ausführen. Weitere Informationen finden Sie unter Kontingente und Abrechnung. Speicher. Die Abrechnung erfolgt auf der Grundlage der Nutzung von GB-Monaten. Die ersten 0,5 GB-Monate sind kostenfrei. Dann werden Sie wie auf der Seite mit den Angebotsdetails angegeben belastet, siehe Container Registry.

Pull-Datenverkehr. Die Abrechnung erfolgt auf der Grundlage der Nutzung in GB pro Monat. Die ersten 5 GB sind kostenfrei. Anschließend erhalten Sie eine Abrechnung, wie auf der Seite mit den Angebotsdetails angegeben. Informationen hierzu finden Sie im Abschnitt Container Registry. Falls Sie Ihre Grenzwerte für den Speicher oder den Pull-Datenverkehr überschreiten, können Sie keine Push- oder Pull-Operationen für Images in Bezug auf Ihren Namensbereich ausführen. Weitere Informationen zum Speicher, zum Pull-Datenverkehr und zum Kostenschätzer finden Sie in Kontingente und Abrechnung.

Kontingente und Abrechnung

Hier finden Sie Informationen und Beispiele zur Funktionsweise der Abrechnung und der Kontingente in Container Registry.

Jedes Image ist aus einer Anzahl von Ebenen aufgebaut, von der jede eine inkrementelle Änderung ausgehend vom Basisimage darstellt. Wenn Sie eine Push- oder Pull-Operation für ein Image durchführen, wird der für jede Ebene benötigte Speicher und Pull-Datenverkehr auf Ihre monatliche Nutzung angerechnet. Identische Ebenen werden automatisch von den Images in Ihrem IBM Cloud-Konto gemeinsam genutzt und bei der Erstellung weiterer Images wiederverwendet. Der Speicher für jede identische Ebene wird nur einmal berechnet, unabhängig davon, wie viele Images in Ihrem Konto auf die Ebene verweisen. Ebenen, die nur durch gelöschte Bilder im Papierkorb referenziert werden, werden nicht berechnet.

Ab dem 1. Februar 2022 werden Gebühren getaggte und ungetaggte Images berechnet.

Kontingentierung und Abrechnung sind auf die spezifische Registerinstanz (eines der regionalen Register oder das globale Register) beschränkt, mit der Sie gerade arbeiten. Kontingenteinstellungen müssen für Ihr Konto in jeder Registry-Instanz separat verwaltet werden. Weitere Informationen finden Sie unter Regionen.

Pull-Datenverkehr über öffentliche Verbindungen wird für Nutzung und Kontingent gezählt. Pull-Datenverkehr über private Verbindungen wird nicht gezählt.

Das folgende Beispiel veranschaulicht Push-Operationen für Images:

Sie führen eine Push-Operation für ein Image in Ihren Namensbereich durch, das auf dem Ubuntu-Image basiert. Das Ubuntu-Image enthält mehrere Ebenen. Da Sie diese Ebenen noch nicht in Ihrem Konto haben, wird der Speicher, den diese Ebenen erfordern, auf Ihre monatliche Nutzung angerechnet.

Zu einem späteren Zeitpunkt erstellen Sie ein zweites Image, das auf dem Ubuntu-Image basiert. Sie nehmen Änderungen am Ubuntu-Basisimage vor, beispielsweise durch Hinzufügen zusätzlicher Befehle oder Dateien zu Ihrer Dockerfile. Jede Änderung stellt eine neue Image-Ebene dar. Wenn Sie das zweite Image per Push-Operation übertragen, erkennt Container Registry, dass alle Ebenen des Basis-Ubuntu-Image bereits in Ihrem Konto gespeichert wurden. Die Speicherung dieser Ebenen wird Ihnen nicht ein zweites Mal in Rechnung gestellt, selbst wenn Sie Ihr Bild in einen anderen Namensraum verschoben haben. Container Registry ermittelt die Anteile aller neuen Ebenen und rechnet die Speichermenge zu Ihrer monatlichen Nutzung hinzu.

Abrechnung für Speicher und Pull-Datenverkehr

In Abhängigkeit von dem Serviceplan, den Sie auswählen, wird Ihnen der monatlich genutzte Speicher und Pull-Datenverkehr in den einzelnen Regionen in Rechnung gestellt.

Speichergebühren

Jeder IBM Cloud Container Registry-Serviceplan beinhaltet ein bestimmtes Speicherkontingent, das Sie nutzen können, um Ihre Docker-Images in den Namensbereichen Ihres IBM Cloud-Kontos zu speichern. Beim Standardtarif wird die Nutzung nach GB-Monaten abgerechnet. Die ersten 0.5 GB-Monate sind jeden Monat kostenlos. Wenn Sie den kostenlosen Tarif nutzen, können Sie Ihre Bilder kostenlos auf Container Registry speichern, bis Sie die Kontingentgrenzen des kostenlosen Tarifs erreicht haben. Ein GB-Monat ist der Durchschnittswert von 1 GB Speicher für einen Monat (730 Stunden).

Das folgende Beispiel bezieht sich auf den Standardplan:

Sie nutzen 5 GB für genau die Hälfte des Monats, dann übertragen Sie einige Images per Push-Operation an Ihren Namensbereich und nutzen 10 GB für den Rest des Monats. Ihre monatliche Nutzung wird wie im folgenden Beispiel ersichtlich berechnet:

(5 GB x 0,5 (Monate)) + (10 GB x 0,5 (Monate)) = 2,5 + 5 = 7,5 GB-Monate

Im Standardtarif sind die ersten 0.5 GB-Monate jeden Monat kostenlos, so dass Sie für 7 GB-Monate ( 7.5 GB-Monate - 0.5 GB-Monate) berechnet werden.

Gebühren für Pull-Datenverkehr

Jeder IBM Cloud Container Registry-Serviceplan beinhaltet ein bestimmtes Kontingent an kostenfreiem Pull-Datenverkehr zu Ihren privaten Images, die in Ihrem Namensbereich gespeichert sind. Der Pull-Datenverkehr ist die Bandbreite, die Sie verwenden, wenn Sie eine Ebene eines Images aus Ihrem Namensbereich mit einer Pull-Operation an den lokalen Computer übertragen. Beim Standardtarif wird die Nutzung nach GB pro Monat abgerechnet. Die ersten 5 GB jeden Monat sind kostenfrei. Wenn Sie den kostenlosen Tarif nutzen, können Sie Bilder aus Ihrem Namensraum abrufen, bis Sie das Kontingent für den kostenlosen Tarif erreicht haben.

Pull-Datenverkehr über öffentliche Verbindungen wird für Nutzung und Kontingent gezählt. Pull-Datenverkehr über private Verbindungen wird nicht gezählt.

Das folgende Beispiel bezieht sich auf den Standardplan:

In diesem Monat haben Sie Bilder gezogen, die Ebenen mit einer Gesamtgröße von 14 GB enthalten. Ihre monatliche Nutzung wird wie im folgenden Beispiel ersichtlich berechnet:

Im Standardplan sind die ersten 5 GB pro Monat kostenfrei, sodass Ihnen 9 GB (14 GB - 5 GB) berechnet werden.

Größenbeschränkungen für Speicher und Pull-Datenverkehr

In Abhängigkeit von dem Serviceplan, den Sie auswählen, können Sie für die einzelnen Regionen Images per Push- und Pull-Operationen in und aus Ihrem Namensbereich übertragen, bis Ihr planspezifisches oder angepasstes Kontingent erreicht ist.

Speicherkontingentgrenzwerte

Wenn Sie die Kontingentgrenze für Ihren Plan erreichen oder überschreiten, können Sie keine Images mehr per Push-Operation in die Namensbereiche Ihres IBM Cloud-Kontos übertragen, bis Sie einen der folgenden Schritte ausführen.

Das folgende Beispiel bezieht sich auf den Standardplan:

Ihr aktuelles Speicherkontingent ist auf 1 GB festgelegt. Alle privaten Images zusammen, die in den Namensbereichen Ihres IBM Cloud-Kontos gespeichert sind, belegen bereits 900 MB dieses Speicherplatzes. Es stehen Ihnen 100 MB Speicherplatz zur Verfügung, bis Sie Ihr Kontingent ausgeschöpft haben. Ein Benutzer möchte ein 2 GB großes Image auf den lokalen Computer übertragen. Da das Kontingentgrenze noch nicht erreicht ist, lässt Container Registry zu, dass der Benutzer dieses Image mit einer Push-Operation überträgt.

Nach dem Push ermittelt Container Registry die tatsächlichen Proportionen des Bildes in Ihrem Namensraum, die von den Proportionen auf Ihrem lokalen Computer abweichen können, und prüft, ob das Limit für die Speicherung erreicht ist. In diesem Beispiel erhöht sich die Speicherbelegung von 900 MB um 2 GB. Ist das aktuelle Kontingent auf 1 GB gesetzt, verhindert Container Registry die Push-Operation in den Namensbereich für weitere Images.

Kontingente für Pull-Datenverkehr

Wenn Sie die Kontingentgrenze für Ihren Plan erreichen oder überschreiten, können Sie keine Images mehr per Pull-Operation aus den Namensbereichen Ihres IBM Cloud-Kontos extrahieren, bis Sie einen der folgenden Schritte ausführen.

Pull-Datenverkehr über öffentliche Verbindungen wird für Nutzung und Kontingent gezählt. Pull-Datenverkehr über private Verbindungen wird nicht gezählt.

Das folgende Beispiel bezieht sich auf den Standardplan:

In einem Monat ist Ihr Kontingent für Pull-Datenverkehr auf 5 GB festgelegt. Sie haben bereits Images per Pull-Operation aus Ihren Namensbereichen übertragen und 4,5 GB dieses Pull-Datenverkehrs genutzt. Es stehen Ihnen 0,5 GB für den Pull-Datenverkehr zur Verfügung, bis das Kontingent ausgeschöpft ist. Ein Benutzer möchte ein 1-GB-Image aus Ihrem Namespace abrufen. Da die Kontingentgrenze noch nicht erreicht ist, lässt Container Registry zu, dass der Benutzer dieses Image mit einer Pull-Operation überträgt.

Nachdem das Image per Pull-Operation übertragen wurde, bestimmt Container Registry die Bandbreite, die Sie während der Pull-Operation verwendet haben, und prüft, ob der Grenzwert für den Pull-Datenverkehr erreicht ist. In diesem Beispiel erhöht sich der Pull-Datenverkehr von 4,5 GB auf 5,5 GB. Ist das aktuelle Kontingent auf 5 GB gesetzt, verhindert Container Registry die Pull-Operation aus Ihrem Namensbereich für weitere Images.

Kosten für Container Registry

Sie können die Kosten für IBM Cloud Container Registry im Abschnitt mit den Preistarifen auf der Seite mit den Angebotsdetails einsehen (siehe Container Registry).

Upgrade für den Serviceplan durchführen

Sie können ein Upgrade für Ihren Serviceplan durchführen, um von unbegrenztem Speicher und Pull-Datenverkehr zu profitieren und die Docker-Images für alle Namensbereiche in Ihrem IBM Cloud-Konto zu verwalten.

Wenn Sie herausfinden möchten, welchen Serviceplan Sie für die Registry-Region verwenden, die Sie anvisieren, führen Sie den Befehl ibmcloud cr plan aus.

Führen Sie die folgenden Schritte aus, um für Ihren Serviceplan ein Upgrade durchzuführen.

  1. Melden Sie sich bei IBM Cloud an.

    ibmcloud login

    Falls Sie über eine föderierte ID verfügen, geben Sie ibmcloud login --sso ein, um sich an der Befehlszeilenschnittstelle von IBM Cloud anzumelden. Geben Sie Ihren Benutzernamen ein und verwenden Sie die bereitgestellte URL in Ihrer CLI-Ausgabe, um Ihren einmaligen Kenncode abzurufen. Wenn Sie über eine eingebundene ID verfügen, schlägt die Anmeldung ohne die Option --sso fehl; mit der Option --sso ist sie erfolgreich.

  2. Visieren Sie die Region an, für die Sie ein Planupgrade durchführen möchten.

    ibmcloud cr region-set

    Weitere Informationen finden Sie in ibmcloud cr region-set und in Regionen.

  3. Upgrade auf Standardplan durchführen.

    ibmcloud cr plan-upgrade standard

    Wenn Sie über einen Lite-Plan für IBM Cloud verfügen, müssen Sie ein Upgrade auf ein Pay-as-you-go- oder Abonnementkonto für IBM Cloud durchführen, bevor Sie ibmcloud cr plan-upgradeausführen.

    Weitere Informationen finden Sie unter ibmcloud cr plan-upgrade.

In IBM Cloud Container Registry verwendete Begriffe

Informationen zu den in IBM Cloud Container Registry verwendeten Begriffen.

Weitere Informationen zu Docker-spezifischen Begriffen finden Sie unter Docker glossary.

Container-Image

Ein Dateisystem und seine Ausführungsparameter, die in einer Containerlaufzeit zum Erstellen eines Containers verwendet werden. Das Dateisystem besteht aus einer Reihe von Layern, die erstellt werden, wenn das Container-Image durch aufeinanderfolgende Aktualisierungen erstellt wird, und zur Laufzeit miteinander kombiniert werden. Das Container-Image behält seinen Zustand nicht bei, wenn der Container läuft.

Container-Images werden in einem Repository gespeichert, das sich in einem Namensbereich befindet.

Digest

Digests werden als unveränderliche Verweise auf verschiedene Objekte in der Registry, wie Imagemanifeste, Ebenen und Konfigurationselemente, verwendet.

Im Kontext der Registry ist ein Image-Digest ein unveränderlicher Verweis auf ein Image, das ein Image mithilfe des sha256-Hashwerts eines Imagemanifests angibt. Sie können einen Image-Digest verwenden, um sicherzustellen, dass Sie immer auf dieselbe Version eines Image verweisen. Verwenden Sie das Langformat des Image-Digests für die Arbeit mit Images, beispielsweise für das das Extrahieren, Übertragen und Löschen von Images.

Führen Sie den Befehl ibmcloud cr image-digests aus, um den Image-Digest zu suchen. Der Befehl ibmcloud cr image-list gibt auch den Image-Digest zurück, er hat jedoch standardmäßig ein abgeschnittenes Format. Sie können dem Befehl ibmcloud cr image-list eine Option hinzufügen, um den Image-Digest im Langformat zurückzugeben.

Wenn Sie den Digest zum Identifizieren eines Image verwenden, verwenden Sie immer das Langformat.

In Container Registry bedeutet jeder Verweis auf "digest" "image digest".

Dockerfile

Eine Dockerfile ist eine Textdatei, die Anweisungen zur Erstellung eines Docker-Image enthält.

Im Normalfall baut ein Container-Image auf einem Basisimage auf, das ein Basisbetriebssystem wie z. B. Ubuntu enthält. Sie können mit den Dockerfile-Anweisungen schrittweise das Basisimage ändern, um die Umgebung zu definieren, die die App für die Ausführung benötigt. Jede Änderung am Basisimage beschreibt eine neue Imageebene und Sie können mehrere Änderungen in einer einzelnen Dockerfilezeile vornehmen. Die Anweisungen in einer Dockerfile können auch auf Buildartefakte verweisen, die separat gespeichert sind (z. B. eine App, die Konfiguration der App und ihre Abhängigkeiten). Weitere Informationen über Dockerfile finden Sie unter Dockerfile-Referenz.

Docker V2-Container-Images

Ein Container-Image, das mit der Spezifikation Image Manifest Version 2, Schema 2 konform ist.

Der Medientyp für Docker Image Manifest V2, Schema 2 ist application/vnd.docker.distribution.manifest.v2+json und der Medientyp für die Manifestliste ist application/vnd.docker.distribution.manifest.list.v2+json. Ein Docker V2-Container-Image ist ein Typ von OCI-Container-Image. Weitere Informationen zur Unterstützung von Docker finden Sie unter Docker.

Domänenname

Der Name eines Hostsystems. Ein Domänenname besteht aus einer Folge von Unternamen, die durch ein Begrenzungszeichen getrennt sind, z. B. www.ibm.com.

Die von Container Registry verwendeten Domänennamen haben das Format us.icr.io. Frühere von Container Registry verwendete Domänennamen haben das Format registry.ng.bluemix.net. Beide Formate des Domänennamens beziehen sich auf dieselbe Registry und denselben Inhalt. Der Container Registry-Service reagiert gleichermaßen auf frühere und auf kanonische Domänennamen. Sie können Images mit Push- oder Pull-Operationen übertragen, indem Sie einen der beiden Domänennamen austauschbar verwenden.

Der Domänenname ist nur in den folgenden Situationen von Bedeutung:

  • Wenn Kubernetes einen geheimen Schlüssel für Pull-Operationen auswählt, wird ein Schlüssel ausgewählt, der dem Domänennamen entspricht.
  • Wenn ibmcloud cr login Sie bei der Anmeldung unterstützt, werden nur Domänennamen im Format us.icr.io verwendet.
  • Wenn Images signiert werden, enthält die Signatur den Domänennamen, der beim Signieren verwendet wurde.

Weitere Informationen zu den Domänennamen, die von Container Registry verwendet werden, finden Sie unter Regionen.

Imagemanifest

Ein Imagemanifest ist ein .json-Dokument, das auf das Konfigurationsobjekt und die Imageebenen verweist, die zum Extrahieren und Ausführen des Image erforderlich sind. Der sha256-Hashwert des Imagemanifests ist der Digest, mit dem das Image identifiziert wird. Sie können das Imagemanifest anzeigen, indem Sie den Befehl ibmcloud cr manifest-inspect ausführen.

OCI-Container-Images

Ein Container-Image, das mit der OCI-Image-Format-Spezifikation konform ist.

Der Medientyp für OCI-Container-Images ist application/vnd.oci.image.manifest.v1+json.

Registry

Ein Speicher- und Verteilungsservices für öffentliche oder private Container-Images.

Für OCI-Container-ImagesEin Container-Image, das mit der OCI Image Format Specification kompatibel ist (auch bekannt als Docker Container-Images) wird Speicherplatz bereitgestellt. OCI-Clients, die den entsprechenden Registry-Domänennamen verwenden, können auf OCI-Container-Images zugreifen (d. h. für diese eine so genannte 'Pull'-Operation ausführen). Auf Container-Images kann jeder (öffentliche Images) zugreifen oder der Zugriff kann auf eine Gruppe (private Images) beschränkt werden. Container Registry stellt eine hoch verfügbare private Multi-Tenant-Image-Registry bereit, die von IBM gehostet und verwaltet wird. Sie können die Registry verwenden, indem Sie einen privaten Namensbereich für Ihr Konto hinzufügen und dann Images per Push-Operationen an Ihren Namensbereich übertragen.

Registry-Namensbereich

Ein Ordner, der Ordner oder Repositories enthält, die Ihre Container-Images in Container Registry speichern. Der Registry-Namensbereich ist Ihrem IBM Cloud-Konto zugeordnet. Sie können in Ihrem Konto über mehrere Registry-Namensbereiche verfügen.

Wenn Sie Ihren eigenen Namensraum in Container Registry einrichten, wird der Namensraum an die Registrierung URL <region>.icr.io/<my_namespace> angehängt, wobei <region> die Region und <my_namespace> Ihr Namensraum ist. Der Namensbereich muss für alle IBM Cloud-Konten in derselben Region eindeutig sein. Jeder Benutzer in Ihrem IBM Cloud-Konto, der über die richtigen IAM-Berechtigungen verfügt, kann Bilder, die in Ihrem Registrierungsnamensraum gespeichert sind, anzeigen und mit ihnen arbeiten.

Sie können in jeder Region über 100 Namensbereiche verfügen.

Namensräume werden in einer von Ihnen festgelegten Ressourcengruppe erstellt, so dass Sie den Zugriff auf Ressourcen innerhalb des Namensraums auf der Ebene der Ressourcengruppe konfigurieren können. Wenn Sie keine Ressourcengruppe angeben und keine Ressourcengruppe als Ziel angegeben ist, wird die Standardressourcengruppe verwendet. Wenn Sie einen älteren Namespace haben, der sich nicht in einer Ressourcengruppe befindet, können Sie ihn einer Ressourcengruppe zuweisen und dann die Berechtigungen für diesen Namespace auf der Ebene der Ressourcengruppe festlegen. Weitere Informationen zu Ressourcengruppen finden Sie in Namensbereiche zu Ressourcengruppen zuordnen.

Namensbereiche, die einer Ressourcengruppe zugeordnet sind, werden auf der Seite Ressourcenliste der IBM Cloud-Konsole angezeigt.

Repository

Speichert eine Sammlung zusammengehöriger Container-Bilder. Ein Repository wird in einem Namespace gespeichert. Die Container-Images werden nur durch Tag oder Digest unterschieden. Der Begriff "Repository" wird oft synonym mit "Container-Image" verwendet, aber ein Repository enthält potenziell mehrere mit Tags versehene Varianten eines Container-Images.

Tag

Eine Kennung, die Container-Images in einem Repository zugeordnet ist. Tags können neu zugewiesen oder aus Images gelöscht werden.

Sie können TagsEine benutzerdefinierte Kennung, die einer Gruppierung von Ressourcen in einem Konto zugeordnet ist. Tags sind im gesamten Konto sichtbar. verwenden, um verschiedene Versionen desselben Basisbildes innerhalb eines Repositorys zu unterscheiden. Wenn Sie einen Docker-Befehl ausführen und den Tag eines Repository-Image nicht angeben, wird das Image, das mit dem Tag latest versehen ist, standardmäßig verwendet.

Ungetaggtes Image

Ein Image, das keinen Tag enthält, ist ein nicht mit Tags gekennzeichnetes Image. Auf Images ohne Tag kann im Gegensatz zum Tagreferenzformat <repository>:<tag> mit dem Digestreferenzformat <repository>@<digest> verwiesen werden. Images ohne Tags entstehen normalerweise, wenn ein Image mit einer bereits vorhandenen Kombination von <repository>:<tag> im Rahmen einer Push-Operation gesendet wird. In diesem Fall wird das Tag überschrieben und das Originalbild wird nicht markiert.

Images ohne Tags können unter Verwendung des Befehls ibmcloud cr image-digests angezeigt und mit dem Befehl ibmcloud cr image-prune-untagged bereinigt werden.

Regionen

Die Standardinstanz von Container Registry ist die globale Registry. Die globale Registry enthält keine Region in ihrem Domänennamen (icr.io).

Verwenden Sie die globale Instanz der Registry, es sei denn, Sie haben eine bestimmte Anforderung, zum Beispiel die Datenhoheit, um Ihre Daten in einer bestimmten Region zu speichern. In diesem Fall können Sie Container Registry in lokalen Regionenverwenden.

Jede Region wird in einer anderen Region gesichert. So werden beispielsweise die Bilder, die in der Registrierung IBM Cloud Container Registry Frankfurt(eu-de) gespeichert sind, über die sechs Rechenzentren in den Regionen Frankfurt(eu-de) und London(eu-gb) repliziert.

Die folgende Tabelle zeigt Ihnen die Speicherorte der Sicherungskopien. Weitere Informationen zu Container Registry Sicherungsorten finden Sie unter Repliziert der Dienst die Daten?

Sicherungspositionen
Umgebung Umgebung, die früher bekannt war als Aktiver Standort Sicherungsstandort
au-syd ap-south au-syd jp-tok
br-sao Nicht zutreffend br-sao us-south
ca-tor Nicht zutreffend ca-tor us-east (Service- und Richtlinieneinstellungen)

ca-mon (Images)
eu-de eu-central eu-de eu-gb
eu-es Nicht zutreffend eu-es eu-de
eu-gb uk-south eu-gb eu-de
global Nicht zutreffend us-east us-south
jp-osa Nicht zutreffend jp-osa jp-tok
jp-tok ap-north jp-tok au-syd
us-south Nicht zutreffend us-south us-east

Alle Registry-Artefakte sind auf die spezifische Registry-Instanz (eine der regionalen Registrys oder die globale Registry) beschränkt, mit der Sie gerade arbeiten. Beispielsweise müssen alle Namensbereiche, Bilder, Kontingent- und Planeinstellungen für Ihr Konto in jeder Registry-Instanz separat verwaltet werden.

Globale Registry

Es ist eine globale Registry verfügbar. Die globale Registry hat keine Region in ihrem Namen (icr.io). Diese Registry hostet nicht nur Namensbereich und Images von Benutzern, sondern auch öffentliche Images, die von IBM bereitgestellt werden.

Die globale Instanz von Container Registry ist über die in der folgenden Tabelle aufgeführten Domainnamen verfügbar.

Domänenname für das globale Register
Registry Domänenname Name der privaten Domäne Veralteter Domänenname
Global icr.io private.icr.io registry.bluemix.net

Informationen zum Herstellen einer Verbindung zu Container Registry über die privaten Domänennamen finden Sie unter Private Netzverbindungen verwenden.

Die bereits vorhandenen Domänennamen des Typs bluemix.net sind zwar veraltet, Sie können sie jedoch zurzeit noch nutzen. Allerdings ist noch kein Datum bekannt, an dem die Unterstützung endet.

Globale Registry anvisieren

Sie können die globale Registry als Ziel verwenden, indem Sie den Befehl ibmcloud cr region-set ausführen.

  1. Führen Sie den folgenden Befehl aus, um die globale Registry als Ziel zu definieren.

    ibmcloud cr region-set global

  2. Um Ihren lokalen Docker-Dämon bei der globalen Registry anzumelden, führen Sie den Befehl ibmcloud cr login aus.

    Container Registry unterstützt andere Clients sowie Docker. Informationen zur Anmeldung mit anderen Clients finden Sie im Abschnitt zum interaktiven Zugriff auf Namensbereiche.

Lokale Regionen

Regionale Instanzen von Container Registry sind über die Domainnamen verfügbar, die in der folgenden Tabelle aufgeführt sind.

Domänennamen für lokale Regionen
Lokale Registry-Region Region, die früher bekannt war als Domänenname Name der privaten Domäne Veralteter Domänenname
au-syd ap-south au.icr.io private.au.icr.io registry.au-syd.bluemix.net
br-sao Nicht zutreffend br.icr.io private.br.icr.io Nicht zutreffend
ca-tor Nicht zutreffend ca.icr.io private.ca.icr.io Nicht zutreffend
eu-de eu-central de.icr.io private.de.icr.io registry.eu-de.bluemix.net
eu-es Nicht zutreffend es.icr.io private.es.icr.io Nicht zutreffend
eu-gb uk-south uk.icr.io private.uk.icr.io registry.eu-gb.bluemix.net
jp-osa Nicht zutreffend jp2.icr.io private.jp2.icr.io Nicht zutreffend
jp-tok ap-north jp.icr.io private.jp.icr.io Nicht zutreffend
us-south Nicht zutreffend us.icr.io private.us.icr.io registry.ng.bluemix.net

Informationen zum Herstellen einer Verbindung zu Container Registry über die privaten Domänennamen finden Sie unter Private Netzverbindungen verwenden.

Die bereits vorhandenen Domänennamen des Typs bluemix.net sind zwar veraltet, Sie können sie jedoch zurzeit noch nutzen. Allerdings ist noch kein Datum bekannt, an dem die Unterstützung endet.

Lokale Region anvisieren

Wenn Sie eine andere als Ihre lokale Region verwenden möchten, können Sie die Region, auf die Sie zugreifen möchten, ansteuern, indem Sie den Befehl ibmcloud cr region-set verwenden. Sie können den Befehl ohne Optionen ausführen, um eine Liste der verfügbaren Regionen abzurufen, oder Sie können die Region als Option angeben.

  1. Um den Befehl mit Optionen auszuführen, ersetzen Sie REGION durch den Namen der Region.

    ibmcloud cr region-set REGION

    Wenn Sie beispielsweise die Region eu-de anvisieren möchten, führen Sie den folgenden Befehl aus.

    ibmcloud cr region-set eu-de

  2. Um Ihren lokalen Docker-Dämon in der Registry anzumelden, so dass Sie Images verschieben oder abrufen können, führen Sie den Befehl ibmcloud cr login aus.

    Container Registry unterstützt andere Clients sowie Docker. Informationen zur Anmeldung mit anderen Clients finden Sie im Abschnitt zum interaktiven Zugriff auf Namensbereiche.

Unterstützte Kunden

Unterstützung für Docker

IBM Cloud Container Registry unterstützt die Versionen von Docker Engine, die Docker unterstützt.

Docker ist nur für die Ausführung von Push- oder Pull-Operationen für Images erforderlich.

Docker V2 Schema 2-Images werden unterstützt. Manifestlisten werden ebenfalls unterstützt. Weitere Informationen finden Sie unter Kompatibilität der Registry.

Docker V2 Schema 1-Images werden nicht weiter unterstützt und können nicht mehr per Push-Operation in Container Registry übertragen werden.

Unterstützung für andere Kunden

IBM Cloud Container Registry unterstützt unterstützte Versionen von Clients, die mit der OCI-Distributionsspezifikation Version 1 oder höher kompatibel sind, z. B. Buildah, Podman und Skopeo.