Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Utilizzo di registri di terze parti supportati dalla cache pull through

Puoi utilizzare le regole di pull through cache di Amazon ECR per sincronizzare i repository in un registro upstream supportato con i tuoi repository privati Amazon ECR. Per ulteriori informazioni, consulta Sincronizzazione di un registro upstream nel Guida per l'utente di Amazon Elastic Container Registry.

La prima volta che un'immagine viene estratta, il pull through cache crea il repository di immagini nel registro privato e lo mantiene sincronizzato con l'immagine originale, a condizione che i tag dell'immagine del repository rimangano modificabili.

HealthOmics supporta la cache pull through per i seguenti registri upstream:

Per i registri che non supportano il pull through della cache, HealthOmics copia le immagini nei tuoi repository privati Amazon ECR. Per ulteriori informazioni, consulta Utilizzo di registri di terze parti non supportati dalla cache pull through.

I vantaggi dell'utilizzo della cache pull through di Amazon ECR includono:

Prerequisiti

Se un registro upstream richiede l'autenticazione, AWS Secrets Manager il segreto deve essere nello stesso Account AWS e Region come regola di pull through cache. Quando crei la regola, passa --credential-arn l'ARN del segreto esattamente come lo restituisce Secrets Manager, incluso il suffisso che Secrets Manager aggiunge al nome. Il Secrets Manager create-secret e describe-secret entrambe le risposte lo restituiscono. Gli ARN di esempio in questo argomento abbreviano il nome segreto.

Il nome segreto deve iniziare con ecr-pullthroughcache/. Per gli altri requisiti, vedere Archiviazione delle credenziali del repository upstream in un AWS Secrets Manager segreto nel Guida per l'utente di Amazon Elastic Container Registry.

Configurazione della cache pull through

Amazon ECR fornisce un registro per i tuoi Account AWS in ogni regione. Assicurati di creare la configurazione Amazon ECR nella stessa regione in cui intendi eseguire il flusso di lavoro.

Completa le seguenti attività di configurazione in ordine. Il passaggio 4 si applica solo se la definizione del flusso di lavoro utilizza gli URI delle immagini a monte.

Fase 1: Creazione di una regola di pull through cache

Crea una regola di cache pull through di Amazon ECR per ogni registro upstream contenente immagini da memorizzare nella cache. Una regola specifica una mappatura tra un registro upstream e il repository privato Amazon ECR.

Per un registro upstream che richiede l'autenticazione, fornisci le tue credenziali utilizzando AWS Secrets Manager.

Per ulteriori informazioni, consulta Creazione di una regola di pull through cache nel Guida per l'utente di Amazon Elastic Container Registry.

Creazione di una regola di pull through cache utilizzando la console

Per configurare la cache pull through, segui questi passaggi utilizzando la console Amazon ECR:

Creazione di una regola di pull through cache utilizzando il AWS CLI

Usa Amazon ECR create-pull-through-cache-rule comando per creare una regola di pull through cache. Per i registri upstream che richiedono l'autenticazione, memorizza le credenziali in un segreto di Secrets Manager.

Gli esempi seguenti mostrano come creare una regola per ogni registro upstream supportato.

Amazon ECR Public

L'esempio seguente crea una regola di cache pull-through per il registro pubblico di Amazon ECR. Specifica il prefisso del repository di ecr-public, quindi ogni repository creato dalla regola utilizza lo schema di denominazione ecr-public/upstream-repository-name.

aws ecr create-pull-through-cache-rule \
     --ecr-repository-prefix ecr-public \
     --upstream-registry-url public.ecr.aws \
     --region us-east-1

Kubernetes container image registry

L'esempio seguente crea una regola di cache pull through per il registro pubblico Kubernetes. Specifica il prefisso del repository di kubernetes, quindi ogni repository creato dalla regola utilizza lo schema di denominazione kubernetes/upstream-repository-name.

aws ecr create-pull-through-cache-rule \
     --ecr-repository-prefix kubernetes \
     --upstream-registry-url registry.k8s.io \
     --region us-east-1

Quay

L'esempio seguente crea una regola di cache pull-through per il registro pubblico Quay. Specifica il prefisso del repository di quay, quindi ogni repository creato dalla regola utilizza lo schema di denominazione quay/upstream-repository-name.

aws ecr create-pull-through-cache-rule \
     --ecr-repository-prefix quay \
     --upstream-registry-url quay.io \
     --region us-east-1

Docker Hub

L'esempio seguente crea una regola di cache pull-through per il registro Docker Hub. Specifica il prefisso del repository di docker-hub, quindi ogni repository creato dalla regola utilizza lo schema di denominazione docker-hub/upstream-repository-name. Devi specificare nella sua interezza il nome della risorsa Amazon (ARN) del segreto contenente le credenziali di Docker Hub.

aws ecr create-pull-through-cache-rule \
     --ecr-repository-prefix docker-hub \
     --upstream-registry-url registry-1.docker.io \
     --credential-arn arn:aws:secretsmanager:us-east-1:111122223333:secret:ecr-pullthroughcache/example1234 \
     --region us-east-1

GitHub Container Registry

L'esempio seguente crea una regola di pull through cache per GitHub Registro dei contenitori. Specifica il prefisso del repository di github, quindi ogni repository creato dalla regola utilizza lo schema di denominazione github/upstream-repository-name. Devi specificare l'Amazon Resource Name (ARN) completo del segreto che contiene il tuo GitHub Credenziali del Container Registry.

aws ecr create-pull-through-cache-rule \
     --ecr-repository-prefix github \
     --upstream-registry-url ghcr.io \
     --credential-arn arn:aws:secretsmanager:us-east-1:111122223333:secret:ecr-pullthroughcache/example1234 \
     --region us-east-1

Microsoft Azure Container Registry

L'esempio seguente crea una regola di pull through cache per il Microsoft Azure Container Registry. Specifica un prefisso del repository di azure, quindi ogni repository creato dalla regola utilizza lo schema di denominazione azure/upstream-repository-name. Devi specificare nella sua interezza il nome della risorsa Amazon (ARN) del segreto contenente le credenziali di Microsoft Azure Container Registry.

aws ecr create-pull-through-cache-rule \
     --ecr-repository-prefix azure \
     --upstream-registry-url myregistry.azurecr.io \
     --credential-arn arn:aws:secretsmanager:us-east-1:111122223333:secret:ecr-pullthroughcache/example1234 \
     --region us-east-1

GitLab Container Registry

L'esempio seguente crea una regola di pull through cache per GitLab Registro dei contenitori. Specifica il prefisso del repository di gitlab, quindi ogni repository creato dalla regola utilizza lo schema di denominazione gitlab/upstream-repository-name. Devi specificare l'Amazon Resource Name (ARN) completo del segreto che contiene il tuo GitLab Credenziali del Container Registry.

aws ecr create-pull-through-cache-rule \
     --ecr-repository-prefix gitlab \
     --upstream-registry-url registry.gitlab.com \
     --credential-arn arn:aws:secretsmanager:us-east-1:111122223333:secret:ecr-pullthroughcache/example1234 \
     --region us-east-1

Puoi usare il get-run-task AWS CLI comando per recuperare informazioni sull'immagine del contenitore utilizzata per un'attività specifica:

aws omics get-run-task --id run-id --task-id task-id

L'output include le seguenti informazioni sull'immagine del contenitore:

"imageDetails": {
    "image": "string",
    "imageDigest": "string",
    "sourceImage": "string",
    ...
}

Fase 2: Impostazione delle autorizzazioni per il registro upstream

Usa le autorizzazioni di registro per consentire HealthOmics per utilizzare la cache pull through e inserire le immagini del contenitore nel registro privato Amazon ECR. Aggiungi una policy di Amazon ECR Registry al registro che fornisce i contenitori utilizzati nelle esecuzioni.

La seguente politica concede l'autorizzazione per HealthOmics servizio per creare repository con i prefissi di cache pull through specificati e per avviare i pull upstream in questi repository.

Assicurati Resource copre tutti i prefissi del repository di cache che hai creato e imposta la regione e il Account AWS in ogni repository ARN del registro che stai configurando, poiché una politica di registro si applica solo alla propria regione e al proprio account.

Per allegare la politica al AWS CLI invece, salvala in un file, quindi usa Amazon ECR put-registry-policy comando:

aws ecr put-registry-policy \
     --policy-text file://registry-policy-file.json \
     --region region

Per ulteriori informazioni sulle politiche relative alla cache pull through di Amazon ECR, consulta Le politiche per Amazon ECR estraggono la cache.

Fase 3: creazione di modelli di repository

Per utilizzare il pull through caching in HealthOmics, il repository Amazon ECR deve avere un modello di creazione del repository. Il modello definisce le impostazioni di configurazione per quando tu o Amazon ECR create un repository privato per un registro upstream.

Ogni modello contiene un prefisso dello spazio dei nomi del repository, che Amazon ECR utilizza per abbinare i nuovi repository a un modello specifico. I modelli specificano la configurazione per tutte le impostazioni del repository, comprese le politiche di accesso basate sulle risorse, l'immutabilità dei tag, la crittografia e le politiche del ciclo di vita.

Per ulteriori informazioni, consulta Modelli per la creazione di repository nel Guida per l'utente di Amazon Elastic Container Registry.

Per creare un modello per la creazione di un repository, segui questi passaggi utilizzando la console Amazon ECR:

Per creare il modello con AWS CLI invece, salva la policy del repository della procedura precedente in un file, quindi utilizza Amazon ECR create-repository-creation-template comando con --prefix impostato sul prefisso del repository della cache dalla regola pull through cache. La descrizione è facoltativa:

aws ecr create-repository-creation-template \
     --prefix ecr-repository-prefix \
     --applied-for PULL_THROUGH_CACHE \
     --repository-policy file://repository-policy-file.json \
     --image-tag-mutability MUTABLE \
     --description "description" \
     --region region

Se esiste già un modello per il prefisso, create-repository-creation-template fallisce con TemplateAlreadyExistsException. Aggiorna invece il modello esistente:

aws ecr update-repository-creation-template \
     --prefix ecr-repository-prefix \
     --applied-for PULL_THROUGH_CACHE \
     --repository-policy file://repository-policy-file.json \
     --image-tag-mutability MUTABLE \
     --region region

Amazon ECR è configurato, ma il HealthOmics la configurazione non è terminata. Se la definizione del flusso di lavoro utilizza gli URI delle immagini a monte, continua Fase 4: aggiunta di una mappa del registro del contenitore (se il flusso di lavoro utilizza URI upstream): senza una mappa del registro del contenitore, l'esecuzione ha esito negativo dopo l'avvio. Altrimenti, passare a Fase 5: Verifica della configurazione della cache pull through.

Fase 4: aggiunta di una mappa del registro del contenitore (se il flusso di lavoro utilizza URI upstream)

Gli URI delle immagini nella definizione del flusso di lavoro determinano se è necessaria una mappa del registro dei contenitori:

Il nome di un'immagine scritto senza un host di registro è un nome breve di Docker Hub, che conta come un URI upstream e necessita di una mappa.

Se la tua definizione utilizza entrambi i tipi di URI, aggiungi una mappa per le immagini che utilizzano gli URI upstream.

Rispecchia la tua regola di pull through cache nella mappatura: set upstreamRegistryUrl all'URL di registro originario della regola, ecrRepositoryPrefix al prefisso del relativo archivio di cache e upstreamRepositoryPrefix al prefisso del repository upstream se la regola ne utilizza uno.

Se i tuoi repository di cache si trovano in un altro Account AWS dal flusso di lavoro, imposta ecrAccountId all'account che possiede i repository di cache e aggiungi le politiche tra account descritte in Politiche per l'accesso ad Amazon ECR tra più account. ecrAccountId l'impostazione predefinita è l'account del flusso di lavoro.

La mappa viene fornita quando si crea il flusso di lavoro o la versione del flusso di lavoro. Per il formato della mappa e le regole che determinano le mappature necessarie al flusso di lavoro, consulta Mappature del registro. Per le mappature delle immagini, vedere Mappature delle immagini. Dopo aver aggiunto la mappa, continua con Fase 5: Verifica della configurazione della cache pull through.

Fase 5: Verifica della configurazione della cache pull through

Esegui il aws ecr comandi nell'account che possiede i repository di cache, perché get-registry-policy e describe-repository-creation-templates leggi sempre il registro dell'account chiamante ed esegui aws omics comandi nell'account proprietario del flusso di lavoro. Utilizza la regione in cui esegui i flussi di lavoro per entrambi. I tre controlli della procedura seguente sono indipendenti, quindi eseguili tutti e raccogli tutti i problemi prima di tornare indietro per risolverli. Il controllo della mappa del registro dopo la procedura viene applicato una volta creato il flusso di lavoro o la versione del flusso di lavoro, come descritto in Aggiungere contenitori privati o di terze parti durante la creazione del flusso di lavoro. Il controllo end-to-end successivo richiede anche l'avvio dell'esecuzione.

Se la tua definizione utilizza gli URI originali, conferma la mappa del registro che hai aggiunto Fase 4: aggiunta di una mappa del registro del contenitore (se il flusso di lavoro utilizza URI upstream). Una mappa appartiene al flusso di lavoro o alla versione del flusso di lavoro che l'hai fornita, quindi controlla quella utilizzata dalle tue esecuzioni: la versione che passi come --workflow-version-name a start-run, o il flusso di lavoro se le tue esecuzioni non ne nominano uno. Per una corsa già esistente, workflowVersionName nel get-run l'output nomina la sua versione.

Per un flusso di lavoro:

aws omics get-workflow \
     --id workflow-id \
     --region region

Per una versione del flusso di lavoro:

aws omics get-workflow-version \
     --workflow-id workflow-id \
     --version-name version-name \
     --region region

Controlla il containerRegistryMap valore nell'output. Se non ha una mappa, la risposta omette il campo. Confermalo status è ACTIVE: se è fermo CREATING, attendi e riprova, e se lo è FAILED, il motivo è statusMessage. Non puoi modificare una mappa sul posto, quindi se manca o è errata, crea una nuova versione del flusso di lavoro come descritto in Re-running la configurazione.

Per confermare end-to-end che un'esecuzione ha utilizzato un'immagine memorizzata nella cache, leggi il risultato di un'esecuzione che utilizza la cache. Un'esecuzione che è già terminata funziona, inclusa una che non è riuscita, ma un'esecuzione annullata potrebbe non aver mai risolto le sue immagini; inizia una corsa solo se non ne hai ancora una:

aws omics get-run \
     --id run-id \
     --region region

Il resourceDigests il campo nell'output, quando l'esecuzione ne riporta uno, registra le risorse risolte dall'esecuzione, incluse le immagini del contenitore. Una voce la cui chiave è un URI privato Amazon ECR sotto il prefisso del tuo repository di cache, con un sha256 digest come valore, conferma che l'esecuzione ha risolto l'immagine nella cache. Questo è il controllo più rapido e funziona anche per un'esecuzione fallita per un motivo non correlato.

Se l'esecuzione si interrompe senza successo, failureReason e statusMessage insieme vi dicono se è coinvolta questa configurazione. Controllali prima di esaminare le attività dell'esecuzione, perché un'esecuzione che non riesce su un'immagine potrebbe non creare alcuna attività:

Non tutte le corse riportano resourceDigestse una corsa che non ha ancora risolto le proprie immagini non è in grado di inserirle. Se manca il campo o la voce, o se vuoi confermare l'immagine estratta da una singola attività, elenca le attività dell'esecuzione:

aws omics list-run-tasks \
     --id run-id \
     --region region

Un vuoto items Una lista su una corsa ancora in corso significa che HealthOmics non ha ancora creato le attività, quindi attendi ed elencale nuovamente. Se un'esecuzione è stata interrotta significa che non è mai stata creata alcuna attività: in caso di esecuzione non riuscita, i motivi dell'errore precedente ne spiegano il motivo, mentre un'esecuzione annullata prima dell'inizio non ha nulla da confermare, quindi usa un'esecuzione diversa. Altrimenti, recupera i dettagli dell'immagine per una delle attività, usando un taskId dall'output precedente:

aws omics get-run-task \
     --id run-id \
     --task-id task-id \
     --region region \
     --query imageDetails

Nel imageDetails, sourceImage è l'URI dell'immagine tratto dalla definizione del flusso di lavoro e image è l'URI privato Amazon ECR estratto dall'attività. Un image valore sotto il prefisso del repository della cache, nel modulo URI privato mostrato in Fase 4: aggiunta di una mappa del registro del contenitore (se il flusso di lavoro utilizza URI upstream) e possibilmente con l'aggiunta di un riassunto dell'immagine, conferma che l'operazione ha utilizzato la cache di pull through. imageDetails può essere vuoto, per un'attività che non ha ancora estratto la sua immagine e per alcune attività che sono già state completate. Un'attività senza dettagli di immagine registrati non ne ha nemmeno nel registro del manifesto di esecuzione, quindi seleziona un'altra attività della stessa esecuzione. Se nessuna operazione in un'esecuzione completata li ha registrati, è comunque possibile confermare che l'immagine è memorizzata nella cache, come descritto in Risoluzione di una politica di registro mancante o incompleta. Ciò conferma la configurazione piuttosto che l'immagine estratta da una particolare attività, poiché un'esecuzione precedente potrebbe aver popolato la cache.

Al termine di un'esecuzione, il relativo registro del manifesto di esecuzione ripete queste informazioni sull'immagine, in modo da poter controllare le attività dell'esecuzione contemporaneamente anziché chiamare get-run-task per ognuno di essi. Nel record di ogni attività il campo denominato originalImage corrisponde a sourceImage qui e image è lo stesso valore di cui sopra. Per sapere dove trovare il registro, consulta Monitoraggio HealthOmics con CloudWatch Registrie per il resto del record di un'attività, vedi Ottieni informazioni sulla corsa.

Dopo aver configurato la cache pull through, puoi creare un nuovo flusso di lavoro o una nuova versione del flusso di lavoro per utilizzare i contenitori dei registri configurati. Per ulteriori informazioni, consulta Aggiungere contenitori privati o di terze parti durante la creazione del flusso di lavoro.

Re-running la configurazione

È possibile ripetere questi passaggi, ad esempio per aggiungere un prefisso o correggere una policy. I comandi di creazione hanno esito negativo con un codice di uscita diverso da zero quando la risorsa esiste già, senza modificarla. put-registry-policy non fallisce, ma sostituisce l'intera politica del registro, come descritto in Fase 2: Impostazione delle autorizzazioni per il registro upstream.

Risoluzione dei problemi relativi al pull through cache

I seguenti problemi di configurazione causano l'esito negativo dell'esecuzione quando si utilizzano contenitori provenienti dalla cache pull through. Se la definizione del flusso di lavoro utilizza gli URI delle immagini a monte e un'esecuzione non riesce con INVALID_ECR_IMAGE_URI, inizia con la mappa del registro, come descritto in Fase 4: aggiunta di una mappa del registro del contenitore (se il flusso di lavoro utilizza URI upstream). Per altri motivi di errore di esecuzione, vedere Motivi di errore dell'esecuzione.

Esegui il aws ecr i comandi in questa sezione nello stesso account di Fase 5: Verifica della configurazione della cache pull through, oppure pass --registry-id ecr-account-id. Usa i nomi dei repository esattamente come describe-repositories li restituisce: un nome di cache repository è il prefisso del cache repository seguito dal percorso del repository upstream, che per un nome breve di Docker Hub include library/ segmento descritto in Fase 4: aggiunta di una mappa del registro del contenitore (se il flusso di lavoro utilizza URI upstream).

Risoluzione di una politica di registro mancante o incompleta

Sintomo—L'esecuzione dell'URI dell'immagine non riesce con uno dei seguenti motivi di errore:

Se manca il repository della cache, il comando seguente non restituisce alcun repository per il prefisso:

aws ecr describe-repositories \
     --region region \
     --query "repositories[?starts_with(repositoryName, 'ecr-repository-prefix/')]"

È previsto un risultato vuoto per un prefisso da cui non è stato ancora estratto nulla e non è di per sé un problema di configurazione. Quando un'esecuzione dell'URI dell'immagine ha esito negativo, un repository mancante di solito significa che Amazon ECR non è riuscito a crearlo. Se il repository esiste, conferma se l'immagine lo ha raggiunto:

aws ecr describe-images \
     --repository-name cache-repository-name \
     --image-ids imageTag=tag \
     --region region

Un'immagine restituita indica che il tag è memorizzato nella cache. ImageNotFoundException significa che il repository esiste ma quel tag non è presente e RepositoryNotFoundException significa che il nome del repository è sbagliato o che il prefisso non è ancora stato inserito. Passa --image-ids: in caso contrario, il comando riporta tutti i tag nel repository, quindi la presenza di un altro tag può sembrare un successo per il tag di cui hai bisogno per l'esecuzione.

Causa—La politica del registro non garantisce HealthOmics di cosa ha bisogno: non esiste una politica, nella politica manca un'azione o è Resource l'elenco non include questo prefisso della cache.

Soluzione—Aggiungere o correggere la politica del registro come descritto in Fase 2: Impostazione delle autorizzazioni per il registro upstreame confermalo come descritto in Fase 5: Verifica della configurazione della cache pull through. Se la politica del registro copre già il prefisso del repository della cache, la politica del registro non è il problema. Per ECR_IMAGE_NOT_FOUND, dove il repository esiste ma l'immagine non è mai arrivata, l'importazione a monte non è riuscita: conferma le credenziali della regola con validate-pull-through-cache-rule, come descritto in Fase 5: Verifica della configurazione della cache pull through. Per ECR_PERMISSION_ERROR su un repository esistente, continua a Risoluzione di un modello o di una politica di creazione del repository mancanti. Quindi ricomincia la corsa.

Risoluzione di un modello o di una politica di creazione del repository mancanti

Sintomo—Il repository della cache esiste con l'immagine importata e l'esecuzione non riesce comunque con ECR_PERMISSION_ERROR per l'URI dell'immagine.

Causa—Nessun modello di creazione del repository corrisponde al prefisso del repository della cache, il modello non include PULL_THROUGH_CACHE nel appliedForo il modello non ha una politica di repository. Il repository non ha quindi una politica che consenta HealthOmics estrai da esso.

Soluzione—Crea o aggiorna il modello come descritto in Fase 3: creazione di modelli di repository. Poiché i repository esistono già, applica la policy anche ad essi, come descritto in Aggiornamento dei repository creati prima del modello.

Aggiornamento dei repository creati prima del modello

Sintomo—Hai creato o corretto il modello di creazione del repository, describe-repository-creation-templates lo mostra come corretto e l'esecuzione continua a fallire con un errore di accesso Amazon ECR per la stessa immagine. Conferma la policy mancante su un repository interessato:

aws ecr get-repository-policy \
     --repository-name cache-repository-name \
     --region region

La policyText il valore deve concedere omics.amazonaws.com almeno le azioni concesse dalla politica del repository del modello. Se il repository non ha alcuna politica, il comando ha esito negativo con RepositoryPolicyNotFoundException. Se fallisce con RepositoryNotFoundException, il nome del repository è sbagliato o il repository non esiste ancora.

Causa—Un modello si applica solo quando Amazon ECR crea un repository, quindi i repository creati prima dell'aggiunta del modello non hanno una politica di repository per HealthOmics.

Soluzione—Aggiorna i repository esistenti in uno dei seguenti modi.

Modifica di una regola della cache mentre è attiva un'esecuzione

Sintomo—Dopo aver modificato o ricreato una regola di pull through cache, un'esecuzione che sta già utilizzando il repository interessato può fallire con CANNOT_START_CONTAINER_ERROR o IMAGE_VERIFICATION_FAILUREoppure puoi completare utilizzando un'immagine che non ti aspettavi.

Causa—Il prefisso del cache repository ora si risolve in un altro repository upstream, mentre le esecuzioni stanno già estraendo dai repository creati dalla vecchia regola.

Soluzione—Attendi il termine delle esecuzioni attive prima di modificare la regola, come indicato nella nota Fase 1: Creazione di una regola di pull through cache descrive. Per confermare quale immagine è stata effettivamente utilizzata da un'attività, seleziona imageDetails nel get-run-task output, come descritto in Fase 5: Verifica della configurazione della cache pull through. Se un'esecuzione ha utilizzato un'immagine memorizzata nella cache obsoleta, elimina quell'immagine dal repository della cache in modo che il successivo pull la aggiorni dal registro upstream.