Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # 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](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache.html) 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](containers-non-ptc-registries.md). 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. 1. 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. 1. 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)](#ecr-ptc-registry-map). **Topics** + [Voraussetzungen](#ecr-ptc-prerequisites) + [Pull-Through-Cache konfigurieren](#ecr-pull-through-configure) + [Re-running die Konfiguration](#rerun-ecr-ptc) + [Problembehandlung beim Pull-Through-Cache](#ecr-ptc-troubleshooting) ## 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](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-secret.html) 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. **Topics** + [Schritt 1: Erstellen einer Pull-Through-Cache-Regel](#create-ecr-ptc) + [Schritt 2: Berechtigungen für die Upstream-Registrierung einrichten](#reg-ecr-ptc) + [Schritt 3: Repository-Vorlagen erstellen](#repo-create-templates-ptc) + [Schritt 4: Hinzufügen einer Container-Registry Map (wenn Ihr Workflow Upstream-URIs verwendet)](#ecr-ptc-registry-map) + [Schritt 5: Überprüfen Sie Ihre Pull-Through-Cache-Konfiguration](#verify-ecr-ptc) ### 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](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html) 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](https://console.aws.amazon.com/ecr/). 1. Im Navigationsbereich unter **Privates Register**, erweitern **Funktionen und Einstellungen**, dann wähle **Durchsuche den Cache**. 1. Auf der **Durchsuche den Cache** Seite, wähle **Regel hinzufügen**. 1. 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**. 1. 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**. 1. 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. 1. Wählen Sie **Weiter** aus. 1. Ü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](https://console.aws.amazon.com/ecr/). 1. Im Navigationsbereich unter **Privates Register**, erweitern **Registrierungsberechtigungen**, dann wähle **Aussage generieren**. 1. 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/*" ] } ] } ``` ------ 1. 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](permissions-ecr.md#permissions-ecr-ptc). ### 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](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-creation-templates.html) 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](#ecr-ptc-troubleshoot-template-late). 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](https://console.aws.amazon.com/ecr/). 1. Im Navigationsbereich unter **Privates Register**, erweitern **Funktionen und Einstellungen**, dann wähle **Vorlagen zur Repository-Erstellung**. 1. Wählen Sie **Create template (Vorlage erstellen)** aus. 1. In **Einzelheiten zur Vorlage**, wählen **Cache durchsuchen**. 1. 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. 1. 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": "*" } ] } ``` ------ 1. (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. 1. Wählen Sie **Weiter** aus. 1. Ü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)](#ecr-ptc-registry-map): 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](#verify-ecr-ptc) 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](permissions-ecr.md#permissions-cross-account). `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](#ecr-ptc-prerequisites). 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](containers-workflow-creation.md#ecr-pull-through-registry-mapping). Informationen zu Bildzuordnungen finden Sie unter [Bildzuordnungen](containers-workflow-creation.md#ecr-pull-through-mapping-format). Nachdem Sie die Karte hinzugefügt haben, fahren Sie fort mit [Schritt 5: Überprüfen Sie Ihre Pull-Through-Cache-Konfiguration](#verify-ecr-ptc). ### 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](containers-workflow-creation.md). 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](#create-ecr-ptc). 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](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-working-validating.html) in der *Amazon Elastic Container Registry — Benutzerhandbuch*. 1. 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](#reg-ecr-ptc), 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](#reg-ecr-ptc). 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](#reg-ecr-ptc) und stellen Sie sicher, dass Sie die Richtlinie gespeichert haben. 1. 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](#repo-create-templates-ptc), `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](#repo-create-templates-ptc). 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](#ecr-ptc-troubleshoot-template-late). 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)](#ecr-ptc-registry-map). 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](#rerun-ecr-ptc). 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](#ecr-ptc-troubleshooting). 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](permissions-ecr.md#permissions-resource-policy). + 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)](#ecr-ptc-registry-map). + 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](#ecr-ptc-troubleshoot-rule-change). 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](getinfo-about-runs.md) und [Gründe für Ausführungsfehler](workflows-run-errors.md). 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)](#ecr-ptc-registry-map) 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](#ecr-ptc-troubleshoot-registry-policy). 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](monitoring-cloudwatch-logs.md), und den Rest des Datensatzes einer Aufgabe finden Sie unter [Holen Sie sich Informationen zum Lauf](getinfo-about-runs.md). 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](containers-workflow-creation.md). ## 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](#reg-ecr-ptc). + 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](#ecr-ptc-prerequisites). + 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](#reg-ecr-ptc); 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](#verify-ecr-ptc). + 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](#repo-create-templates-ptc). 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](#ecr-ptc-troubleshoot-template-late). + 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](workflows-version-create.md). 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)](#ecr-ptc-registry-map), 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](workflows-default-version.md). ## 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)](#ecr-ptc-registry-map). Weitere Gründe für Lauffehler finden Sie unter [Gründe für Ausführungsfehler](workflows-run-errors.md). 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](#verify-ecr-ptc), 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)](#ecr-ptc-registry-map). ### 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](#reg-ecr-ptc), und bestätigen Sie sie wie unter beschrieben [Schritt 5: Überprüfen Sie Ihre Pull-Through-Cache-Konfiguration](#verify-ecr-ptc). 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](#verify-ecr-ptc). Für ECR\_PERMISSION\_ERROR fahren Sie in einem vorhandenen Repository fort mit [Behebung einer fehlenden Vorlage zur Repository-Erstellung oder einer Repository-Richtlinie](#ecr-ptc-troubleshoot-template). 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](#repo-create-templates-ptc). Da die Repositorys bereits existieren, wenden Sie die Richtlinie auch auf sie an, wie unter [Aktualisierung der Repositorys, die vor der Vorlage erstellt wurden](#ecr-ptc-troubleshoot-template-late). ### 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](#create-ecr-ptc) 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](#verify-ecr-ptc). 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.