Utilizzo di un riferimento di registro dinamico
Il sito IBM Cloud Hyper Protect Virtual Servers per VPC è deprecato. A partire dal 28 febbraio 2026, non sarà più possibile creare nuove istanze. Le istanze esistenti sono supportate fino al 20 febbraio 2027. Tutte le istanze ancora esistenti a quella data saranno eliminate. È possibile distribuire nuovamente i carichi di lavoro utilizzando IBM Confidential Computing Container Runtime(precedentemente noto come Hyper Protect Virtual Servers ) o IBM Confidential Computing Container Runtime for Red Hat Virtualization Solutions(precedentemente noto come Hyper Protect Container Runtime for Red Hat Virtualization Solutions). Per informazioni sulla migrazione dei dati, consultare la guida Migrazione. Per ulteriori informazioni, vedere l'annuncio di deprezzamento del servizio.
È possibile seguire questo tutorial per imparare a utilizzare un riferimento dinamico al registro nel contratto.
Riferimento registro esplicito
In genere, il registro docker è referenziato attraverso il docker completo URL nel file di composizione. Vedi il seguente esempio:
services:
helloworld:
image: docker.io/library/hello-world@sha256:53f1bbee2f52c39e41682ee1d388285290c5c8a76cc92b42687eecf38e0af3f0
Nell'esempio, docker.io/library/ è il prefisso del registro, hello-world è l'identificativo dell'immagine OCI in tale registro e sha256:53f1bbee2f52c39e41682ee1d388285290c5c8a76cc92b42687eecf38e0af3f0 è
l'identificativo univoco della versione dell'immagine.
In tal caso, il ruolo del fornitore del carico di lavoro decide in merito al registro (e alle credenziali di pull associate), poiché sia il riferimento al registro che le credenziali di pull fanno parte della sezione relativa al carico di lavoro del contratto.
Riferimento registro dinamico
In alcuni casi d'uso, il registro non è noto quando la sezione del carico di lavoro è pre-crittografata. Ad esempio, quando il fornitore del carico di lavoro desidera consentire al distributore di utilizzare un mirror del registro o un registro container privato.
In tal caso, è possibile sovrascrivere dinamicamente il registro e le credenziali di pull. Questo sforzo deve essere coordinato tra il fornitore del carico di lavoro e il responsabile della distribuzione.
L'approccio basato sui modelli funziona solo per un carico di lavoro basato sulla composizione e solo per immagini a cui si fa riferimento tramite un digest. I carichi di lavoro basati su DCT non sono supportati.
Provider del carico di lavoro
Il provider del carico di lavoro contrassegna il registro come dinamico utilizzando una variabile di sostituzione nel file di composizione docker:
services:
helloworld:
image: ${REGISTRY}/hpse-docker-hello-world-s390x@sha256:43c500c5f85fc450060b804851992314778e35cadff03cb63042f593687b7347
Il digest dell'immagine è identico in tutti i registri, quindi il fornitore del carico di lavoro può bloccare una versione specifica dell'immagine impostando la chiave, indipendentemente dal registro utilizzato. L'utilizzo dei token nel file di composizione è una funzione nativa della specifica di composizione.
Ora il fornitore del carico di lavoro può preparare (crittografare) la sezione del carico di lavoro senza specificare i segreti di pull per tale registro.
Deployer
Il deployer inserisce le informazioni mancanti relative al registro e ai segreti di pull associati.
Il registro è impostato come variabile di ambiente. Sia il deployer che il fornitore del carico di lavoro possono fornire elementi all'ambiente complessivo e questi elementi vengono sovrapposti con il carico di lavoro che ha la precedenza.
Le credenziali di accesso vengono trasmesse attraverso una sezione auth nella parte del contratto relativa all'ambiente. Proprio come le variabili ambientali, queste auth sezioni sono sovrapposte con la sezione del
carico di lavoro che ha la precedenza.
---
---
env:
type: env
auths:
de.icr.io:
username: xxx
password: yyy
env:
REGISTRY: de.icr.io