Verwendung von Drittanbieter-Registern, die vom Pull-Through-Cache unterstützt werden

Sie können Amazon ECR-Pull-Through-Cache-Regeln verwenden, um Repositorys in einer unterstützten Upstream-Registry mit Ihren privaten Amazon ECR-Repositorys zu synchronisieren. Weitere Informationen finden Sie unter Synchronisieren Sie eine Upstream-Registrierung in der Amazon Elastic Container Registry — Benutzerhandbuch.

Wenn ein Bild zum ersten Mal abgerufen wird, erstellt der Pull-Through-Cache das Image-Repository in Ihrer privaten Registry und synchronisiert es mit dem Upstream-Image, solange die Image-Tags des Repositorys veränderbar bleiben.

HealthOmics unterstützt den Pull-Through-Cache für die folgenden Upstream-Registries:

• Amazon ECR Public

• Kubernetes-Container-Image-Registrierung

• Quay

• Docker Hub

• Microsoft Azure Container Registry

• GitHub Container-Registrierung

• GitLab Container-Registrierung

Für Registries, die den Cache mit Pull-Through-Cache nicht unterstützen, HealthOmics kopiert die Bilder in Ihre privaten Amazon ECR-Repositorys. Weitere Informationen finden Sie unter Verwendung von Drittanbieter-Registrierungen, die vom Pull-Through-Cache nicht unterstützt werden.

Zu den Vorteilen der Verwendung von Amazon ECR Pull Through Cache gehören:

1. Sie müssen keine Container-Images manuell zu Amazon ECR migrieren oder Updates aus dem Drittanbieter-Repository synchronisieren.

2. Workflows greifen auf die synchronisierten Container-Images in Ihrem privaten Repository zu. Das ist zuverlässiger als das Herunterladen von Inhalten zur Laufzeit aus einem öffentlichen Register.

3. Da Amazon ECR Pull-Through-Caches eine vorhersehbare URI-Struktur verwendet, können Sie die Upstream-Image-URIs in Ihrer Workflow-Definition beibehalten und eine Container-Registry-Map hinzufügen, die sie in Ihren Cache-Repositorys auflöst. Weitere Informationen finden Sie unter Schritt 4: Hinzufügen einer Container-Registry Map (wenn Ihr Workflow Upstream-URIs verwendet).

Voraussetzungen

Wenn eine Upstream-Registrierung eine Authentifizierung erfordert, AWS Secrets Manager Das Geheimnis muss im selben enthalten sein AWS-Konto und Region als Pull-Through-Cache-Regel. Wenn Sie die Regel erstellen, übergeben Sie --credential-arn Der ARN des Secrets genau so, wie Secrets Manager ihn zurückgibt, einschließlich des Suffixes, das Secrets Manager an den Namen anhängt. Der Secrets Manager create-secret und describe-secret Antworten geben es beide zurück. Die Beispiel-ARNs in diesem Thema kürzen den geheimen Namen ab.

Upstream-Registrierung	URL der Registrierung	Secrets Manager-Schlüssel erforderlich
Amazon ECR Public	public.ecr.aws	Nein
Kubernetes-Container-Image-Registrierung	registry.k8s.io	Nein
Quay	quay.io	Nein
Docker Hub	registry-1.docker.io	Ja
Microsoft Azure Container Registry	registry-name.azurecr.io	Ja
GitHub Container-Registrierung	ghcr.io	Ja
GitLab Container-Registrierung	registry.gitlab.com	Ja

Der geheime Name muss beginnen mit ecr-pullthroughcache/. Die anderen Anforderungen finden Sie unter Speichern Ihrer Upstream-Repository-Anmeldeinformationen in einem AWS Secrets Manager Geheimnis in der Amazon Elastic Container Registry — Benutzerhandbuch.

Pull-Through-Cache konfigurieren

Amazon ECR bietet eine Registrierung für Ihre AWS-Konto in jeder Region. Stellen Sie sicher, dass Sie die Amazon ECR-Konfiguration in derselben Region erstellen, in der Sie den Workflow ausführen möchten.

Führen Sie die folgenden Konfigurationsaufgaben der Reihe nach aus. Schritt 4 gilt nur, wenn Ihre Workflow-Definition die Upstream-Image-URIs verwendet.

Aufgaben zur Konfiguration

• Schritt 1: Erstellen einer Pull-Through-Cache-Regel

• Schritt 2: Berechtigungen für die Upstream-Registrierung einrichten

• Schritt 3: Repository-Vorlagen erstellen

• Schritt 4: Hinzufügen einer Container-Registry Map (wenn Ihr Workflow Upstream-URIs verwendet)

• Schritt 5: Überprüfen Sie Ihre Pull-Through-Cache-Konfiguration

Schritt 1: Erstellen einer Pull-Through-Cache-Regel

Erstellen Sie eine Amazon ECR-Pull-Through-Cache-Regel für jede Upstream-Registrierung, die Bilder enthält, die Sie zwischenspeichern möchten. Eine Regel legt eine Zuordnung zwischen einer Upstream-Registrierung und dem privaten Amazon ECR-Repository fest.

Für eine Upstream-Registrierung, die eine Authentifizierung erfordert, geben Sie Ihre Anmeldeinformationen wie folgt an AWS Secrets Manager.

Anmerkung

Ändere keine Pull-Through-Cache-Regel, während ein aktiver Lauf das private Repository verwendet. Der Lauf könnte fehlschlagen oder, was noch wichtiger ist, dazu führen, dass Ihre Pipeline unerwartete Bilder verwendet.

Weitere Informationen finden Sie unter Eine Pull-Through-Cache-Regel erstellen in der Amazon Elastic Container Registry — Benutzerhandbuch.

Erstellen einer Pull-Through-Cache-Regel mithilfe der Konsole

Gehen Sie mithilfe der Amazon ECR-Konsole wie folgt vor, um den Pull-Through-Cache zu konfigurieren:

Teil 1: Auswahl der Upstream-Registrierung

1. Öffnen Sie die Amazon-ECR-Konsole.

2. Im Navigationsbereich unter Privates Register, erweitern Funktionen und Einstellungen, dann wähle Durchsuche den Cache.

3. Auf der Durchsuche den Cache Seite, wähle Regel hinzufügen.

4. In der Upstream-Registrierung Panel, wählen Sie die Upstream-Registrierung aus, die mit Ihrer privaten Registrierung synchronisiert werden soll, und wählen Sie dann Weiter.

5. Wenn für die Upstream-Registrierung eine Authentifizierung erforderlich ist, geben Sie auf der nächsten Seite das Secrets Manager-Geheimnis an, das Ihre Anmeldeinformationen enthält. Wählen Sie Weiter aus.

Teil 2: Namespaces angeben und die Regel erstellen

1. Unter Geben Sie Namespaces an, in der Namespace zwischenspeichern Wählen Sie im Bedienfeld, ob die privaten Repositorys mit einem bestimmten Repository-Präfix oder ohne Präfix erstellt werden sollen. Wenn Sie ein Präfix verwenden möchten, geben Sie den Präfixnamen in Repository-Präfix zwischenspeichern.

2. In der Upstream-Namespace Wählen Sie im Bedienfeld aus, ob Sie mit einem bestimmten Repository-Präfix oder ohne Präfix aus Upstream-Repositorys abrufen möchten. Wenn Sie ein Präfix verwenden möchten, geben Sie den Präfixnamen in Präfix für das Upstream-.

   Das Beispiel für einen Namespace Das Panel zeigt einen Beispiel-Pull-Request, eine Upstream-URL und die URL des Cache-Repositorys, das erstellt wird.

3. Wählen Sie Weiter aus.

4. Überprüfen Sie die Konfiguration und wählen Sie Erstellen um die Regel zu erstellen.

Erstellen einer Pull-Through-Cache-Regel mit der AWS CLI

Verwenden Sie den Amazon ECR create-pull-through-cache-rule Befehl zum Erstellen einer Pull-Through-Cache-Regel. Speichern Sie die Anmeldeinformationen für Upstream-Registrierungen, für die eine Authentifizierung erforderlich ist, in einem Secrets Manager-Schlüssel.

Die folgenden Beispiele zeigen, wie eine Regel für jede unterstützte Upstream-Registrierung erstellt wird.

Amazon ECR Public

Im folgenden Beispiel wird eine Pull-Through-Cache-Regel für die öffentliche Registrierung von Amazon ECR erstellt. Sie gibt ein Repository-Präfix von an ecr-public, sodass jedes Repository, das die Regel erstellt, das Benennungsschema verwendet 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

Im folgenden Beispiel wird eine Pull-Through-Cache-Regel für das öffentliche Kubernetes-Registry erstellt. Es spezifiziert ein Repository-Präfix von kubernetes, sodass jedes Repository, das die Regel erstellt, das Benennungsschema verwendet 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

Im folgenden Beispiel wird eine Pull-Through-Cache-Regel für die öffentliche Registrierung von Quay erstellt. Es spezifiziert ein Repository-Präfix von quay, sodass jedes Repository, das die Regel erstellt, das Benennungsschema verwendet 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

Im folgenden Beispiel wird eine Pull-Through-Cache-Regel für die Docker-Hub-Registrierung von Quay erstellt. Es spezifiziert ein Repository-Präfix von docker-hub, sodass jedes Repository, das die Regel erstellt, das Benennungsschema verwendet docker-hub/upstream-repository-name. Sie müssen den vollständigen Amazon-Ressourcennamen (ARN) des Secrets mit Ihren Anmeldeinformationen für Docker Hub angeben.

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

Das folgende Beispiel erstellt eine Pull-Through-Cache-Regel für GitHub Container-Registrierung. Es gibt ein Repository-Präfix von an github, sodass jedes Repository, das die Regel erstellt, das Benennungsschema verwendet github/upstream-repository-name. Sie müssen den vollständigen Amazon-Ressourcennamen (ARN) des Secrets angeben, das Ihre enthält GitHub Anmeldeinformationen für 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

Im folgenden Beispiel wird eine Pull-Through-Cache-Regel für die Microsoft Azure Container Registry erstellt. Es gibt ein Repository-Präfix von an azure, sodass jedes Repository, das die Regel erstellt, das Benennungsschema verwendet azure/upstream-repository-name. Sie müssen den vollständigen Amazon-Ressourcennamen (ARN) des Secrets mit Ihren Anmeldeinformationen für die Microsoft Azure Container Registry angeben.

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

Das folgende Beispiel erstellt eine Pull-Through-Cache-Regel für GitLab Container-Registrierung. Es gibt ein Repository-Präfix von an gitlab, sodass jedes Repository, das die Regel erstellt, das Benennungsschema verwendet gitlab/upstream-repository-name. Sie müssen den vollständigen Amazon-Ressourcennamen (ARN) des Secrets angeben, das Ihre enthält GitLab Anmeldeinformationen für 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

Sie können die verwenden get-run-task AWS CLI Befehl zum Abrufen von Informationen über das Container-Image, das für eine bestimmte Aufgabe verwendet wurde:

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

Die Ausgabe enthält die folgenden Informationen über das Container-Image:

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

Schritt 2: Berechtigungen für die Upstream-Registrierung einrichten

Verwenden Sie Registrierungsberechtigungen, um Folgendes zuzulassen HealthOmics um den Pull-Through-Cache zu verwenden und die Container-Images in die private Amazon ECR-Registry abzurufen. Fügen Sie der Registrierung eine Amazon ECR-Registrierungsrichtlinie hinzu, die die in den Läufen verwendeten Container bereitstellt.

Die folgende Richtlinie gewährt die Genehmigung für HealthOmics Dienst, um Repositorys mit den angegebenen Pull-Through-Cache-Präfixen zu erstellen und Upstream-Pulls in diese Repositorys zu initiieren.

Stellen Sie sicher Resource deckt jedes Cache-Repository-Präfix ab, das Sie erstellt haben, und legen Sie die Region und die AWS-Konto in jedem Repository-ARN für die Registrierung, die Sie konfigurieren, da eine Registrierungsrichtlinie nur für ihre eigene Region und ihr eigenes Konto gilt.

1. Öffnen Sie die Amazon-ECR-Konsole.

2. Im Navigationsbereich unter Privates Register, erweitern Registrierungsberechtigungen, dann wähle Aussage generieren.

3. Wählen Sie oben rechts JSON aus. Geben Sie eine Richtlinie ein, die der folgenden ähnelt:

   JSON

   {
       "Version":"2012-10-17",
       "Statement": [
           {
               "Sid": "AllowPTCinRegPermissions",
               "Effect": "Allow",
               "Principal": {
                   "Service": "omics.amazonaws.com"
               },
               "Action": [
                   "ecr:CreateRepository",
                   "ecr:BatchImportUpstreamImage"
               ],
               "Resource": [
                   "arn:aws:ecr:us-east-1:123456789012:repository/ecr-public/*",
                   "arn:aws:ecr:us-east-1:123456789012:repository/docker-hub/*"
               ] 
           }
       ]
   }         
   

4. Speichern Sie die Richtlinie.

Um die Richtlinie an das anzuhängen AWS CLI Speichern Sie es stattdessen in einer Datei und verwenden Sie dann den Amazon ECR put-registry-policy Befehl:

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

Wichtig

put-registry-policy ersetzt die gesamte Registrierungsrichtlinie. Wenn Ihre Registrierung bereits über eine Richtlinie verfügt, rufen Sie sie mit get-registry-policy, füge das hinzu HealthOmics Erklärung, und legen Sie die kombinierte Richtlinie zurück.

Weitere Informationen zu den Richtlinien für Amazon ECR Pull Through Cache finden Sie unter Richtlinien für Amazon ECR ziehen den Cache durch.

Schritt 3: Repository-Vorlagen erstellen

Um Pull-Through-Caching zu verwenden in HealthOmics, das Amazon ECR-Repository muss über eine Vorlage zur Repository-Erstellung verfügen. Die Vorlage definiert Konfigurationseinstellungen für den Fall, dass Sie oder Amazon ECR ein privates Repository für eine Upstream-Registrierung erstellen.

Jede Vorlage enthält ein Repository-Namespace-Präfix, das Amazon ECR verwendet, um neue Repositorys einer bestimmten Vorlage zuzuordnen. Vorlagen spezifizieren die Konfiguration für alle Repository-Einstellungen, einschließlich ressourcenbasierter Zugriffsrichtlinien, Tag-Unveränderbarkeit, Verschlüsselung und Lebenszyklusrichtlinien.

Weitere Informationen finden Sie unter Vorlagen zur Repository-Erstellung in der Amazon Elastic Container Registry — Benutzerhandbuch.

Anmerkung

Erstellen Sie die Vorlage vor dem ersten Lauf, der das Präfix verwendet. Ein Präfix ohne eigene Vorlage und ohne ROOT Vorlage, erhält keine Repository-Richtlinie, also HealthOmics kann die zwischengespeicherten Bilder nicht abrufen. Belassen Sie die Tag-Veränderbarkeit bei MUTABLE, sodass Amazon ECR ein zwischengespeichertes Bild aktualisieren kann, wenn sich das Upstream-Tag ändert. Informationen zu Repositorys, die bereits existieren, finden Sie unter Aktualisierung der Repositorys, die vor der Vorlage erstellt wurden.

Gehen Sie mit der Amazon ECR-Konsole wie folgt vor, um eine Vorlage zur Repository-Erstellung zu erstellen:

Teil 1: Definition der Vorlage

1. Öffnen Sie die Amazon-ECR-Konsole.

2. Im Navigationsbereich unter Privates Register, erweitern Funktionen und Einstellungen, dann wähle Vorlagen zur Repository-Erstellung.

3. Wählen Sie Create template (Vorlage erstellen) aus.

4. In Einzelheiten zur Vorlage, wählen Cache durchsuchen.

5. Wählen Sie, ob Sie diese Vorlage auf ein bestimmtes Präfix oder auf alle Repositorys anwenden möchten, die keiner anderen Vorlage entsprechen.

   Wenn du wählst Ein bestimmtes Präfix, geben Sie den Namespace-Präfixwert in Präfix. Sie haben dieses Präfix angegeben, als Sie die Pull-Through-Cache-Regel erstellt haben.

6. Wählen Sie Weiter aus.

Teil 2: Hinzufügen der Konfiguration zur Repository-Erstellung

1. Auf der Konfiguration zur Repository-Erstellung hinzufügen Seite, für Repository-Berechtigungen, verwenden Sie eine der Beispielrichtlinien, oder geben Sie eine ähnliche wie im folgenden Beispiel ein:

   JSON

   {
       "Version":"2012-10-17",
       "Statement": [
           {
               "Sid": "PTCRepoCreationTemplate",
               "Effect": "Allow",
               "Principal": {
                   "Service": "omics.amazonaws.com"
               },
               "Action": [
                   "ecr:BatchGetImage",
                   "ecr:GetDownloadUrlForLayer"
               ],
               "Resource": "*"
           }
       ]
   }         
   

2. (Optional) Fügen Sie Repository-Einstellungen wie Lebenszyklusrichtlinien und Tags hinzu. Amazon ECR wendet diese Regeln auf alle Container-Images an, die für den Pull-Through-Cache erstellt wurden und das angegebene Präfix verwenden.

3. Wählen Sie Weiter aus.

4. Überprüfen Sie die Konfiguration und wählen Sie Erstellen um die Vorlage zu erstellen.

Um die Vorlage zu erstellen mit dem AWS CLI Speichern Sie stattdessen die Repository-Richtlinie aus dem vorherigen Verfahren in einer Datei und verwenden Sie dann den Amazon ECR create-repository-creation-template Befehl mit --prefix auf das Cache-Repository-Präfix aus Ihrer Pull-Through-Cache-Regel setzen. Die Beschreibung ist optional:

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

Wenn bereits eine Vorlage für das Präfix existiert, create-repository-creation-template schlägt fehl mit TemplateAlreadyExistsException. Aktualisieren Sie stattdessen die vorhandene Vorlage an Ort und Stelle:

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

Wichtig

update-repository-creation-template ersetzt jeden Wert, den Sie übergeben, also --applied-for und --repository-policy die bestehende Liste und Richtlinie überschreiben, anstatt sie mit ihnen zusammenzuführen. Rufen Sie die aktuelle Vorlage mit ab describe-repository-creation-templates, führen Sie Ihre Änderungen zusammen und übergeben Sie die vollständigen Werte.

Amazon ECR ist konfiguriert, aber HealthOmics Die Konfiguration ist noch nicht abgeschlossen. Wenn Ihre Workflow-Definition die Upstream-Image-URIs verwendet, fahren Sie mit Schritt 4: Hinzufügen einer Container-Registry Map (wenn Ihr Workflow Upstream-URIs verwendet): Ohne eine Container-Registrierungszuordnung schlägt der Lauf fehl, nachdem er gestartet wurde. Fahren Sie andernfalls mit dem Schritt Schritt 5: Überprüfen Sie Ihre Pull-Through-Cache-Konfiguration fort.

Schritt 4: Hinzufügen einer Container-Registry Map (wenn Ihr Workflow Upstream-URIs verwendet)

Die Image-URIs in Ihrer Workflow-Definition entscheiden, ob Sie eine Container-Registry-Map benötigen:

Image-URIs in Ihrer Workflow-Definition	Übersicht über die Registrierung
Die Upstream-URIs in der Form upstream-registry-url/upstream-repository-name:tag	Fügen Sie eine Karte hinzu. Die Karte verrät HealthOmics welches Cache-Repository-Präfix zu welcher Upstream-Registry gehört, weil HealthOmics liest deine Pull-Through-Cache-Regeln nicht.
Die privaten Amazon ECR-URIs Ihrer Cache-Repositorys in der folgenden Form account-id.dkr.ecr.region.amazonaws.com/ecr-repository-prefix/upstream-repository-name:tag	Sie benötigen keine Karte. HealthOmics verwendet jeden URI wie angegeben.

Ein Image-Name, der ohne einen Registrierungshost geschrieben wird, ist ein Docker-Hub-Kurzname, der als Upstream-URI gilt und eine Map benötigt.

Wenn Ihre Definition beide Arten von URIs verwendet, fügen Sie eine Map für die Bilder hinzu, die die Upstream-URIs verwenden.

Wichtig

Mit den Upstream-URIs StartRun ist auch dann erfolgreich, wenn die Map fehlt oder keine Zuordnung für die Upstream-Registrierung eines Images enthält. HealthOmics validiert jedes Image, wenn es die Aufgabe erstellt, die es verwendet, sodass die Ausführung nach dem Start fehlschlägt. In beiden Fällen wird der Grund für den Fehler angegeben INVALID_ECR_IMAGE_URI, und die Statusmeldung des Laufs unterscheidet sie. Ein Mapping, das ein Bild in ein Cache-Repository auflöst, das nicht existiert, bietet stattdessen ECR_REPOSITORY_NOT_FOUND.

Spiegeln Sie Ihre Pull-Through-Cache-Regel im Mapping: set wider upstreamRegistryUrl zur Upstream-Registrierungs-URL der Regel, ecrRepositoryPrefix zu seinem Cache-Repository-Präfix und upstreamRepositoryPrefix zu seinem Upstream-Repository-Präfix, falls die Regel eines verwendet.

Wenn sich Ihre Cache-Repositorys in einem anderen befinden AWS-Konto aus dem Workflow, setzen ecrAccountId zu dem Konto, dem die Cache-Repositorys gehören, und fügen Sie die kontoübergreifenden Richtlinien hinzu, die unter beschrieben sind Richtlinien für den kontoübergreifenden Amazon ECR-Zugriff. ecrAccountId verwendet standardmäßig das eigene Konto des Workflows.

Anmerkung

Für Docker Hub setzen Sie upstreamRegistryUrl zu registry-1.docker.io, der Wert in Voraussetzungen. HealthOmics Leckereien registry-1.docker.io und docker.io als derselbe Host, sodass ein Mapping auch Bild-URIs abdeckt, die mit geschrieben wurden docker.io.

HealthOmics erweitert auch einen kurzen Docker-Hub-Namen, bevor er mit dem Mapping übereinstimmt: ubuntu:22.04 wird docker.io/library/ubuntu:22.04, und myorg/image:tag wird docker.io/myorg/image:tag. HealthOmics Einsätze library/ nur wenn der Bildname in Ihrer Definition keinen Schrägstrich enthält. Der erweiterte Name bestimmt auch den Cache-Repository-Pfad, also ubuntu:22.04 wird aufgelöst zu ecr-repository-prefix/library/ubuntu:22.04 in Ihrem privaten Register.

Sie stellen die Map bereit, wenn Sie den Workflow oder die Workflow-Version erstellen. Das Kartenformat und die Regeln, nach denen entschieden wird, welche Zuordnungen Ihr Workflow benötigt, finden Sie unter Zuordnungen in der Registrierung. Informationen zu Bildzuordnungen finden Sie unter Bildzuordnungen. Nachdem Sie die Karte hinzugefügt haben, fahren Sie fort mit Schritt 5: Überprüfen Sie Ihre Pull-Through-Cache-Konfiguration.

Schritt 5: Überprüfen Sie Ihre Pull-Through-Cache-Konfiguration

Führen Sie das aus aws ecr Befehle in dem Konto, dem die Cache-Repositorys gehören, weil get-registry-policy und describe-repository-creation-templates lese immer die Registrierung des Anruferkontos und starte den aws omics Befehle in dem Konto, dem der Workflow gehört. Verwenden Sie für beide die Region, in der Sie Ihre Workflows ausführen. Die drei Prüfungen im folgenden Verfahren sind unabhängig. Führen Sie also alle Prüfungen aus und erfassen Sie alle Probleme, bevor Sie sie beheben. Die Überprüfung der Registrierungszuordnung nach dem Verfahren gilt, sobald Sie den Workflow oder die Workflow-Version erstellt haben, wie unter beschrieben Hinzufügen von privaten Containern oder Containern von Drittanbietern während der Workflow-Erstellung. Die anschließende Ende-zu-Ende-Überprüfung erfordert ebenfalls einen gestarteten Lauf.

1. Vergewissern Sie sich, dass die Pull-Through-Cache-Regel existiert und auf die erwartete Upstream-Registrierung verweist:

   aws ecr describe-pull-through-cache-rules \
        --region region

   Jede Regel, die Sie erstellt haben, wird mit ihrer ecrRepositoryPrefix und upstreamRegistryUrl. Eine Regel, die ein Upstream-Repository-Präfix festlegt, wird ebenfalls angezeigt upstreamRepositoryPrefix, und eine Regel, die Anmeldeinformationen verwendet, wird ebenfalls angezeigt credentialArn; Amazon ECR lässt jedes dieser Felder aus, wenn die Regel es nicht festlegt. Ein leeres pullThroughCacheRules Eine Liste bedeutet, dass in dieser Region keine Regel existiert. Kehren Sie zurück zu Schritt 1: Erstellen einer Pull-Through-Cache-Regel.

   Wenn die Regel Anmeldeinformationen verwendet, stellen Sie außerdem sicher, dass Amazon ECR das Geheimnis lesen kann, und melden Sie sich bei der Upstream-Registrierung an:

   aws ecr validate-pull-through-cache-rule \
        --ecr-repository-prefix ecr-repository-prefix \
        --region region

   Die Ausgabe beinhaltet "isValid": true wenn die Authentifizierung erfolgreich ist, und benennt andernfalls den Grund in failure. Wenn der Befehl fehlschlägt mit PullThroughCacheRuleNotFoundException, keine Regel verwendet dieses Präfix. Ein AccessDeniedException bedeutet, dass Ihrem Anrufer das fehlt ecr:ValidatePullThroughCacheRule Erlaubnis, die in Richtlinien zum Lesen nicht immer enthalten ist, nicht dass die Regel falsch ist. Weitere Informationen finden Sie unter Überprüfung der Pull-Through-Cache-Regeln in der Amazon Elastic Container Registry — Benutzerhandbuch.

2. Bestätigen Sie, dass die Registrierungsrichtlinie Folgendes gewährt HealthOmics Zugriff:

   aws ecr get-registry-policy \
        --region region

   Das policyText Wert in der Ausgabe, den Amazon ECR zurückgibt JSON-escaped, muss die Aussage von enthalten Schritt 2: Berechtigungen für die Upstream-Registrierung einrichten, gewährend omics.amazonaws.com beides ecr:CreateRepository und ecr:BatchImportUpstreamImage, einzeln oder durch einen Platzhalter und deckt jedes Cache-Repository-Präfix ab, das Sie erstellt haben. Ein Präfix wird durch ein abgedeckt Resource Eintrag, der mit den darunter liegenden Cache-Repositorys übereinstimmt, z. B. ein Repository-ARN, der mit dem Präfix endet, gefolgt von /*, eine Repository-ARN, die mit endet /* allein oder ein Resource von *. Ein ARN, der am Präfix selbst endet, ohne /*, deckt nichts ab: Ein Cache-Repository-Name hat immer einen Pfad unter dem Präfix. Ein ARN, der eine Region benennt oder AWS-Konto außer der eigenen Registrierung deckt auch nichts ab, wie unter beschrieben Schritt 2: Berechtigungen für die Upstream-Registrierung einrichten. Wenn keine Anweisung ein Präfix abdeckt oder wenn der Befehl fehlschlägt mit RegistryPolicyNotFoundException, zurück zu Schritt 2: Berechtigungen für die Upstream-Registrierung einrichten und stellen Sie sicher, dass Sie die Richtlinie gespeichert haben.

3. Vergewissern Sie sich, dass für jedes Cache-Repository-Präfix eine Vorlage zur Repository-Erstellung existiert. Übergeben Sie alle Präfixe, die Sie erstellt haben:

   aws ecr describe-repository-creation-templates \
        --prefixes ecr-repository-prefix-1 ecr-repository-prefix-2 \
        --region region

   Für jedes Präfix muss die Vorlage, die Amazon ECR auf seine Cache-Repositorys anwendet — wie im nächsten Absatz beschrieben — Folgendes enthalten PULL_THROUGH_CACHE in appliedFor und ein repositoryPolicy das gewährt omics.amazonaws.com die Pull-Aktionen von Schritt 3: Repository-Vorlagen erstellen, ecr:BatchGetImage und ecr:GetDownloadUrlForLayer. Eine Richtlinie, die nicht leer ist, reicht nicht aus: Bestätigen Sie sowohl das Prinzip als auch die Aktionen.

   Amazon ECR wendet die Vorlage an, deren Präfix die längste Übereinstimmung mit dem Repository ist, oder ROOT Vorlage, wenn kein Präfix übereinstimmt. Führen Sie den Befehl ohne --prefixes um alle Vorlagen zu sehen, weil --prefixes passt genau zu jedem Präfix und nicht nach Pfad, also keines ROOT Eine Vorlage oder eine Vorlage mit einem längeren Präfix erscheint in der gefilterten Ausgabe. Kehren Sie für jedes Präfix, dessen entsprechende Vorlage fehlt oder eine der Anforderungen nicht erfüllt, zu diesem Schritt zurück. imageTagMutability hat keinen Einfluss darauf, ob HealthOmics kann das Bild abrufen, aber eine Vorlage, die es auf etwas anderes festlegt MUTABLE stoppt Amazon ECR, ein zwischengespeichertes Bild zu aktualisieren, wenn das Upstream-Tag verschoben wird, wie unter beschrieben Schritt 3: Repository-Vorlagen erstellen.

   Falls bereits Cache-Repositorys existierten, bevor Sie die Vorlage erstellt haben, überprüfen Sie auch die Repository-Richtlinie für jedes dieser Repositorys, wie unter beschrieben Aktualisierung der Repositorys, die vor der Vorlage erstellt wurden.

Wenn Ihre Definition die Upstream-URIs verwendet, bestätigen Sie die Registrierungszuordnung, die Sie hinzugefügt haben Schritt 4: Hinzufügen einer Container-Registry Map (wenn Ihr Workflow Upstream-URIs verwendet). Eine Map gehört zu dem Workflow oder der Workflow-Version, mit der Sie sie geliefert haben, also überprüfen Sie, welche Ihre Läufe verwenden: die Version, als die Sie übergeben --workflow-version-name zu start-run, oder den Workflow, falls deine Läufe keinen benennen. Für einen Lauf, der bereits existiert, workflowVersionName in der get-run Die Ausgabe benennt ihre Version.

Für einen Arbeitsablauf:

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

Für eine Workflow-Version:

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

Prüfen Sie das containerRegistryMap Wert in der Ausgabe. Wenn es keine Map gibt, wird das Feld in der Antwort weggelassen. Bestätigen Sie das status ist ACTIVE: wenn es immer noch ist CREATING, warte und versuche es erneut, und wenn ja FAILED, der Grund ist in statusMessage. Sie können eine Map nicht an Ort und Stelle ändern. Wenn sie fehlt oder falsch ist, erstellen Sie eine neue Workflow-Version, wie unter beschrieben Re-running die Konfiguration.

Lesen Sie das Ergebnis eines Laufs, bei dem der Cache verwendet wird, um zu überprüfen, ob bei einem Lauf ein zwischengespeichertes Bild verwendet wurde. Eine Ausführung, die bereits abgeschlossen ist, funktioniert, auch wenn eine fehlgeschlagene Ausführung ausgeführt wurde, aber bei einem abgebrochenen Lauf wurden die Images möglicherweise nie aufgelöst. Starten Sie einen Lauf nur, wenn Sie noch keinen haben:

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

Der resourceDigests Das Feld in der Ausgabe zeichnet Ressourcen auf, die durch den Lauf aufgelöst wurden, einschließlich der zugehörigen Container-Images, wenn der Lauf einen Wert meldet. Ein Eintrag, dessen Schlüssel eine private Amazon ECR-URI unter Ihrem Cache-Repository-Präfix ist, mit einem sha256 digest als Wert bestätigt, dass der Lauf das Bild in Ihrem Cache aufgelöst hat. Dies ist die schnellste Überprüfung, und sie funktioniert auch bei einem Lauf, der aus einem anderen Grund fehlgeschlagen ist.

Wenn der Lauf erfolglos gestoppt wurde, failureReason und statusMessage zusammen sagen wir Ihnen, ob es sich um diese Konfiguration handelt. Überprüfe diese, bevor du dir die Aufgaben des Laufs ansiehst, denn ein Lauf, der auf einem Image fehlschlägt, erzeugt möglicherweise gar keine Aufgaben:

• ECR_REPOSITORY_NOT_FOUND, ECR_IMAGE_NICHT_GEFUNDEN oder ECR_PERMISSION_ERROR für eine Bild-URI unter einem Ihrer Cache-Repository-Präfixe — fahren Sie fort mit Problembehandlung beim Pull-Through-Cache. Einer dieser Gründe für eine URI, die nicht unter einem Ihrer Präfixe steht, ist eher ein Amazon ECR-Problem mit diesem Repository als ein Pull-Through-Cache-Problem, da keine Cache-Regel für sie gilt. Für ein Repository, das Sie selbst in Amazon ECR verwalten, geben Sie HealthOmics Zugriff mit einer Repository-Richtlinie, wie beschrieben unter Erstellen Sie eine Ressourcenrichtlinie für das Amazon ECR-Repository.

• UNGÜLTIGE_ECR_IMAGE-URI — Die Registry Map fehlt, sie hat keine Zuordnung für die Upstream-Registry des Images, es ist upstreamRepositoryPrefix deckt den Pfad des Bildes nicht ab, oder die Bild-URI ist nicht gültig. Lesen Sie die Statusmeldung, um diese zu unterscheiden, und überprüfen Sie die URI, bevor Sie die Karte ändern. Siehe Schritt 4: Hinzufügen einer Container-Registry Map (wenn Ihr Workflow Upstream-URIs verwendet).

• CONTAINER_ERROR KANN NICHT GESTARTET WERDEN oder IMAGE_VERIFICATION_FAILURE für eine Bild-URI unter einem Ihrer Präfixe — das Bild hat Ihr Cache-Repository erreicht, aber die Aufgabe konnte es nicht verwenden. Wenn Sie die Cache-Regel geändert oder neu erstellt haben, kann dies durch ein veraltetes, zwischengespeichertes Bild verursacht werden; siehe Änderung einer Cache-Regel, während eine Ausführung aktiv ist. Andernfalls ist das zwischengespeicherte Image selbst das Problem und nicht diese Konfiguration, und das Upstream-Image oder die Aufgabe, die es verwendet, ist der Ort, an dem gesucht werden muss.

• Irgendein anderer Fehlergrund oder gar kein Grund, wie ein abgebrochener Lauf meldet — der Lauf wurde aus einem Grund gestoppt, der nichts mit dieser Konfiguration zu tun hat. Informationen zum Ausführungsstatus und zu den anderen Fehlergründen finden Sie unter Holen Sie sich Informationen zum Lauf und Gründe für Ausführungsfehler.

Nicht jeder Lauf meldet sich resourceDigests, und ein Lauf, dessen Bilder noch nicht aufgelöst wurden, hat keinen Eintrag für sie. Wenn das Feld oder der Eintrag fehlt oder wenn Sie überprüfen möchten, welches Image eine einzelne Aufgabe abgerufen hat, listen Sie die Aufgaben des Laufs auf:

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

Ein leeres items Eine Liste bei einem Lauf, der noch läuft, bedeutet HealthOmics hat die Aufgaben noch nicht erstellt, also warte und liste sie erneut auf. Bei einem Lauf, der gestoppt wurde, bedeutet das, dass noch nie eine Aufgabe erstellt wurde: Bei einem fehlgeschlagenen Lauf erklären die vorherigen Fehlergründe, warum, und ein Lauf, der vor dem Start abgebrochen wurde, hat nichts zu bestätigen. Verwenden Sie also einen anderen Lauf. Rufen Sie andernfalls die Image-Details für eine der Aufgaben ab. Verwenden Sie dazu taskId aus der vorherigen Ausgabe:

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

In imageDetails, sourceImage ist die Bild-URI aus Ihrer Workflow-Definition und image ist die private Amazon ECR-URI, die von der Aufgabe abgerufen wurde. Ein image Wert unter Ihrem Cache-Repository-Präfix, in der privaten URI-Form, wie in Schritt 4: Hinzufügen einer Container-Registry Map (wenn Ihr Workflow Upstream-URIs verwendet) und möglicherweise mit einer angehängten Bildübersicht, bestätigt, dass die Aufgabe Ihren Pull-Through-Cache verwendet hat. imageDetails kann leer sein, für eine Aufgabe, die ihr Image noch nicht abgerufen hat, und für einige Aufgaben, die bereits abgeschlossen wurden. Eine Aufgabe, für die keine Bilddetails aufgezeichnet wurden, hat auch keine im Ausführungsmanifestprotokoll. Überprüfen Sie daher eine andere Aufgabe derselben Ausführung. Wenn keine Aufgabe in einem abgeschlossenen Lauf sie aufgezeichnet hat, können Sie trotzdem bestätigen, dass das Image zwischengespeichert wurde, wie unter beschrieben Behebung einer fehlenden oder unvollständigen Registrierungsrichtlinie. Das bestätigt eher die Konfiguration als das Image, das eine bestimmte Aufgabe abgerufen hat, da ein früherer Lauf den Cache möglicherweise gefüllt hat.

Nach Abschluss einer Ausführung wiederholt das Ausführungsmanifestprotokoll diese Image-Informationen, sodass Sie die Aufgaben der Ausführung sofort überprüfen können, anstatt sie aufzurufen get-run-task für jeden. Im Datensatz jeder Aufgabe das benannte Feld originalImage entspricht sourceImage hier, und image ist derselbe Wert wie oben. Wo Sie das Protokoll finden, finden Sie unter Überwachung HealthOmics mit CloudWatch Logs, und den Rest des Datensatzes einer Aufgabe finden Sie unter Holen Sie sich Informationen zum Lauf.

Nachdem Sie den Pull-Through-Cache konfiguriert haben, können Sie einen neuen Workflow oder eine neue Workflow-Version erstellen, um die Container aus konfigurierten Registries zu verwenden. Weitere Informationen finden Sie unter Hinzufügen von privaten Containern oder Containern von Drittanbietern während der Workflow-Erstellung.

Re-running die Konfiguration

Sie können diese Schritte wiederholen, um beispielsweise ein Präfix hinzuzufügen oder eine Richtlinie zu korrigieren. Die Create-Befehle schlagen mit einem Exit-Code ungleich Null fehl, wenn die Ressource bereits existiert, ohne sie zu ändern. put-registry-policy schlägt nicht fehl, aber es ersetzt die gesamte Registrierungsrichtlinie, wie unter beschrieben Schritt 2: Berechtigungen für die Upstream-Registrierung einrichten.

• Cache-Regel durchziehen — create-pull-through-cache-rule schlägt fehl mit PullThroughCacheRuleAlreadyExistsException. Wenn für die Registrierung, die Sie hinzufügen, eine Authentifizierung erforderlich ist, erstellen Sie zuerst das Secrets Manager-Geheimnis, wie unter beschrieben Voraussetzungen.

• Richtlinie für Registrierungsberechtigungen — fügen Sie eine hinzu Resource Eintrag für jedes neue Cache-Repository-Präfix, wie unter beschrieben Schritt 2: Berechtigungen für die Upstream-Registrierung einrichten; eine Richtlinie, die Präfixe einzeln aufzählt, gilt nicht für neue. Bestätigen Sie den Versicherungsschutz mit get-registry-policy, wie beschrieben unter Schritt 5: Überprüfen Sie Ihre Pull-Through-Cache-Konfiguration.

• Vorlage zur Repository-Erstellung — Erstellen Sie eine Vorlage für ein Cache-Repository-Präfix, das keines hat, und aktualisieren Sie die vorhandene Vorlage, um ein Präfix zu ändern, das bereits eines hat. Beides ist unter beschrieben Schritt 3: Repository-Vorlagen erstellen. Wenn Sie ein Update für die Vorlage eines anderen Präfixes ausführen, wird diese Vorlage überschrieben. Um Repositorys, die Amazon ECR bereits erstellt hat, auf den neuesten Stand zu bringen, siehe Aktualisierung der Repositorys, die vor der Vorlage erstellt wurden.

• Container-Registry Map — Sie geben die Map an, wenn Sie einen Workflow oder eine Workflow-Version erstellen, und update-workflow und update-workflow-version kann es nicht ändern. Bevor Sie eine Version erstellen, sollten Sie die komplette Map bereithalten: Eine neue Version erbt nicht die Map der vorherigen Version, also listen Sie alle Mappings auf, die der Workflow noch benötigt, nicht nur die neue. create-workflow-version verwendet die gesamte Version und nicht nur die Map, daher benötigen Sie auch die Workflow-Definition und die anderen Parameter der Version, wie unter beschrieben Eine Workflow-Version erstellen. Erstellen Sie dann die Version mit der aktualisierten Karte, wie unter beschrieben Schritt 4: Hinzufügen einer Container-Registry Map (wenn Ihr Workflow Upstream-URIs verwendet), und starte deine Runs mit dieser Version. Ein Lauf, der keine Version benennt, verwendet die Standardversion des Workflows, die die Map, mit der er erstellt wurde, beibehält, sodass er auf die gleiche Weise fehlschlägt wie zuvor. Weitere Informationen finden Sie unter Standard-Workflow-Version.

Problembehandlung beim Pull-Through-Cache

Die folgenden Konfigurationsprobleme führen dazu, dass ein Lauf fehlschlägt, wenn Sie Container aus dem Pull-Through-Cache verwenden. Wenn Ihre Workflow-Definition die Upstream-Image-URIs verwendet und ein Lauf fehlschlägt mit INVALID_ECR_IMAGE_URI, beginnen Sie mit der Registrierungsübersicht, wie unter beschrieben Schritt 4: Hinzufügen einer Container-Registry Map (wenn Ihr Workflow Upstream-URIs verwendet). Weitere Gründe für Lauffehler finden Sie unter Gründe für Ausführungsfehler.

Führen Sie das aus aws ecr Befehle in diesem Abschnitt im selben Konto wie in Schritt 5: Überprüfen Sie Ihre Pull-Through-Cache-Konfiguration, oder bestehen --registry-id ecr-account-id. Verwenden Sie die Repository-Namen genau wie describe-repositories gibt sie zurück: Ein Cache-Repository-Name ist das Cache-Repository-Präfix, gefolgt vom Upstream-Repository-Pfad, der für einen Docker-Hub-Kurznamen Folgendes beinhaltet library/ Segment, beschrieben in Schritt 4: Hinzufügen einer Container-Registry Map (wenn Ihr Workflow Upstream-URIs verwendet).

Behebung einer fehlenden oder unvollständigen Registrierungsrichtlinie

Symptom— Die Ausführung für den Image-URI schlägt mit einem der folgenden Fehlergründe fehl:

• ECR_REPOSITORY_NOT_FOUND — Das Cache-Repository existiert nicht in Ihrer privaten Registrierung.

• ECR_IMAGE_NOT_FOUND — Das Cache-Repository existiert, aber das Bild wurde nie in es importiert.

• ECR_PERMISSION_ERROR — Amazon ECR verweigert den Zugriff.

Wenn das Cache-Repository fehlt, gibt der folgende Befehl kein Repository für das Präfix zurück:

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

Ein leeres Ergebnis für ein Präfix, aus dem noch nichts abgerufen wurde, wird erwartet und ist kein eigenständiges Konfigurationsproblem. Wenn ein Rechenlauf für den Image-URI fehlgeschlagen ist, bedeutet ein fehlendes Repository in der Regel, dass Amazon ECR es nicht erstellen konnte. Wenn das Repository existiert, überprüfen Sie, ob das Image es erreicht hat:

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

Ein zurückgegebenes Bild bedeutet, dass das Tag zwischengespeichert ist. ImageNotFoundException bedeutet, dass das Repository existiert, aber dieses Tag nicht darin ist, und RepositoryNotFoundException bedeutet, dass der Repository-Name falsch ist oder dass noch nichts das Präfix durchgesetzt hat. Durchgehen --image-ids: Ohne ihn meldet der Befehl jedes Tag im Projektarchiv, sodass das Vorhandensein eines anderen Tags als Erfolg für das Tag, das dein Lauf benötigt, aussehen kann.

Ursache—Die Registrierungsrichtlinie gewährt nicht HealthOmics was sie benötigt: Es gibt keine Richtlinie, der Richtlinie fehlt eine Aktion oder Resource Die Liste deckt dieses Cache-Präfix nicht ab.

Lösung— Fügen Sie die Registrierungsrichtlinie hinzu oder korrigieren Sie sie wie unter beschrieben Schritt 2: Berechtigungen für die Upstream-Registrierung einrichten, und bestätigen Sie sie wie unter beschrieben Schritt 5: Überprüfen Sie Ihre Pull-Through-Cache-Konfiguration. Wenn die Registrierungsrichtlinie das Cache-Repository-Präfix bereits abdeckt, ist die Registrierungsrichtlinie nicht das Problem. Für ECR_IMAGE_NOT_FOUND, wo das Repository existiert, aber das Image nie angekommen ist, ist der Upstream-Import fehlgeschlagen: Bestätigen Sie die Anmeldeinformationen der Regel mit validate-pull-through-cache-rule, wie beschrieben unter Schritt 5: Überprüfen Sie Ihre Pull-Through-Cache-Konfiguration. Für ECR_PERMISSION_ERROR fahren Sie in einem vorhandenen Repository fort mit Behebung einer fehlenden Vorlage zur Repository-Erstellung oder einer Repository-Richtlinie. Dann starte den Lauf erneut.

Behebung einer fehlenden Vorlage zur Repository-Erstellung oder einer Repository-Richtlinie

Symptom— Das Cache-Repository ist mit dem importierten Image vorhanden, und die Ausführung schlägt immer noch fehl ECR_PERMISSION_ERROR für die Bild-URI.

Ursache— Keine Vorlage zur Repository-Erstellung entspricht dem Cache-Repository-Präfix, die Vorlage enthält keine PULL_THROUGH_CACHE in appliedFor, oder die Vorlage hat keine Repository-Richtlinie. Das Repository hat daher keine Richtlinie, die Folgendes ermöglicht HealthOmics ziehe davon ab.

Lösung— Erstellen oder aktualisieren Sie die Vorlage wie unter beschrieben Schritt 3: Repository-Vorlagen erstellen. Da die Repositorys bereits existieren, wenden Sie die Richtlinie auch auf sie an, wie unter Aktualisierung der Repositorys, die vor der Vorlage erstellt wurden.

Aktualisierung der Repositorys, die vor der Vorlage erstellt wurden

Symptom— Sie haben die Vorlage zur Repository-Erstellung erstellt oder korrigiert, describe-repository-creation-templates zeigt sie als korrekt an, und eine Ausführung schlägt immer noch fehl und es wird ein Amazon ECR-Zugriffsfehler für dasselbe Image angezeigt. Bestätigen Sie die fehlende Richtlinie für ein betroffenes Repository:

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

Die policyText Wert muss gewähren omics.amazonaws.com mindestens die Aktionen, die die Repository-Richtlinie der Vorlage gewährt. Wenn das Repository überhaupt keine Richtlinie hat, schlägt der Befehl fehl mit RepositoryPolicyNotFoundException. Wenn es fehlschlägt mit RepositoryNotFoundException, der Repository-Name ist falsch oder das Repository existiert noch nicht.

Ursache— Eine Vorlage gilt nur, wenn Amazon ECR ein Repository erstellt. Repositorys, die vor dem Hinzufügen der Vorlage erstellt wurden, haben daher keine Repository-Richtlinie für HealthOmics.

Lösung— Bringen Sie die vorhandenen Repositorys auf eine der folgenden Arten auf den neuesten Stand.

Warnung

Durch das Löschen eines Repositorys werden auch alle darin zwischengespeicherten Bilder gelöscht, und Sie können es nicht rückgängig machen. Lösche ein Repository nicht, während es von einem Run verwendet wird.

• Lege die Richtlinie direkt für jedes bestehende Repository fest. Speichern Sie die Repository-Richtlinie der Vorlage in einer Datei und führen Sie dann den folgenden Befehl für jedes betroffene Repository aus:

  aws ecr set-repository-policy \
       --repository-name cache-repository-name \
       --policy-text file://repository-policy-file.json \
       --region region

• Löschen Sie jedes betroffene Repository. Der Pull-Through-Cache erstellt es aus der Vorlage neu, wenn eine Aufgabe das Image das nächste Mal abruft. Das zwischengespeicherte Image ist also erst verfügbar, wenn der Abruf abgeschlossen ist.

  aws ecr delete-repository \
       --repository-name cache-repository-name \
       --force \
       --region region

Änderung einer Cache-Regel, während eine Ausführung aktiv ist

Symptom—Nachdem Sie eine Pull-Through-Cache-Regel geändert oder neu erstellt haben, kann ein Lauf, der das betroffene Repository bereits verwendet, fehlschlagen mit CANNOT_START_CONTAINER_ERROR oder IMAGE_VERIFICATION_FAILURE, oder kann mit einem Bild abgeschlossen werden, das Sie nicht erwartet haben.

Ursache— Das Cache-Repository-Präfix wird jetzt in ein anderes Upstream-Repository aufgelöst, während Läufe bereits aus den Repositorys abgerufen werden, die mit der alten Regel erstellt wurden.

Lösung—Warten Sie, bis die aktiven Durchläufe abgeschlossen sind, bevor Sie die Regel ändern, wie der Hinweis in Schritt 1: Erstellen einer Pull-Through-Cache-Regel beschreibt. Um zu überprüfen, welches Image eine Aufgabe tatsächlich verwendet hat, überprüfen Sie imageDetails in der get-run-task Ausgabe, wie beschrieben unter Schritt 5: Überprüfen Sie Ihre Pull-Through-Cache-Konfiguration. Wenn bei einem Lauf ein veraltetes zwischengespeichertes Image verwendet wurde, löschen Sie dieses Image aus dem Cache-Repository, sodass es beim nächsten Abruf aus der Upstream-Registrierung aktualisiert wird.