Dynamische Registry-Referenz verwenden
Die IBM Cloud Hyper Protect Virtual Servers für VPC ist veraltet. Ab dem 28. Februar 2026 können Sie keine neuen Instanzen mehr anlegen. Bestehende Instanzen werden bis zum 20. Februar 2027 unterstützt. Alle Instanzen, die zu diesem Zeitpunkt noch existieren, werden gelöscht. Sie können Ihre Workloads mit IBM Confidential Computing Container Runtime(früher bekannt als Hyper Protect Virtual Servers ) oder IBM Confidential Computing Container Runtime for Red Hat Virtualization Solutions(früher bekannt als Hyper Protect Container Runtime for Red Hat Virtualization Solutions) neu bereitstellen. Informationen zur Datenmigration finden Sie in der Anleitung zur Migration. Weitere Informationen finden Sie in der Ankündigung zur Abschaffung des Dienstes.
In diesem Tutorial erfahren Sie, wie Sie eine dynamische Registrierungsreferenz im Vertrag verwenden können.
Explizite Registry-Referenz
Normalerweise wird die Docker-Registry über die vollständige Docker-Adresse URL in der Compose-Datei referenziert. Sehen Sie sich das folgende Beispiel an:
services:
helloworld:
image: docker.io/library/hello-world@sha256:53f1bbee2f52c39e41682ee1d388285290c5c8a76cc92b42687eecf38e0af3f0
Im Beispiel ist docker.io/library/ das Registry-Präfix, hello-world ist die ID des OCI-Image in dieser Registry und sha256:53f1bbee2f52c39e41682ee1d388285290c5c8a76cc92b42687eecf38e0af3f0 ist die eindeutige
ID der Version des Image.
In einem solchen Fall entscheidet die Rolle des Workload-Anbieters über die Registrierung (und die zugehörigen Pull-Anmeldedaten), da sowohl die Registrierungsreferenz als auch die Pull-Anmeldedaten Teil des Workload-Abschnitts des Vertrags sind.
Dynamische Registry-Referenz
In bestimmten Anwendungsfällen ist die Registrierung nicht bekannt, wenn der Workload-Abschnitt vorverschlüsselt ist. Beispielsweise wenn der Workload-Anbieter dem Bereitsteller die Verwendung eines Registrierungsspeegels oder einer privaten Containerregistrierung gestatten möchte.
In diesem Fall ist es möglich, die Registrierung und die Pull-Anmeldedaten dynamisch zu überschreiben. Diese Bemühungen müssen zwischen dem Workload-Anbieter und dem Bereitsteller koordiniert werden.
Der Template-Ansatz funktioniert nur für eine auf Compose basierende Workload und nur für Images, auf die über einen Digest verwiesen wird. DCT-basierte Workloads werden nicht unterstützt.
Workload-Provider
Der Workload-Provider markiert die Registry als dynamisch, indem er eine Ersatzvariable in der Docker Compose-Datei verwendet:
services:
helloworld:
image: ${REGISTRY}/hpse-docker-hello-world-s390x@sha256:43c500c5f85fc450060b804851992314778e35cadff03cb63042f593687b7347
Der Digest des Images ist in allen Registern identisch, sodass der Workload-Anbieter eine bestimmte Version des Images durch Festlegen des Schlüssels sperren kann, unabhängig davon, welches Register verwendet wird. Die Verwendung von Tokens in der Erstellungsdatei ist ein natives Feature der Erstellungsspezifikation.
Jetzt kann der Workload-Provider den Workloadabschnitt vorbereiten (verschlüsseln), ohne die geheimen Pull-Schlüssel für diese Registry anzugeben.
Bereitsteller
Der Bereitsteller gibt die fehlenden Informationen zur Registrierung und die zugehörigen Pull-Geheimnisse ein.
Die Registry wird als Umgebungsvariable festgelegt. Sowohl der Deployer als auch der Workload-Anbieter können Teile zur Gesamtumgebung beitragen, wobei diese Teile mit der Workload überlagert werden, die Vorrang hat.
Die Pull-Zugangsdaten werden über einen Abschnitt auth im Umweltteil des Vertrags übermittelt. Genau wie Umgebungsvariablen werden diese auth Abschnitte mit dem Workload-Abschnitt überlagert, der Vorrang hat.
---
---
env:
type: env
auths:
de.icr.io:
username: xxx
password: yyy
env:
REGISTRY: de.icr.io