Utilización de una referencia de registro dinámico
La dirección IBM Cloud Hyper Protect Virtual Servers para VPC está obsoleta. A partir del 28 de febrero de 2026, no se podrán crear nuevas instancias. Las instancias existentes recibirán asistencia hasta el 20 de febrero de 2027. Se eliminarán todas las instancias que aún existan en esa fecha. Puede redistribuir sus cargas de trabajo utilizando IBM Confidential Computing Container Runtime(antes conocido como Hyper Protect Virtual Servers) o IBM Confidential Computing Container Runtime para soluciones de virtualización Red Hat(anteriormente conocido como Hyper Protect Container Runtime para soluciones de virtualización Red Hat). Para obtener información sobre la migración de datos, consulte la Guía de migración. Para más información, consulte el anuncio de eliminación de servicios.
Puede seguir este tutorial para aprender a utilizar una referencia dinámica al registro en el contrato.
Referencia de registro explícita
Normalmente, se hace referencia al registro docker a través de la dirección completa URL en el archivo de composición. Consulte el ejemplo siguiente:
services:
helloworld:
image: docker.io/library/hello-world@sha256:53f1bbee2f52c39e41682ee1d388285290c5c8a76cc92b42687eecf38e0af3f0
En el ejemplo, docker.io/library/ es el prefijo de registro, hello-world es el identificador de la imagen OCI de dicho registro y sha256:53f1bbee2f52c39e41682ee1d388285290c5c8a76cc92b42687eecf38e0af3f0 es el identificador exclusivo de la versión de la imagen.
En tal caso, la función del proveedor de carga de trabajo decide sobre el registro (y las credenciales de extracción asociadas), ya que tanto la referencia del registro como las credenciales de extracción forman parte de la sección de carga de trabajo del contrato.
Referencia de registro dinámico
En determinados casos de uso, el registro no se conoce cuando la sección de carga de trabajo está precifrada. Por ejemplo, cuando el proveedor de carga de trabajo desea permitir que el implementador utilice un espejo de registro o un registro de contenedores privado.
En ese caso, es posible anular dinámicamente el registro y las credenciales de extracción. Este esfuerzo debe coordinarse entre el proveedor de la carga de trabajo y el implementador.
El enfoque de plantillas solo funciona para cargas de trabajo basadas en composición y solo para imágenes a las que se hace referencia a través de un resumen. Las cargas de trabajo basadas en DCT no son compatibles.
Proveedor de carga de trabajo
El proveedor de carga de trabajo marca el registro como dinámico utilizando una variable de sustitución en el archivo de composición de docker:
services:
helloworld:
image: ${REGISTRY}/hpse-docker-hello-world-s390x@sha256:43c500c5f85fc450060b804851992314778e35cadff03cb63042f593687b7347
El resumen de la imagen es idéntico en todos los registros, por lo que el proveedor de carga de trabajo puede bloquear una versión específica de la imagen estableciendo la clave, independientemente del registro que se utilice. El uso de señales en el archivo de composición es una característica nativa de la especificación de composición.
Ahora el proveedor de carga de trabajo puede preparar (cifrar) la sección de carga de trabajo sin especificar los secretos de extracción para dicho registro.
Desplegador
El implementador introduce la información que falta sobre el registro y los secretos de extracción asociados.
El registro se establece como una variable de entorno. Tanto el implementador como el proveedor de carga de trabajo pueden aportar elementos al entorno general, y estos elementos se superponen dando prioridad a la carga de trabajo.
Las credenciales pull se introducen a través de una sección auth en la parte de entorno del contrato. Al igual que las variables de entorno, estas auth secciones se superponen, teniendo prioridad la sección de carga
de trabajo.
---
---
env:
type: env
auths:
de.icr.io:
username: xxx
password: yyy
env:
REGISTRY: de.icr.io