Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Utilisation de registres tiers pris en charge par le cache d'extraction Vous pouvez utiliser les règles de cache d'extraction d'Amazon ECR pour synchroniser les référentiels d'un registre en amont pris en charge avec vos référentiels privés Amazon ECR. Pour plus d'informations, voir [Synchroniser un registre en amont](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache.html) dans le *Guide de l'utilisateur d'Amazon Elastic Container Registry*. La première fois qu'une image est extraite, l'extraction dans le cache crée le référentiel d'images dans votre registre privé et le synchronise avec l'image en amont, tant que les balises d'image du référentiel restent modifiables. HealthOmics prend en charge le cache d'extraction pour les registres en amont suivants : + Amazon ECR Public + Registre d'images de conteneurs Kubernetes + Quay + Docker Hub + Microsoft Azure Container Registry + GitHub Registre des conteneurs + GitLab Registre des conteneurs Pour les registres dont l'extraction par le cache n'est pas prise en charge, HealthOmics copie les images dans vos référentiels privés Amazon ECR. Pour plus d’informations, consultez [Utilisation de registres tiers non pris en charge par le cache d'extraction](containers-non-ptc-registries.md). Les avantages de l'utilisation du cache Pull Through d'Amazon ECR incluent : 1. Vous n'avez pas à migrer manuellement les images de conteneurs vers Amazon ECR ou à synchroniser les mises à jour depuis le référentiel tiers. 1. Les flux de travail accèdent aux images de conteneurs synchronisées dans votre référentiel privé, ce qui est plus fiable que le téléchargement de contenu au moment de l'exécution à partir d'un registre public. 1. Comme les caches d'extraction Amazon ECR utilisent une structure d'URI prévisible, vous pouvez conserver les URI des images en amont dans la définition de votre flux de travail et ajouter une carte de registre de conteneurs qui les résout dans vos référentiels de cache. Pour plus d’informations, consultez [Étape 4 : Ajout d'une carte de registre de conteneurs (si votre flux de travail utilise des URI en amont)](#ecr-ptc-registry-map). **Topics** + [Conditions préalables](#ecr-ptc-prerequisites) + [Configuration du cache Pull Through](#ecr-pull-through-configure) + [Re-running la configuration](#rerun-ecr-ptc) + [Résolution des problèmes liés à l'extraction du cache](#ecr-ptc-troubleshooting) ## Conditions préalables Si un registre en amont nécessite une authentification, AWS Secrets Manager le secret doit être dans le même Compte AWS et Region comme règle d'extraction du cache. Lorsque vous créez la règle, passez `--credential-arn` l'ARN du secret exactement tel que Secrets Manager le renvoie, y compris le suffixe que Secrets Manager ajoute au nom. Le gestionnaire des secrets **create-secret** et **describe-secret** les réponses le renvoient toutes les deux. Les exemples d'ARN de cette rubrique abrégent le nom secret. | Registre en amont | URL du registre | Secret du gestionnaire de secrets requis | | --- | --- | --- | | Amazon ECR Public | `public.ecr.aws` | Non | | Registre d'images de conteneurs Kubernetes | `registry.k8s.io` | Non | | Quay | `quay.io` | Non | | Docker Hub | `registry-1.docker.io` | Oui | | Microsoft Azure Container Registry | `{{registry-name}}.azurecr.io` | Oui | | GitHub Registre des conteneurs | `ghcr.io` | Oui | | GitLab Registre des conteneurs | `registry.gitlab.com` | Oui | Le nom secret doit commencer par `ecr-pullthroughcache/`. Pour les autres exigences, voir [Stockage des informations d'identification de votre référentiel en amont dans un AWS Secrets Manager secret](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-secret.html) dans le *Guide de l'utilisateur d'Amazon Elastic Container Registry*. ## Configuration du cache Pull Through Amazon ECR fournit un registre pour vos Compte AWS dans chaque région. Assurez-vous de créer la configuration Amazon ECR dans la même région que celle où vous prévoyez d'exécuter le flux de travail. Effectuez les tâches de configuration suivantes dans l'ordre. L'étape 4 s'applique uniquement si la définition de votre flux de travail utilise les URI des images en amont. **Topics** + [Étape 1 : Création d'une règle de cache d'extraction](#create-ecr-ptc) + [Étape 2 : Configuration des autorisations pour le registre en amont](#reg-ecr-ptc) + [Étape 3 : Création de modèles de référentiel](#repo-create-templates-ptc) + [Étape 4 : Ajout d'une carte de registre de conteneurs (si votre flux de travail utilise des URI en amont)](#ecr-ptc-registry-map) + [Étape 5 : Vérification de la configuration de votre cache d'extraction](#verify-ecr-ptc) ### Étape 1 : Création d'une règle de cache d'extraction Créez une règle de cache d'extraction Amazon ECR pour chaque registre en amont contenant des images que vous souhaitez mettre en cache. Une règle spécifie un mappage entre un registre en amont et le référentiel privé Amazon ECR. Pour un registre en amont qui nécessite une authentification, vous devez fournir vos informations d'identification en utilisant AWS Secrets Manager. **Note** Ne modifiez pas une règle de cache d'extraction lorsqu'une exécution active utilise le référentiel privé. L'exécution peut échouer ou, plus grave encore, entraîner l'utilisation d'images inattendues dans votre pipeline. Pour plus d'informations, voir [Création d'une règle de cache d'extraction](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-creating-rule.html) dans le *Guide de l'utilisateur d'Amazon Elastic Container Registry*. #### Création d'une règle de cache d'extraction à l'aide de la console Pour configurer le cache d'extraction, procédez comme suit à l'aide de la console Amazon ECR : **Partie 1 : Choix du registre en amont** 1. Ouvrez la [console Amazon ECR](https://console.aws.amazon.com/ecr/). 1. Dans le volet de navigation, sous **Registre privé**, développer **Caractéristiques et paramètres**, puis choisissez **Extraire le cache**. 1. Sur le **Extraire le cache** page, choisissez **Ajouter une règle**. 1. Dans le **Registre en amont** panneau, choisissez le registre en amont à synchroniser avec votre registre privé, puis choisissez **Suivant**. 1. Si le registre en amont nécessite une authentification, sur la page suivante, spécifiez le secret Secrets Manager qui contient vos informations d'identification. Choisissez **Suivant**. **Partie 2 : Spécification des espaces de noms et création de la règle** 1. En dessous **Spécifier les espaces de noms**, dans le **Espace de noms du cache** panneau, choisissez si vous souhaitez créer les référentiels privés en utilisant un préfixe de référentiel spécifique ou sans préfixe. Si vous choisissez d'utiliser un préfixe, spécifiez le nom du préfixe dans **Préfixe du référentiel de cache**. 1. Dans le **Espace de noms en amont** panneau, choisissez si vous souhaitez extraire des référentiels en amont en utilisant un préfixe de référentiel spécifique ou sans préfixe. Si vous choisissez d'utiliser un préfixe, spécifiez le nom du préfixe dans **Préfixe du référentiel en amont**. Le **Exemple d'espace de noms** le panneau affiche un exemple de demande d'extraction, une URL en amont et l'URL du référentiel de cache créé. 1. Choisissez **Suivant**. 1. Vérifiez la configuration et choisissez **Créez** pour créer la règle. #### Création d'une règle de cache d'extraction à l'aide du AWS CLI Utilisez Amazon ECR **create-pull-through-cache-rule** commande pour créer une règle de cache d'extraction. Pour les registres en amont qui nécessitent une authentification, stockez les informations d'identification dans un secret Secrets Manager. Les exemples suivants montrent comment créer une règle pour chaque registre en amont pris en charge. ------ #### [ Amazon ECR Public ] L'exemple suivant crée une règle de mise en cache par extraction pour le registre public Amazon ECR. Il spécifie un préfixe de référentiel de `ecr-public`, de sorte que chaque référentiel créé par la règle utilise le schéma de dénomination `ecr-public/{{upstream-repository-name}}`. ``` aws ecr create-pull-through-cache-rule \ --ecr-repository-prefix {{ecr-public}} \ --upstream-registry-url public.ecr.aws \ --region {{us-east-1}} ``` ------ #### [ Kubernetes container image registry ] L'exemple suivant crée une règle de mise en cache par extraction pour le registre public Kubernetes. Il spécifie un préfixe de référentiel de `kubernetes`, de sorte que chaque référentiel créé par la règle utilise le schéma de dénomination `kubernetes/{{upstream-repository-name}}`. ``` aws ecr create-pull-through-cache-rule \ --ecr-repository-prefix {{kubernetes}} \ --upstream-registry-url registry.k8s.io \ --region {{us-east-1}} ``` ------ #### [ Quay ] L'exemple suivant crée une règle de mise en cache par extraction pour le registre public Quay. Il spécifie un préfixe de référentiel de `quay`, de sorte que chaque référentiel créé par la règle utilise le schéma de dénomination `quay/{{upstream-repository-name}}`. ``` aws ecr create-pull-through-cache-rule \ --ecr-repository-prefix {{quay}} \ --upstream-registry-url quay.io \ --region {{us-east-1}} ``` ------ #### [ Docker Hub ] L'exemple suivant crée une règle de mise en cache par extraction pour le registre Docker Hub. Il spécifie un préfixe de référentiel de `docker-hub`, de sorte que chaque référentiel créé par la règle utilise le schéma de dénomination `docker-hub/{{upstream-repository-name}}`. Vous devez spécifier l'Amazon Resource Name (ARN) complet du secret contenant vos informations d'identification Docker Hub. ``` aws ecr create-pull-through-cache-rule \ --ecr-repository-prefix {{docker-hub}} \ --upstream-registry-url registry-1.docker.io \ --credential-arn arn:aws:secretsmanager:{{us-east-1}}:{{111122223333}}:secret:{{ecr-pullthroughcache/example1234}} \ --region {{us-east-1}} ``` ------ #### [ GitHub Container Registry ] L'exemple suivant crée une règle de cache d'extraction pour GitHub Registre des conteneurs. Il spécifie un préfixe de référentiel de `github`, de sorte que chaque référentiel créé par la règle utilise le schéma de dénomination `github/{{upstream-repository-name}}`. Vous devez spécifier le nom de ressource Amazon (ARN) complet du secret contenant votre GitHub Informations d'identification du registre des conteneurs. ``` aws ecr create-pull-through-cache-rule \ --ecr-repository-prefix {{github}} \ --upstream-registry-url ghcr.io \ --credential-arn arn:aws:secretsmanager:{{us-east-1}}:{{111122223333}}:secret:{{ecr-pullthroughcache/example1234}} \ --region {{us-east-1}} ``` ------ #### [ Microsoft Azure Container Registry ] L'exemple suivant crée une règle de cache d'extraction pour le Microsoft Azure Container Registry. Il spécifie un préfixe de référentiel de `azure`, de sorte que chaque référentiel créé par la règle utilise le schéma de dénomination `azure/{{upstream-repository-name}}`. Vous devez spécifier l'Amazon Resource Name (ARN) complet du secret contenant vos informations d'identification Azure Container Registry. ``` aws ecr create-pull-through-cache-rule \ --ecr-repository-prefix {{azure}} \ --upstream-registry-url {{myregistry}}.azurecr.io \ --credential-arn arn:aws:secretsmanager:{{us-east-1}}:{{111122223333}}:secret:{{ecr-pullthroughcache/example1234}} \ --region {{us-east-1}} ``` ------ #### [ GitLab Container Registry ] L'exemple suivant crée une règle de cache d'extraction pour GitLab Registre des conteneurs. Il spécifie un préfixe de référentiel de `gitlab`, de sorte que chaque référentiel créé par la règle utilise le schéma de dénomination `gitlab/{{upstream-repository-name}}`. Vous devez spécifier le nom de ressource Amazon (ARN) complet du secret contenant votre GitLab Informations d'identification du registre des conteneurs. ``` 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}} ``` ------ Vous pouvez utiliser le **get-run-task** AWS CLI commande pour récupérer des informations sur l'image du conteneur utilisée pour une tâche spécifique : ``` aws omics get-run-task --id {{run-id}} --task-id {{task-id}} ``` La sortie inclut les informations suivantes concernant l'image du conteneur : ``` "imageDetails": { "image": "string", "imageDigest": "string", "sourceImage": "string", ... } ``` ### Étape 2 : Configuration des autorisations pour le registre en amont Utiliser les autorisations du registre pour autoriser HealthOmics pour utiliser le cache d'extraction et extraire les images du conteneur dans le registre privé Amazon ECR. Ajoutez une politique de registre Amazon ECR au registre qui fournit les conteneurs utilisés lors des exécutions. La politique suivante accorde l'autorisation pour HealthOmics service permettant de créer des référentiels avec les préfixes de cache d'extraction spécifiés et d'initier des extractions en amont vers ces référentiels. Assurez-vous `Resource` couvre chaque préfixe de référentiel de cache que vous avez créé et définit la région et le Compte AWS dans chaque référentiel, l'ARN du registre que vous configurez, car une politique de registre s'applique uniquement à sa propre région et à son propre compte. 1. Ouvrez la [console Amazon ECR](https://console.aws.amazon.com/ecr/). 1. Dans le volet de navigation, sous **Registre privé**, développer **Autorisations de registre**, puis choisissez **Générer une déclaration**. 1. En haut à droite, choisissez JSON. Entrez une politique similaire à la suivante : ------ #### [ 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. Enregistrez la politique. Pour joindre la politique à AWS CLI enregistrez-le plutôt dans un fichier, puis utilisez Amazon ECR **put-registry-policy** commande : ``` aws ecr put-registry-policy \ --policy-text file://{{registry-policy-file}}.json \ --region {{region}} ``` **Important** **put-registry-policy** remplace l'intégralité de la politique de registre. Si votre registre possède déjà une politique, récupérez-la avec **get-registry-policy**, ajoutez le HealthOmics déclaration, et remettez la politique combinée en place. Pour plus d'informations sur les politiques relatives au cache d'extraction d'Amazon ECR, consultez [Politiques relatives au cache d'extraction d'Amazon ECR](permissions-ecr.md#permissions-ecr-ptc). ### Étape 3 : Création de modèles de référentiel Pour utiliser la mise en cache par extraction dans HealthOmics, le référentiel Amazon ECR doit disposer d'un modèle de création de référentiel. Le modèle définit les paramètres de configuration lorsque vous ou Amazon ECR créez un référentiel privé pour un registre en amont. Chaque modèle contient un préfixe d'espace de noms de référentiel, qu'Amazon ECR utilise pour associer les nouveaux référentiels à un modèle spécifique. Les modèles spécifient la configuration de tous les paramètres du référentiel, y compris les politiques d'accès basées sur les ressources, l'immuabilité des balises, le cryptage et les politiques de cycle de vie. Pour plus d'informations, voir [Modèles de création de référentiels](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-creation-templates.html) dans le *Guide de l'utilisateur d'Amazon Elastic Container Registry*. **Note** Créez le modèle qui utilise le préfixe avant la première exécution. Un préfixe sans modèle propre et sans `ROOT` modèle, n'obtient aucune politique de référentiel, donc HealthOmics ne peut pas extraire ses images mises en cache. Laisser le tag mutability à `MUTABLE`, afin qu'Amazon ECR puisse actualiser une image mise en cache lorsque la balise en amont change. Pour les référentiels qui existent déjà, voir [Mise à jour des référentiels créés avant le modèle](#ecr-ptc-troubleshoot-template-late). Pour créer un modèle de création de référentiel, procédez comme suit à l'aide de la console Amazon ECR : **Partie 1 : Définition du modèle** 1. Ouvrez la [console Amazon ECR](https://console.aws.amazon.com/ecr/). 1. Dans le volet de navigation, sous **Registre privé**, développer **Caractéristiques et paramètres**, puis choisissez **Modèles de création de référentiels**. 1. Sélectionnez **Create template (Créer un modèle)**. 1. Dans **Détails du modèle**, choisissez **Extraire le cache**. 1. Choisissez d'appliquer ce modèle à un préfixe spécifique ou à tous les référentiels qui ne correspondent pas à un autre modèle. Si tu choisis **Un préfixe spécifique**, entrez la valeur du préfixe de l'espace de noms dans **Préfixe**. Vous avez spécifié ce préfixe lorsque vous avez créé la règle de cache d'extraction. 1. Choisissez **Suivant**. **Partie 2 : Ajout de la configuration de création du référentiel** 1. Sur le **Ajouter une configuration de création de référentiel** page, pour **Autorisations du référentiel**, utilisez l'un des exemples de déclaration de politique ou saisissez-en une similaire à l'exemple suivant : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "PTCRepoCreationTemplate", "Effect": "Allow", "Principal": { "Service": "omics.amazonaws.com" }, "Action": [ "ecr:BatchGetImage", "ecr:GetDownloadUrlForLayer" ], "Resource": "*" } ] } ``` ------ 1. (Facultatif) Ajoutez des paramètres de référentiel tels que la politique de cycle de vie et les balises. Amazon ECR applique ces règles à toutes les images de conteneur créées pour extraire le cache et qui utilisent le préfixe spécifié. 1. Choisissez **Suivant**. 1. Vérifiez la configuration et choisissez **Créez** pour créer le modèle. Pour créer le modèle avec AWS CLI enregistrez plutôt la politique de référentiel de la procédure précédente dans un fichier, puis utilisez Amazon ECR **create-repository-creation-template** commande avec `--prefix` définissez le préfixe du référentiel de cache à partir de votre règle de cache d'extraction. La description est facultative : ``` 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}} ``` Si un modèle existe déjà pour le préfixe, **create-repository-creation-template** échoue avec TemplateAlreadyExistsException. Mettez plutôt à jour le modèle existant en place : ``` 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}} ``` **Important** **update-repository-creation-template** remplace chaque valeur que vous passez, donc `--applied-for` et `--repository-policy` remplacer la liste et la politique existantes plutôt que de les fusionner avec elles. Récupérez le modèle actuel avec **describe-repository-creation-templates**, fusionnez vos modifications et transmettez les valeurs complètes. Amazon ECR est configuré, mais HealthOmics la configuration n'est pas terminée. Si la définition de votre flux de travail utilise les URI des images en amont, passez à [Étape 4 : Ajout d'une carte de registre de conteneurs (si votre flux de travail utilise des URI en amont)](#ecr-ptc-registry-map): sans carte de registre de conteneurs, l'exécution échoue après son démarrage. Dans le cas contraire, passez à [Étape 5 : Vérification de la configuration de votre cache d'extraction](#verify-ecr-ptc). ### Étape 4 : Ajout d'une carte de registre de conteneurs (si votre flux de travail utilise des URI en amont) Les URI d'image figurant dans la définition de votre flux de travail déterminent si vous avez besoin d'une carte de registre de conteneurs : | URI d'image dans la définition de votre flux de travail | Plan du registre | | --- | --- | | Les URI en amont, sous la forme `{{upstream-registry-url}}/{{upstream-repository-name}}:{{tag}}` | Ajoutez une carte. La carte indique HealthOmics quel préfixe de référentiel de cache appartient à quel registre en amont, car HealthOmics ne lit pas vos règles d'extraction du cache. | | Les URI privés Amazon ECR de vos dépôts de cache, sous la forme `{{account-id}}.dkr.ecr.{{region}}.amazonaws.com/{{ecr-repository-prefix}}/{{upstream-repository-name}}:{{tag}}` | Vous n'avez pas besoin de carte. HealthOmics utilise chaque URI tel qu'il est indiqué. | Un nom d'image écrit sans hôte de registre est un nom abrégé de Docker Hub, qui compte comme un URI en amont et nécessite une carte. Si votre définition utilise les deux types d'URI, ajoutez une carte pour les images qui utilisent les URI en amont. **Important** Avec les URI en amont, `StartRun` réussit même si la carte est manquante ou si aucun mappage n'est disponible pour le registre en amont d'une image. HealthOmics valide chaque image lorsqu'elle crée la tâche qui l'utilise, de sorte que l'exécution échoue après son démarrage. Les deux cas donnent la raison de l'échec UR\_ECR\_IMAGE\_URI NON VALIDE, et le message d'état de l'exécution les distingue. Un mappage qui résout une image vers un dépôt de cache qui n'existe pas donne à la place REPOSITORY\_ECR\_NOT\_FOUND. Reproduisez votre règle d'extraction du cache dans le mappage : définissez `upstreamRegistryUrl` vers l'URL de registre en amont de la règle, `ecrRepositoryPrefix` au préfixe de son référentiel de cache, et `upstreamRepositoryPrefix` au préfixe de son référentiel en amont si la règle en utilise un. Si vos dépôts de cache se trouvent dans un autre Compte AWS à partir du flux de travail, définissez `ecrAccountId` au compte propriétaire des référentiels de cache, et ajoutez les politiques intercomptes décrites dans [Politiques relatives à l'accès à Amazon ECR entre comptes](permissions-ecr.md#permissions-cross-account). `ecrAccountId` est défini par défaut sur le propre compte du flux de travail. **Note** Pour Docker Hub, définissez `upstreamRegistryUrl` pour `registry-1.docker.io`, la valeur en [Conditions préalables](#ecr-ptc-prerequisites). HealthOmics friandises `registry-1.docker.io` et `docker.io` en tant que même hôte, de sorte qu'un mappage couvre également les URI d'image écrits avec `docker.io`. HealthOmics développe également un nom court de Docker Hub avant qu'il ne corresponde au mappage : `ubuntu:22.04` devient `docker.io/library/ubuntu:22.04`, et `myorg/image:tag` devient `docker.io/myorg/image:tag`. HealthOmics inserts `library/` uniquement lorsque le nom de l'image dans votre définition ne comporte pas de barre oblique. Le nom étendu détermine également le chemin du référentiel de cache, donc `ubuntu:22.04` décide de `{{ecr-repository-prefix}}/library/ubuntu:22.04` dans votre registre privé. Vous fournissez la carte lorsque vous créez le flux de travail ou sa version. Pour le format de carte et les règles qui déterminent les mappages dont votre flux de travail a besoin, voir [Mappages de registres](containers-workflow-creation.md#ecr-pull-through-registry-mapping). Pour les mappages d'images, voir [Mappages d'images](containers-workflow-creation.md#ecr-pull-through-mapping-format). Après avoir ajouté la carte, passez à [Étape 5 : Vérification de la configuration de votre cache d'extraction](#verify-ecr-ptc). ### Étape 5 : Vérification de la configuration de votre cache d'extraction Exécutez le **aws ecr** commandes dans le compte qui possède les référentiels de cache, car **get-registry-policy** et **describe-repository-creation-templates** lisez toujours le registre du compte appelant et exécutez le **aws omics** commandes du compte propriétaire du flux de travail. Utilisez la région dans laquelle vous exécutez vos flux de travail pour les deux. Les trois vérifications de la procédure suivante sont indépendantes, alors exécutez-les toutes et collectez tous les problèmes avant de les résoudre. La vérification de la carte de registre après la procédure s'applique une fois que vous avez créé le flux de travail ou la version du flux de travail, comme décrit dans [Ajout de conteneurs privés ou tiers lors de la création du flux de travail](containers-workflow-creation.md). La vérification de bout en bout qui suit nécessite également un démarrage de l'exécution. 1. Vérifiez que la règle de cache d'extraction existe et pointe vers le registre en amont attendu : ``` aws ecr describe-pull-through-cache-rules \ --region {{region}} ``` Chaque règle que vous avez créée apparaît avec son `ecrRepositoryPrefix` et `upstreamRegistryUrl`. Une règle qui définit un préfixe de référentiel en amont indique également `upstreamRepositoryPrefix`, et une règle qui utilise un identifiant indique également `credentialArn`; Amazon ECR omet chacun de ces champs lorsque la règle ne le définit pas. Un vide `pullThroughCacheRules` liste signifie qu'aucune règle n'existe dans cette région. Retourner à [Étape 1 : Création d'une règle de cache d'extraction](#create-ecr-ptc). Si la règle utilise un identifiant, vérifiez également qu'Amazon ECR peut lire le secret et se connecter au registre en amont : ``` aws ecr validate-pull-through-cache-rule \ --ecr-repository-prefix {{ecr-repository-prefix}} \ --region {{region}} ``` La sortie inclut `"isValid": true` lorsque l'authentification est réussie, et indique la raison dans `failure`. Si la commande échoue avec PullThroughCacheRuleNotFoundException, aucune règle n'utilise ce préfixe. Un AccessDeniedException signifie que votre appelant n'a pas `ecr:ValidatePullThroughCacheRule` autorisation, que les politiques en lecture seule n'incluent pas toujours, ce n'est pas que la règle soit erronée. Pour plus d'informations, voir [Validation des règles d'extraction du cache](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-working-validating.html) dans le *Guide de l'utilisateur d'Amazon Elastic Container Registry*. 1. Vérifiez que la politique de registre accorde HealthOmics accès : ``` aws ecr get-registry-policy \ --region {{region}} ``` Le `policyText` valeur dans la sortie, renvoyée par Amazon ECR JSON-escaped, doit contenir la déclaration de [Étape 2 : Configuration des autorisations pour le registre en amont](#reg-ecr-ptc), accordant `omics.amazonaws.com` tous les deux `ecr:CreateRepository` et `ecr:BatchImportUpstreamImage`, individuellement ou par le biais d'un caractère générique, et couvrant chaque préfixe de référentiel de cache que vous avez créé. Un préfixe est couvert par un `Resource` entrée qui correspond aux dépôts de cache situés en dessous, comme un ARN de référentiel se terminant par le préfixe suivi de `/*`, un ARN de référentiel se terminant par `/*` seul, ou `Resource` de `*`. Un ARN qui se termine par le préfixe lui-même, sans `/*`, ne couvre rien : le nom d'un dépôt de cache comporte toujours un chemin sous le préfixe. Un ARN qui nomme une région ou Compte AWS autre que celui de ce registre ne couvre rien non plus, comme décrit dans [Étape 2 : Configuration des autorisations pour le registre en amont](#reg-ecr-ptc). Si aucune instruction ne couvre un préfixe, ou si la commande échoue avec RegistryPolicyNotFoundException, retournez à [Étape 2 : Configuration des autorisations pour le registre en amont](#reg-ecr-ptc) et assurez-vous d'avoir enregistré la politique. 1. Vérifiez qu'un modèle de création de référentiel existe pour chaque préfixe de référentiel de cache. Transmettez tous les préfixes que vous avez créés : ``` aws ecr describe-repository-creation-templates \ --prefixes {{ecr-repository-prefix-1}} {{ecr-repository-prefix-2}} \ --region {{region}} ``` Pour chaque préfixe, le modèle qu'Amazon ECR applique à ses référentiels de cache, identifié dans le paragraphe suivant, doit comporter `PULL_THROUGH_CACHE` dans `appliedFor` et un `repositoryPolicy` qui accorde `omics.amazonaws.com` les actions d'extraction de [Étape 3 : Création de modèles de référentiel](#repo-create-templates-ptc), `ecr:BatchGetImage` et `ecr:GetDownloadUrlForLayer`. Une politique non vide ne suffit pas : confirmez le principal ainsi que les actions. Amazon ECR applique le modèle dont le préfixe correspond le plus longtemps au référentiel, ou un `ROOT` modèle si aucun préfixe ne correspond. Exécutez la commande sans `--prefixes` pour voir tous les modèles, car `--prefixes` correspond exactement à chaque préfixe plutôt que par chemin, donc ni un `ROOT` aucun modèle comportant un préfixe plus long n'apparaît dans la sortie filtrée. Revenez à cette étape pour tout préfixe dont le modèle applicable est manquant ou qui ne répond pas à l'une ou l'autre des exigences. `imageTagMutability` n'a aucune incidence sur le fait que HealthOmics peut extraire l'image, mais un modèle qui la définit comme autre chose que `MUTABLE` empêche Amazon ECR d'actualiser une image mise en cache lorsque la balise amont est déplacée, comme décrit dans [Étape 3 : Création de modèles de référentiel](#repo-create-templates-ptc). Si des référentiels de cache existaient avant la création du modèle, confirmez également la politique de référentiel pour chacun d'entre eux, comme décrit dans [Mise à jour des référentiels créés avant le modèle](#ecr-ptc-troubleshoot-template-late). Si votre définition utilise les URI en amont, confirmez la carte de registre que vous avez ajoutée [Étape 4 : Ajout d'une carte de registre de conteneurs (si votre flux de travail utilise des URI en amont)](#ecr-ptc-registry-map). Une carte appartient au flux de travail ou à la version du flux de travail que vous lui avez fournie, alors vérifiez celle que vos exécutions utilisent : la version que vous transmettez comme `--workflow-version-name` pour **start-run**, ou le flux de travail si vos exécutions n'en nomment aucun. Pour une course qui existe déjà, `workflowVersionName` dans le **get-run** la sortie nomme sa version. Pour un flux de travail : ``` aws omics get-workflow \ --id {{workflow-id}} \ --region {{region}} ``` Pour une version du flux de travail : ``` aws omics get-workflow-version \ --workflow-id {{workflow-id}} \ --version-name {{version-name}} \ --region {{region}} ``` Vérifiez le `containerRegistryMap` valeur dans la sortie. S'il n'y a pas de carte, la réponse omet le champ. Confirmez que `status` est `ACTIVE`: s'il est toujours `CREATING`, attendez et réessayez, et si c'est le cas `FAILED`, la raison en est `statusMessage`. Vous ne pouvez pas modifier une carte sur place. Par conséquent, si elle est manquante ou erronée, créez une nouvelle version du flux de travail comme décrit dans [Re-running la configuration](#rerun-ecr-ptc). Pour confirmer de bout en bout qu'une exécution a utilisé une image mise en cache, lisez le résultat d'une exécution utilisant le cache. Une exécution déjà terminée fonctionne, y compris une exécution qui a échoué, mais une exécution annulée n'aura peut-être jamais résolu ses images ; lancez une course uniquement si vous n'en avez pas encore une : ``` aws omics get-run \ --id {{run-id}} \ --region {{region}} ``` Le `resourceDigests` Le champ de sortie, lorsque l'exécution en signale une, enregistre les ressources que l'exécution a résolues, y compris ses images de conteneur. Une entrée dont la clé est un URI privé Amazon ECR sous le préfixe de votre référentiel de cache, avec un `sha256` digest comme valeur, confirme que l'exécution a résolu cette image dans votre cache. Il s'agit de la vérification la plus rapide, et elle fonctionne même pour une exécution qui a échoué pour une raison indépendante. Si la course s'arrête sans succès, `failureReason` et `statusMessage` ensemble, vous indiquent si cette configuration est impliquée. Vérifiez ces points avant d'examiner les tâches de l'exécution, car une exécution qui échoue sur une image risque de ne créer aucune tâche : + REPOSITORY\_ECR\_NOT\_FOUND, ECR\_IMAGE\_NOT\_FOUND ou ECR\_PERMISSION\_ERROR pour un URI d'image sous l'un des préfixes de votre dépôt de cache, passez à [Résolution des problèmes liés à l'extraction du cache](#ecr-ptc-troubleshooting). L'une des raisons pour lesquelles un URI ne se trouve pas sous l'un de vos préfixes est un problème Amazon ECR avec ce référentiel plutôt qu'un problème de cache d'extraction, car aucune règle de cache ne s'y applique. Pour un référentiel que vous gérez vous-même dans Amazon ECR, donnez HealthOmics accès avec une politique de dépôt, comme décrit dans [Création d'une politique de ressources pour le référentiel Amazon ECR](permissions-ecr.md#permissions-resource-policy). + UR\_ECR\_IMAGE\_URI NON VALIDE — la carte de registre est manquante, elle n'a aucun mappage pour le registre en amont de l'image, son `upstreamRepositoryPrefix` ne couvre pas le chemin de l'image, ou l'URI de l'image n'est pas valide. Lisez le message d'état pour les différencier et vérifiez l'URI avant de modifier la carte. Consultez [Étape 4 : Ajout d'une carte de registre de conteneurs (si votre flux de travail utilise des URI en amont)](#ecr-ptc-registry-map). + CANNOT\_START\_CONTAINER\_ERROR ou ÉCHEC DE LA VÉRIFICATION\_D'IMAGE pour un URI d'image sous l'un de vos préfixes : l'image a atteint votre dépôt de cache mais la tâche n'a pas pu l'utiliser. Si vous avez modifié ou recréé la règle de cache, une image en cache obsolète peut en être la cause ; voir [Modification d'une règle de cache pendant qu'une exécution est active](#ecr-ptc-troubleshoot-rule-change). Sinon, c'est l'image mise en cache elle-même qui pose problème plutôt que cette configuration, et c'est l'image en amont ou la tâche qui l'utilise qui constitue l'endroit où chercher. + Toute autre raison d'échec, ou aucune raison du tout en cas d'annulation d'une exécution : l'exécution s'est arrêtée pour une raison indépendante de cette configuration. Pour les états d'exécution et les autres raisons d'échec, voir [Obtenir des informations sur la course](getinfo-about-runs.md) et [Motifs d'échec de l'exécution](workflows-run-errors.md). Ce ne sont pas tous les rapports de course `resourceDigests`, et une course qui n'a pas résolu ses images mais n'a aucune entrée pour celles-ci. Si le champ ou l'entrée est absent, ou si vous souhaitez confirmer quelle image une tâche individuelle a extraite, listez les tâches de l'exécution : ``` aws omics list-run-tasks \ --id {{run-id}} \ --region {{region}} ``` Un vide `items` la liste d'une course qui est toujours en cours signifie que HealthOmics n'a pas encore créé les tâches, alors attendez et listez-les à nouveau. Lors d'une exécution arrêtée, cela signifie qu'aucune tâche n'a jamais été créée : pour une exécution échouée, les raisons d'échec précédentes expliquent pourquoi, et une exécution annulée avant son démarrage n'a rien à confirmer, utilisez donc une autre exécution. Sinon, récupérez les détails de l'image pour l'une des tâches à l'aide d'un `taskId` à partir de la sortie précédente : ``` aws omics get-run-task \ --id {{run-id}} \ --task-id {{task-id}} \ --region {{region}} \ --query imageDetails ``` Dans `imageDetails`, `sourceImage` est l'URI de l'image issue de la définition de votre flux de travail, et `image` est l'URI privé Amazon ECR extrait par la tâche. Un `image` valeur sous le préfixe de votre référentiel de cache, sous la forme d'URI privé indiquée dans [Étape 4 : Ajout d'une carte de registre de conteneurs (si votre flux de travail utilise des URI en amont)](#ecr-ptc-registry-map) et éventuellement avec un résumé d'image en annexe, confirme que la tâche a utilisé votre cache d'extraction. `imageDetails` peut être vide, pour une tâche qui n'a pas encore extrait son image et pour certaines tâches déjà terminées. Une tâche pour laquelle aucun détail d'image n'est enregistré n'en a pas non plus dans le journal du manifeste d'exécution. Vérifiez donc une autre tâche de la même exécution. Si aucune tâche ne les a enregistrées au cours d'une exécution terminée, vous pouvez toujours confirmer que l'image est mise en cache, comme décrit dans [Résoudre une politique de registre manquante ou incomplète](#ecr-ptc-troubleshoot-registry-policy). Cela confirme la configuration plutôt que l'image extraite par une tâche particulière, car une exécution précédente a peut-être rempli le cache. Une fois l'exécution terminée, son journal du manifeste d'exécution répète ces informations d'image, afin que vous puissiez vérifier les tâches de l'exécution en une seule fois au lieu d'appeler **get-run-task** pour chacun. Dans l'enregistrement de chaque tâche, le champ nommé `originalImage` correspond à `sourceImage` ici, et `image` est la même valeur que ci-dessus. Pour savoir où trouver le journal, voir [Surveillance HealthOmics avec CloudWatch Journaux](monitoring-cloudwatch-logs.md), et pour le reste de l'enregistrement d'une tâche, voir [Obtenir des informations sur la course](getinfo-about-runs.md). Après avoir configuré le cache d'extraction, vous pouvez créer un nouveau flux de travail ou une nouvelle version de flux de travail pour utiliser les conteneurs des registres configurés. Pour plus d’informations, consultez [Ajout de conteneurs privés ou tiers lors de la création du flux de travail](containers-workflow-creation.md). ## Re-running la configuration Vous pouvez répéter ces étapes, par exemple pour ajouter un préfixe ou pour corriger une politique. Les commandes de création échouent avec un code de sortie différent de zéro lorsque la ressource existe déjà, sans la modifier. **put-registry-policy** n'échoue pas, mais elle remplace l'ensemble de la politique de registre, comme décrit dans [Étape 2 : Configuration des autorisations pour le registre en amont](#reg-ecr-ptc). + Règle d'extraction du cache — **create-pull-through-cache-rule** échoue avec PullThroughCacheRuleAlreadyExistsException. Si le registre que vous ajoutez nécessite une authentification, créez d'abord son secret Secrets Manager, comme décrit dans [Conditions préalables](#ecr-ptc-prerequisites). + Politique d'autorisations du registre : ajoutez un `Resource` entrée pour chaque nouveau préfixe de référentiel de cache, comme décrit dans [Étape 2 : Configuration des autorisations pour le registre en amont](#reg-ecr-ptc); une politique qui énumère les préfixes individuellement n'en couvrira pas un nouveau. Confirmez la couverture avec **get-registry-policy**, comme décrit dans [Étape 5 : Vérification de la configuration de votre cache d'extraction](#verify-ecr-ptc). + Modèle de création de référentiel : créez un modèle pour un préfixe de référentiel de cache qui n'en possède pas, et mettez à jour le modèle existant pour modifier un préfixe qui en possède déjà un, comme décrit dans [Étape 3 : Création de modèles de référentiel](#repo-create-templates-ptc). L'exécution de la mise à jour sur le modèle d'un autre préfixe remplace ce modèle. Pour mettre à jour les référentiels déjà créés par Amazon ECR, consultez [Mise à jour des référentiels créés avant le modèle](#ecr-ptc-troubleshoot-template-late). + Carte du registre des conteneurs : vous fournissez la carte lorsque vous créez un flux de travail ou une version de flux de travail, et **update-workflow** et **update-workflow-version** Je ne peux pas le changer. Avant de créer une version, préparez la carte complète : une nouvelle version n'hérite pas de la carte de la version précédente. Dressez donc la liste de tous les mappages dont le flux de travail a encore besoin, et pas seulement de la nouvelle. **create-workflow-version** prend la version complète plutôt que la carte. Vous avez donc également besoin de la définition du flux de travail et des autres paramètres de la version, comme décrit dans [Création d'une version du flux de travail](workflows-version-create.md). Créez ensuite la version avec la carte mise à jour, comme décrit dans [Étape 4 : Ajout d'une carte de registre de conteneurs (si votre flux de travail utilise des URI en amont)](#ecr-ptc-registry-map), et commencez vos courses avec cette version. Une exécution qui ne nomme pas de version utilise la version par défaut du flux de travail, qui conserve la carte avec laquelle il a été créé. Elle échoue donc de la même manière qu'auparavant. Pour plus d’informations, consultez [Version du flux de travail par défaut](workflows-default-version.md). ## Résolution des problèmes liés à l'extraction du cache Les problèmes de configuration suivants entraînent l'échec d'une exécution lorsque vous utilisez des conteneurs provenant du cache d'extraction. Si la définition de votre flux de travail utilise les URI des images en amont et qu'une exécution échoue avec UR\_ECR\_IMAGE\_URI NON VALIDE, commencez par la carte du registre, comme décrit dans [Étape 4 : Ajout d'une carte de registre de conteneurs (si votre flux de travail utilise des URI en amont)](#ecr-ptc-registry-map). Pour d'autres raisons d'échec d'exécution, voir [Motifs d'échec de l'exécution](workflows-run-errors.md). Exécutez le **aws ecr** commandes de cette section dans le même compte que dans [Étape 5 : Vérification de la configuration de votre cache d'extraction](#verify-ecr-ptc), ou laissez-passer `--registry-id {{ecr-account-id}}`. Utilisez les noms des référentiels exactement comme **describe-repositories** les renvoie : un nom de dépôt de cache est le préfixe du référentiel de cache suivi du chemin du référentiel en amont, qui, pour un nom abrégé de Docker Hub, inclut le `library/` segment décrit dans [Étape 4 : Ajout d'une carte de registre de conteneurs (si votre flux de travail utilise des URI en amont)](#ecr-ptc-registry-map). ### Résoudre une politique de registre manquante ou incomplète **Symptôme**—L'exécution échoue pour l'URI de l'image pour l'une des raisons suivantes : + REPOSITORY\_ECR\_NOT\_FOUND — le dépôt de cache n'existe pas dans votre registre privé. + ECR\_IMAGE\_NOT\_FOUND — le dépôt de cache existe, mais l'image n'y a jamais été importée. + ECR\_PERMISSION\_ERROR — Amazon ECR refuse l'accès. Si le référentiel de cache est absent, la commande suivante ne renvoie aucun référentiel pour le préfixe : ``` aws ecr describe-repositories \ --region {{region}} \ --query "repositories[?starts_with(repositoryName, '{{ecr-repository-prefix}}/')]" ``` Un résultat vide pour un préfixe dont rien n'a encore été extrait est attendu et ne constitue pas en soi un problème de configuration. Lorsqu'une exécution échoue pour l'URI de l'image, un référentiel manquant signifie généralement qu'Amazon ECR n'a pas pu le créer. Si le référentiel existe, vérifiez si l'image l'a atteint : ``` aws ecr describe-images \ --repository-name {{cache-repository-name}} \ --image-ids imageTag={{tag}} \ --region {{region}} ``` Une image renvoyée signifie que la balise est mise en cache. ImageNotFoundException signifie que le référentiel existe mais que cette balise n'y figure pas, et RepositoryNotFoundException signifie que le nom du dépôt est erroné ou que rien n'a encore été extrait du préfixe. Passe `--image-ids`: sans elle, la commande signale toutes les balises du référentiel, de sorte que la présence d'une autre balise peut être considérée comme une réussite pour la balise dont votre exécution a besoin. **Cause**—La politique de registre n'accorde pas HealthOmics ce dont elle a besoin : il n'y a pas de politique, il manque une action à la politique, ou `Resource` la liste ne couvre pas ce préfixe de cache. **Solution**—Ajoutez ou corrigez la politique de registre comme décrit dans [Étape 2 : Configuration des autorisations pour le registre en amont](#reg-ecr-ptc), et confirmez-le comme décrit dans [Étape 5 : Vérification de la configuration de votre cache d'extraction](#verify-ecr-ptc). Si la politique de registre couvre déjà le préfixe du référentiel de cache, la politique de registre n'est pas le problème. Pour ECR\_IMAGE\_NOT\_FOUND, où le référentiel existe mais où l'image n'est jamais arrivée, l'importation en amont a échoué : confirmez les informations d'identification de la règle avec **validate-pull-through-cache-rule**, comme décrit dans [Étape 5 : Vérification de la configuration de votre cache d'extraction](#verify-ecr-ptc). Pour ECR\_PERMISSION\_ERROR sur un référentiel existant, continuez à [Résoudre un modèle de création de référentiel ou une politique de référentiel manquant](#ecr-ptc-troubleshoot-template). Ensuite, recommencez la course. ### Résoudre un modèle de création de référentiel ou une politique de référentiel manquant **Symptôme**—Un référentiel de cache existe avec l'image importée et l'exécution échoue toujours avec ECR\_PERMISSION\_ERROR pour l'URI de l'image. **Cause**—Aucun modèle de création de référentiel ne correspond au préfixe du référentiel de cache, le modèle n'inclut pas `PULL_THROUGH_CACHE` dans `appliedFor`, ou le modèle n'a aucune politique de référentiel. Le référentiel n'a donc pas de politique permettant HealthOmics tirez-en. **Solution**—Créez ou mettez à jour le modèle comme décrit dans [Étape 3 : Création de modèles de référentiel](#repo-create-templates-ptc). Étant donné que les référentiels existent déjà, appliquez-leur également la politique, comme décrit dans [Mise à jour des référentiels créés avant le modèle](#ecr-ptc-troubleshoot-template-late). ### Mise à jour des référentiels créés avant le modèle **Symptôme**—Vous avez créé ou corrigé le modèle de création du référentiel, **describe-repository-creation-templates** l'affiche comme étant correcte, et l'exécution échoue toujours avec une erreur d'accès Amazon ECR pour la même image. Confirmez la politique manquante sur un référentiel concerné : ``` aws ecr get-repository-policy \ --repository-name {{cache-repository-name}} \ --region {{region}} ``` Le `policyText` la valeur doit être accordée `omics.amazonaws.com` au moins les actions accordées par la politique de référentiel du modèle. Si le référentiel n'a aucune politique, la commande échoue avec RepositoryPolicyNotFoundException. En cas d'échec avec RepositoryNotFoundException, le nom du référentiel est incorrect ou le référentiel n'existe pas encore. **Cause**—Un modèle ne s'applique que lorsqu'Amazon ECR crée un référentiel. Par conséquent, les référentiels créés avant que vous n'ajoutiez le modèle n'ont aucune politique de référentiel pour HealthOmics. **Solution**—Mettez à jour les référentiels existants de l'une des manières suivantes. **Avertissement** La suppression d'un référentiel entraîne également la suppression de toutes les images mises en cache et vous ne pouvez pas l'annuler. Ne supprimez pas un référentiel pendant qu'une exécution l'utilise. + Définissez directement la politique pour chaque référentiel existant. Enregistrez la politique de référentiel du modèle dans un fichier, puis exécutez la commande suivante pour chaque référentiel concerné : ``` aws ecr set-repository-policy \ --repository-name {{cache-repository-name}} \ --policy-text file://{{repository-policy-file}}.json \ --region {{region}} ``` + Supprimez chaque référentiel concerné. La fonction Pull Through cache la recrée à partir du modèle la prochaine fois qu'une tâche extrait l'image. L'image mise en cache ne sera donc pas disponible tant que cette extraction n'est pas terminée. ``` aws ecr delete-repository \ --repository-name {{cache-repository-name}} \ --force \ --region {{region}} ``` ### Modification d'une règle de cache pendant qu'une exécution est active **Symptôme**—Après avoir modifié ou recréé une règle d'extraction du cache, une exécution utilisant déjà le référentiel concerné peut échouer avec CANNOT\_START\_CONTAINER\_ERROR ou ÉCHEC DE LA VÉRIFICATION\_D'IMAGE, ou pouvez compléter en utilisant une image à laquelle vous ne vous attendiez pas. **Cause**—Le préfixe du référentiel de cache renvoie désormais à un référentiel en amont différent, tandis que les exécutions sont déjà extraites des référentiels créés par l'ancienne règle. **Solution**—Attendez la fin des essais actifs avant de modifier la règle, comme indiqué dans [Étape 1 : Création d'une règle de cache d'extraction](#create-ecr-ptc) décrit. Pour vérifier quelle image une tâche a réellement utilisée, cochez `imageDetails` dans le **get-run-task** sortie, comme décrit dans [Étape 5 : Vérification de la configuration de votre cache d'extraction](#verify-ecr-ptc). Si une exécution a utilisé une image en cache obsolète, supprimez cette image du référentiel de cache afin que la prochaine extraction l'actualise à partir du registre en amont.