As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Usando registros de terceiros suportados pelo pull through cache
Você pode usar as regras de pull through cache do Amazon ECR para sincronizar repositórios em um registro upstream compatível com seus repositórios privados do Amazon ECR. Para obter mais informações, consulte Sincronizar um registro upstream na Guia do usuário do Amazon Elastic Container Registry.
Na primeira vez que uma imagem é extraída, o cache pull through cria o repositório de imagens em seu registro privado e o mantém sincronizado com a imagem upstream, desde que as tags de imagem do repositório permaneçam mutáveis.
HealthOmics suporta o cache de extração para os seguintes registros upstream:
Amazon ECR Public
Registro de imagens de contêiner Kubernetes
Quay
Docker Hub
Microsoft Azure Container Registry
GitHub Registro de contêiner
GitLab Registro de contêiner
Para registros que acessam o cache não suportam, HealthOmics copia as imagens em seus repositórios privados do Amazon ECR. Para obter mais informações, consulte O uso de registros de terceiros não é suportado pelo pull through cache.
Os benefícios de usar o cache pull through do Amazon ECR incluem:
-
Você evita a necessidade de migrar manualmente imagens de contêiner para o Amazon ECR ou sincronizar atualizações do repositório de terceiros.
-
Os fluxos de trabalho acessam as imagens sincronizadas do contêiner em seu repositório privado, o que é mais confiável do que baixar conteúdo em tempo de execução de um registro público.
-
Como os caches pull through do Amazon ECR usam uma estrutura de URI previsível, você pode manter os URIs de imagem upstream em sua definição de fluxo de trabalho e adicionar um mapa de registro de contêineres que os resolva aos seus repositórios de cache. Para obter mais informações, consulte Etapa 4: Adicionar um mapa de registro de contêiner (se seu fluxo de trabalho usar URIs upstream).
Tópicos
Pré-requisitos
Se um registro upstream exigir autenticação, o AWS Secrets Manager segredo deve estar no mesmo Conta da AWS
e Region como regra de extração de cache. Ao criar a regra, passe --credential-arn o ARN do segredo exatamente como o Secrets Manager o retorna, incluindo o sufixo que o Secrets Manager acrescenta ao nome. O gerente de segredos create-secret e describe-secret ambas as respostas o retornam. Os exemplos de ARNs neste tópico abreviam o nome secreto.
| Registro upstream | URL do registro | O segredo do Secrets Manager é necessário |
|---|---|---|
Amazon ECR Public |
|
Não |
Registro de imagens de contêiner Kubernetes |
|
Não |
Quay |
|
Não |
Docker Hub |
|
Sim |
Microsoft Azure Container Registry |
|
Sim |
GitHub Registro de contêiner |
|
Sim |
GitLab Registro de contêiner |
|
Sim |
O nome secreto deve começar com ecr-pullthroughcache/. Para os outros requisitos, consulte Armazenando suas credenciais de repositório upstream em um AWS Secrets Manager secreto na Guia do usuário do Amazon Elastic Container Registry.
Configurando o cache de extração
O Amazon ECR fornece um registro para seu Conta da AWS em cada região. Certifique-se de criar a configuração do Amazon ECR na mesma região em que planeja executar o fluxo de trabalho.
Conclua as seguintes tarefas de configuração em ordem. A etapa 4 se aplica somente se sua definição de fluxo de trabalho usar os URIs de imagem upstream.
Tarefas de configuração
Etapa 1: Criando uma regra de pull through cache
Crie uma regra de cache pull through do Amazon ECR para cada registro upstream que tenha imagens que você deseja armazenar em cache. Uma regra especifica um mapeamento entre um registro upstream e o repositório privado do Amazon ECR.
Para um registro upstream que exige autenticação, você fornece suas credenciais usando AWS Secrets Manager.
nota
Não altere uma regra de pull through cache enquanto uma execução ativa estiver usando o repositório privado. A execução pode falhar ou, mais importante ainda, fazer com que seu pipeline use imagens inesperadas.
Para obter mais informações, consulte Criando uma regra de pull through cache na Guia do usuário do Amazon Elastic Container Registry.
Criação de uma regra de pull through cache usando o console
Para configurar o cache de extração, siga estas etapas usando o console do Amazon ECR:
Parte 1: Escolhendo o registro upstream
-
Abra o console do Amazon ECR
. -
No painel de navegação, em Registro privado, expanda Características e configurações, em seguida, escolha Extraia o cache.
-
Na Extraia o cache página, escolha Adicionar regra.
-
Na Registro upstream painel, escolha o registro upstream para sincronizar com seu registro privado e escolha Próximo.
-
Se o registro upstream exigir autenticação, na próxima página, especifique o segredo do Secrets Manager que contém suas credenciais. Escolha Próximo.
Parte 2: Especificando namespaces e criando a regra
-
Abaixo Especificar namespaces, na Namespace de cache painel, escolha se deseja criar os repositórios privados usando um prefixo de repositório específico ou sem prefixo. Se você optar por usar um prefixo, especifique o nome do prefixo em Prefixo do repositório de cache.
-
Na Namespace upstream painel, escolha se deseja extrair dos repositórios upstream usando um prefixo de repositório específico ou sem prefixo. Se você optar por usar um prefixo, especifique o nome do prefixo em Prefixo do repositório upstream.
O Exemplo de namespace O painel mostra um exemplo de pull request, URL upstream e URL do repositório de cache criado.
-
Escolha Próximo.
-
Revise a configuração e escolha Criar para criar a regra.
Criação de uma regra de pull through cache usando o AWS CLI
Use o Amazon ECR create-pull-through-cache-rule comando para criar uma regra de pull through cache. Para registros upstream que exigem autenticação, armazene as credenciais em um segredo do Secrets Manager.
Os exemplos a seguir mostram como criar uma regra para cada registro upstream compatível.
Você pode usar o get-run-task AWS CLI comando para recuperar informações sobre a imagem do contêiner usada para uma tarefa específica:
aws omics get-run-task --idrun-id--task-idtask-id
A saída inclui as seguintes informações sobre a imagem do contêiner:
"imageDetails": { "image": "string", "imageDigest": "string", "sourceImage": "string", ... }
Etapa 2: Configurando permissões para o registro upstream
Use as permissões do registro para permitir HealthOmics para usar o cache de extração e transferir as imagens do contêiner para o registro privado do Amazon ECR. Adicione uma política de registro do Amazon ECR ao registro que fornece os contêineres usados nas execuções.
A política a seguir concede permissão para HealthOmics serviço para criar repositórios com os prefixos de cache de extração especificados e para iniciar transferências upstream para esses repositórios.
Certifique-se Resource abrange todos os prefixos do repositório de cache que você criou e define a Região e o Conta da AWS em cada repositório ARN do registro que você está configurando, porque uma política de registro se aplica somente à sua própria região e conta.
-
Abra o console do Amazon ECR
. -
No painel de navegação, em Registro privado, expanda Permissões de registro, em seguida, escolha Gerar declaração.
-
No canto superior direito, escolha JSON. Insira uma política semelhante à seguinte:
-
Salve a política.
Para anexar a política ao AWS CLI em vez disso, salve-o em um arquivo e use o Amazon ECR put-registry-policy comando:
aws ecr put-registry-policy \ --policy-text file://registry-policy-file.json \ --regionregion
Importante
put-registry-policy substitui toda a política de registro. Se seu registro já tiver uma política, recupere-a com get-registry-policy, adicione o HealthOmics declaração e devolva a política combinada.
Para obter mais informações sobre as políticas do cache pull through do Amazon ECR, consulte Políticas para o Amazon ECR pull through cache.
Etapa 3: Criação de modelos de repositório
Para usar o cache pull through in HealthOmics, o repositório Amazon ECR deve ter um modelo de criação de repositório. O modelo define as configurações para quando você ou o Amazon ECR criarem um repositório privado para um registro upstream.
Cada modelo contém um prefixo de namespace de repositório, que o Amazon ECR usa para associar novos repositórios a um modelo específico. Os modelos especificam a configuração de todas as configurações do repositório, incluindo políticas de acesso com base em recursos, imutabilidade de tags, criptografia e políticas de ciclo de vida.
Para obter mais informações, consulte Modelos de criação de repositórios na Guia do usuário do Amazon Elastic Container Registry.
nota
Crie o modelo antes da primeira execução que usa o prefixo. Um prefixo sem modelo próprio e sem ROOT modelo, não tem política de repositório, então HealthOmics não consigo extrair suas imagens em cache. Deixe a mutabilidade da tag em MUTABLE, para que o Amazon ECR possa atualizar uma imagem em cache quando a tag upstream for alterada. Para repositórios que já existem, consulte Atualização de repositórios criados antes do modelo.
Para criar um modelo de criação de repositório, siga estas etapas usando o console do Amazon ECR:
Parte 1: Definindo o modelo
-
Abra o console do Amazon ECR
. -
No painel de navegação, em Registro privado, expanda Características e configurações, em seguida, escolha Modelos de criação de repositórios.
-
Selecione Criar modelo.
-
Em Detalhes do modelo, escolha Extraia o cache.
-
Escolha se deseja aplicar esse modelo a um prefixo específico ou a todos os repositórios que não correspondam a outro modelo.
Se você escolher Um prefixo específico, insira o valor do prefixo do namespace em Prefixo. Você especificou esse prefixo ao criar a regra de pull through cache.
-
Escolha Próximo.
Parte 2: Adicionando a configuração de criação do repositório
-
Na Adicionar configuração de criação de repositório página, para Permissões do repositório, use um dos exemplos de declarações de política ou insira uma semelhante ao exemplo a seguir:
-
(Opcional) Adicione configurações de repositório, como políticas de ciclo de vida e tags. O Amazon ECR aplica essas regras a todas as imagens de contêiner criadas para extração de cache que usam o prefixo especificado.
-
Escolha Próximo.
-
Revise a configuração e escolha Criar para criar o modelo.
Para criar o modelo com o AWS CLI em vez disso, salve a política do repositório do procedimento anterior em um arquivo e use o Amazon ECR create-repository-creation-template comando com --prefix defina como o prefixo do repositório de cache da sua regra de pull through cache. A descrição é opcional:
aws ecr create-repository-creation-template \ --prefixecr-repository-prefix\ --applied-for PULL_THROUGH_CACHE \ --repository-policy file://repository-policy-file.json \ --image-tag-mutability MUTABLE \ --description "description" \ --regionregion
Se já existir um modelo para o prefixo, create-repository-creation-template falha com TemplateAlreadyExistsException. Em vez disso, atualize o modelo existente em vigor:
aws ecr update-repository-creation-template \ --prefixecr-repository-prefix\ --applied-for PULL_THROUGH_CACHE \ --repository-policy file://repository-policy-file.json \ --image-tag-mutability MUTABLE \ --regionregion
Importante
update-repository-creation-template substitui cada valor que você passa, então --applied-for e --repository-policy sobrescreva a lista e a política existentes em vez de se fundir com elas. Recupere o modelo atual com describe-repository-creation-templates, mescle suas alterações e transmita os valores completos.
O Amazon ECR está configurado, mas o HealthOmics a configuração não está concluída. Se sua definição de fluxo de trabalho usa os URIs de imagem upstream, continue com Etapa 4: Adicionar um mapa de registro de contêiner (se seu fluxo de trabalho usar URIs upstream): sem um mapa de registro do contêiner, a execução falha após o início. Caso contrário, avance para Etapa 5: Verificar sua configuração de cache de extração.
Etapa 4: Adicionar um mapa de registro de contêiner (se seu fluxo de trabalho usar URIs upstream)
Os URIs de imagem em sua definição de fluxo de trabalho decidem se você precisa de um mapa de registro de contêiner:
| URIs de imagem em sua definição de fluxo de trabalho | Mapa de registro |
|---|---|
|
Os URIs upstream, no formato |
Adicione um mapa. O mapa diz HealthOmics qual prefixo do repositório de cache pertence a qual registro upstream, porque HealthOmics não lê suas regras de extração de cache. |
|
Os URIs privados do Amazon ECR de seus repositórios de cache, no formato |
Você não precisa de um mapa. HealthOmics usa cada URI conforme fornecido. |
Um nome de imagem escrito sem um host de registro é um nome abreviado do Docker Hub, que conta como um URI upstream e precisa de um mapa.
Se sua definição usa os dois tipos de URI, adicione um mapa para as imagens que usam os URIs upstream.
Importante
Com os URIs upstream, StartRun é bem-sucedido mesmo se o mapa estiver ausente ou não tiver mapeamento para o registro upstream de uma imagem. HealthOmics valida cada imagem ao criar a tarefa que a usa, de modo que a execução falhe após o início. Ambos os casos fornecem o motivo da falha UR_ECR_IMAGE_URI INVÁLIDO, e a mensagem de status da execução os distingue. Em vez disso, um mapeamento que resolve uma imagem para um repositório de cache que não existe fornece ECR_REPOSITORY_NOT_FOUND.
Espelhe sua regra de pull through cache no mapeamento: set upstreamRegistryUrl para o URL de registro upstream da regra, ecrRepositoryPrefix para seu prefixo de repositório de cache, e upstreamRepositoryPrefix para seu prefixo de repositório upstream, se a regra usar um.
Se seus repositórios de cache estiverem em um local diferente Conta da AWS do fluxo de trabalho, defina ecrAccountId à conta que possui os repositórios de cache e adicione as políticas entre contas descritas em Políticas para acesso entre contas do Amazon ECR. ecrAccountId o padrão é a própria conta do fluxo de trabalho.
nota
Para Docker Hub, defina upstreamRegistryUrl para registry-1.docker.io, o valor em Pré-requisitos. HealthOmics guloseimas registry-1.docker.io e docker.io como o mesmo host, de modo que um mapeamento também cubra URIs de imagem escritos com docker.io.
HealthOmics também expande um nome curto do Docker Hub antes de corresponder ao mapeamento: ubuntu:22.04 torna-se docker.io/library/ubuntu:22.04, e myorg/image:tag torna-se docker.io/myorg/image:tag. HealthOmics inserções library/ somente quando o nome da imagem em sua definição não tem nenhuma barra. O nome expandido também determina o caminho do repositório de cache, então ubuntu:22.04 resolve para ecr-repository-prefix/library/ubuntu:22.04
Você fornece o mapa ao criar o fluxo de trabalho ou a versão do fluxo de trabalho. Para saber o formato do mapa e as regras que decidem quais mapeamentos seu fluxo de trabalho precisa, consulte Mapeamentos de registro. Para mapeamentos de imagens, consulte Mapeamentos de imagens. Depois de adicionar o mapa, continue para Etapa 5: Verificar sua configuração de cache de extração.
Etapa 5: Verificar sua configuração de cache de extração
Execute o aws ecr comandos na conta que possui os repositórios de cache, porque get-registry-policy e describe-repository-creation-templates sempre leia o registro da conta chamadora e execute o aws omics comandos na conta proprietária do fluxo de trabalho. Use a região em que você executa seus fluxos de trabalho para ambos. As três verificações no procedimento a seguir são independentes, portanto, execute todas elas e colete todos os problemas antes de voltar para corrigi-los. A verificação do mapa de registro após o procedimento se aplica depois de criar o fluxo de trabalho ou a versão do fluxo de trabalho, conforme descrito em Adicionar contêineres privados ou de terceiros durante a criação do fluxo de trabalho. A verificação de ponta a ponta após ela também requer uma execução iniciada.
-
Confirme se a regra de pull through cache existe e aponta para o registro upstream esperado:
aws ecr describe-pull-through-cache-rules \ --regionregionCada regra que você criou aparece com sua
ecrRepositoryPrefixeupstreamRegistryUrl. Uma regra que define um prefixo de repositório upstream também mostraupstreamRepositoryPrefix, e uma regra que usa uma credencial também mostracredentialArn; O Amazon ECR omite cada um desses campos quando a regra não o define. Um vaziopullThroughCacheRuleslista significa que não existe nenhuma regra nesta região. Voltar para Etapa 1: Criando uma regra de pull through cache.Se a regra usar uma credencial, confirme também se o Amazon ECR pode ler o segredo e fazer login no registro upstream:
aws ecr validate-pull-through-cache-rule \ --ecr-repository-prefixecr-repository-prefix\ --regionregionA saída inclui
"isValid": truequando a autenticação for bem-sucedida e, caso contrário, nomeia o motivo emfailure. Se o comando falhar comPullThroughCacheRuleNotFoundException, nenhuma regra usa esse prefixo. UmAccessDeniedExceptionsignifica que seu chamador não tem oecr:ValidatePullThroughCacheRulepermissão, que as políticas somente para leitura nem sempre incluem, não que a regra esteja errada. Para obter mais informações, consulte Validando as regras de extração de cache na Guia do usuário do Amazon Elastic Container Registry. -
Confirme se a política de registro concede HealthOmics acesso:
aws ecr get-registry-policy \ --regionregionO
policyTextvalor na saída, que o Amazon ECR retorna JSON-escaped, deve conter a declaração de Etapa 2: Configurando permissões para o registro upstream, concedendoomics.amazonaws.comambosecr:CreateRepositoryeecr:BatchImportUpstreamImage, individualmente ou por meio de um curinga, cobrindo cada prefixo de repositório de cache que você criou. Um prefixo é coberto por umResourceentrada que corresponde aos repositórios de cache abaixo dela, como um ARN de repositório terminando no prefixo seguido por/*, um ARN de repositório que termina em/*sozinho, ou umResourcedo*. Um ARN que termina no próprio prefixo, sem/*, não cobre nada: o nome de um repositório de cache sempre tem um caminho abaixo do prefixo. Um ARN que nomeia uma região ou Conta da AWS além do próprio registro, também não cobre nada, conforme descrito em Etapa 2: Configurando permissões para o registro upstream. Se nenhuma instrução cobrir um prefixo, ou se o comando falhar comRegistryPolicyNotFoundException, voltar para Etapa 2: Configurando permissões para o registro upstream e certifique-se de que você salvou a política. -
Confirme se existe um modelo de criação de repositório para cada prefixo de repositório de cache. Passe todos os prefixos que você criou:
aws ecr describe-repository-creation-templates \ --prefixesecr-repository-prefix-1ecr-repository-prefix-2\ --regionregionPara cada prefixo, o modelo que o Amazon ECR aplica aos seus repositórios de cache — identificados no próximo parágrafo — deve ter
PULL_THROUGH_CACHEemappliedFore umrepositoryPolicyque concedeomics.amazonaws.comas ações de extração de Etapa 3: Criação de modelos de repositório,ecr:BatchGetImageeecr:GetDownloadUrlForLayer. Uma política não vazia não é suficiente: confirme o principal e as ações.O Amazon ECR aplica o modelo cujo prefixo é a correspondência mais longa para o repositório, ou um
ROOTmodelo se nenhum prefixo corresponder. Execute o comando sem--prefixespara ver todos os modelos, porque--prefixescorresponde a cada prefixo exatamente em vez de por caminho, então nem umROOTmodelo nem um modelo em um prefixo mais longo aparecem na saída filtrada. Retorne a essa etapa para obter qualquer prefixo cujo modelo aplicável esteja ausente ou não cumpra qualquer um dos requisitos.imageTagMutabilitynão afeta se HealthOmics pode extrair a imagem, mas um modelo que a define como algo diferente deMUTABLEimpede que o Amazon ECR atualize uma imagem em cache quando a tag upstream se move, conforme descrito em Etapa 3: Criação de modelos de repositório.Se existiam repositórios de cache antes de você criar o modelo, confirme também a política do repositório em cada um deles, conforme descrito em Atualização de repositórios criados antes do modelo.
Se sua definição usa os URIs upstream, confirme o mapa de registro que você adicionou Etapa 4: Adicionar um mapa de registro de contêiner (se seu fluxo de trabalho usar URIs upstream). Um mapa pertence ao fluxo de trabalho ou à versão do fluxo de trabalho que você forneceu, então verifique a que suas execuções usam: a versão que você passa como --workflow-version-name para start-run, ou o fluxo de trabalho, se suas execuções não mencionarem uma. Para uma corrida que já existe, workflowVersionName na get-run a saída nomeia sua versão.
Para um fluxo de trabalho:
aws omics get-workflow \ --idworkflow-id\ --regionregion
Para uma versão de fluxo de trabalho:
aws omics get-workflow-version \ --workflow-idworkflow-id\ --version-nameversion-name\ --regionregion
Verifique o containerRegistryMap valor na saída. Se não tiver mapa, a resposta omite o campo. Confirme que status é ACTIVE: se ainda estiver CREATING, espere e tente novamente, e se for FAILED, o motivo está em statusMessage. Você não pode alterar um mapa no local, portanto, se ele estiver ausente ou errado, crie uma nova versão do fluxo de trabalho conforme descrito em Re-running a configuração.
Para confirmar de ponta a ponta que uma execução usou uma imagem em cache, leia o resultado de uma execução que usa o cache. Uma execução que já terminou funciona, incluindo uma que falhou, mas uma execução cancelada pode nunca ter resolvido suas imagens; inicie uma execução somente se você ainda não tiver uma:
aws omics get-run \ --idrun-id\ --regionregion
O resourceDigests campo na saída, quando a execução relata uma, registra os recursos que a execução resolveu, incluindo suas imagens de contêiner. Uma entrada cuja chave é um URI privado do Amazon ECR sob o prefixo do seu repositório de cache, com um sha256 digest como seu valor, confirma que a execução resolveu essa imagem para seu cache. Essa é a verificação mais rápida e funciona até mesmo para uma execução que falhou por um motivo não relacionado.
Se a corrida parar sem sucesso, failureReason e statusMessage juntos informam se essa configuração está envolvida. Verifique essas opções antes de examinar as tarefas da execução, pois uma execução que falhe em uma imagem pode não criar nenhuma tarefa:
-
ECR_REPOSITORY_NOT_FOUND,ECR_IMAGE_NOT_FOUNDouECR_PERMISSION_ERRORpara um URI de imagem em um dos prefixos do seu repositório de cache — continue com Solução de problemas de extração de cache. Um desses motivos para um URI que não está sob um de seus prefixos é um problema do Amazon ECR com esse repositório, em vez de um problema de extração de cache, porque nenhuma regra de cache se aplica a ele. Para um repositório que você mesmo gerencia no Amazon ECR, forneça HealthOmics acesso com uma política de repositório, conforme descrito em Crie uma política de recursos para o repositório Amazon ECR. -
UR_ECR_IMAGE_URI INVÁLIDO— o mapa de registro está ausente, ele não tem mapeamento para o registro upstream da imagem, seuupstreamRepositoryPrefixnão cobre o caminho da imagem ou o URI da imagem não é válido. Leia a mensagem de status para diferenciá-las e verifique o URI antes de alterar o mapa. Consulte Etapa 4: Adicionar um mapa de registro de contêiner (se seu fluxo de trabalho usar URIs upstream). -
NÃO É POSSÍVEL INICIAR_CONTAINER_ERRORouFALHA_VERIFICAÇÃO_DE IMAGEMpara um URI de imagem sob um de seus prefixos — a imagem chegou ao seu repositório de cache, mas a tarefa não conseguiu usá-la. Se você alterou ou recriou a regra de cache, uma imagem obsoleta em cache pode causar isso; consulte Alterando uma regra de cache enquanto uma execução está ativa. Caso contrário, a imagem em cache em si é o problema, e não essa configuração, e a imagem upstream ou a tarefa que a usa é onde procurar. -
Qualquer outro motivo de falha, ou nenhum, conforme o relatório de uma execução cancelada — a execução foi interrompida por um motivo não relacionado a essa configuração. Para saber os status de execução e os outros motivos de falha, consulte Obtenha informações sobre a execução e Motivos de falha na execução.
Nem todos os relatórios de execução resourceDigests, e uma execução que ainda não resolveu suas imagens não tem entrada para elas. Se o campo ou a entrada estiverem ausentes, ou se você quiser confirmar qual imagem uma tarefa individual extraiu, liste as tarefas da execução:
aws omics list-run-tasks \ --idrun-id\ --regionregion
Um vazio items lista em uma corrida que ainda está em andamento significa que HealthOmics ainda não criou as tarefas, então espere e liste-as novamente. Em uma execução que foi interrompida, isso significa que nenhuma tarefa foi criada: para uma execução com falha, os motivos de falha anteriores explicam o porquê, e uma execução cancelada antes de ser iniciada não tem nada a confirmar, então use uma execução diferente. Caso contrário, recupere os detalhes da imagem para uma das tarefas, usando um taskId da saída anterior:
aws omics get-run-task \ --idrun-id\ --task-idtask-id\ --regionregion\ --query imageDetails
Em imageDetails, sourceImage é o URI da imagem da sua definição de fluxo de trabalho e image é o URI privado do Amazon ECR que a tarefa extraiu. Um image valor sob o prefixo do repositório de cache, no formato URI privado mostrado em Etapa 4: Adicionar um mapa de registro de contêiner (se seu fluxo de trabalho usar URIs upstream) e, possivelmente, com um resumo de imagem anexado, confirma que a tarefa usou seu cache de extração. imageDetails pode estar vazio, para uma tarefa que ainda não obteve sua imagem e para algumas tarefas que já foram concluídas. Uma tarefa sem detalhes de imagem registrados também não tem nenhum no log do manifesto de execução, então marque outra tarefa da mesma execução. Se nenhuma tarefa em uma execução concluída as registrou, você ainda poderá confirmar se a imagem está armazenada em cache, conforme descrito em Resolvendo uma política de registro ausente ou incompleta. Isso confirma a configuração e não a imagem que uma tarefa específica extraiu, porque uma execução anterior pode ter preenchido o cache.
Depois que uma execução é concluída, seu log de manifesto de execução repete essas informações de imagem, para que você possa verificar as tarefas da execução de uma só vez em vez de chamar get-run-task para cada um. No registro de cada tarefa, o campo chamado originalImage corresponde a sourceImage aqui, e image tem o mesmo valor acima. Para saber onde encontrar o registro, consulte Monitoramento HealthOmics com CloudWatch Registrose para o restante do registro de uma tarefa, consulte Obtenha informações sobre a execução.
Depois de configurar o pull through cache, você pode criar um novo fluxo de trabalho ou versão do fluxo de trabalho para usar os contêineres dos registros configurados. Para obter mais informações, consulte Adicionar contêineres privados ou de terceiros durante a criação do fluxo de trabalho.
Re-running a configuração
Você pode repetir essas etapas, por exemplo, para adicionar um prefixo ou corrigir uma política. Os comandos create falham com um código de saída diferente de zero quando o recurso já existe, sem alterá-lo. put-registry-policy não falha, mas substitui toda a política de registro, conforme descrito em Etapa 2: Configurando permissões para o registro upstream.
-
Regra de ultrapassar o cache — create-pull-through-cache-rule falha com
PullThroughCacheRuleAlreadyExistsException. Se o registro que você está adicionando precisar de autenticação, crie primeiro o segredo do Secrets Manager, conforme descrito em Pré-requisitos. -
Política de permissões de registro — adicione um
Resourceentrada para cada novo prefixo do repositório de cache, conforme descrito em Etapa 2: Configurando permissões para o registro upstream; uma política que enumera prefixos individualmente não cobrirá um novo. Confirme a cobertura com get-registry-policy, conforme descrito em Etapa 5: Verificar sua configuração de cache de extração. -
Modelo de criação de repositório — crie um modelo para um prefixo de repositório de cache que não tenha um e atualize o modelo existente para alterar um prefixo que já tenha um, conforme descrito em Etapa 3: Criação de modelos de repositório. Executar a atualização no modelo de outro prefixo substitui esse modelo. Para atualizar os repositórios que o Amazon ECR já criou, consulte Atualização de repositórios criados antes do modelo.
-
Mapa de registro de contêineres — você fornece o mapa ao criar um fluxo de trabalho ou uma versão do fluxo de trabalho e update-workflow e update-workflow-version não posso mudar isso. Antes de criar uma versão, tenha o mapa completo pronto: uma nova versão não herda o mapa da versão anterior, então liste todos os mapeamentos que o fluxo de trabalho ainda precisa, não apenas o novo. create-workflow-version usa a versão inteira em vez de apenas o mapa, então você também precisa da definição do fluxo de trabalho e dos outros parâmetros da versão, conforme descrito em Crie uma versão do fluxo de trabalho. Em seguida, crie a versão com o mapa atualizado, conforme descrito em Etapa 4: Adicionar um mapa de registro de contêiner (se seu fluxo de trabalho usar URIs upstream)e comece suas corridas com essa versão. Uma execução que não nomeia uma versão usa a versão padrão do fluxo de trabalho, que mantém o mapa com o qual foi criada e, portanto, falha da mesma forma que antes. Para obter mais informações, consulte Versão padrão do fluxo de trabalho.
Solução de problemas de extração de cache
Os problemas de configuração a seguir fazem com que uma execução falhe quando você usa contêineres do cache de extração. Se sua definição de fluxo de trabalho usar os URIs da imagem upstream e uma execução falhar com UR_ECR_IMAGE_URI INVÁLIDO, comece com o mapa do registro, conforme descrito em Etapa 4: Adicionar um mapa de registro de contêiner (se seu fluxo de trabalho usar URIs upstream). Para outros motivos de falha de execução, consulte Motivos de falha na execução.
Execute o aws ecr comandos nesta seção na mesma conta que em Etapa 5: Verificar sua configuração de cache de extração, ou passe --registry-id
. Use os nomes dos repositórios exatamente como describe-repositories os retorna: um nome de repositório de cache é o prefixo do repositório de cache seguido pelo caminho do repositório upstream, que, para um nome abreviado do Docker Hub, inclui o ecr-account-idlibrary/ segmento descrito em Etapa 4: Adicionar um mapa de registro de contêiner (se seu fluxo de trabalho usar URIs upstream).
Resolvendo uma política de registro ausente ou incompleta
Sintoma—A execução do URI da imagem falha com um dos seguintes motivos de falha:
-
ECR_REPOSITORY_NOT_FOUND— o repositório de cache não existe em seu registro privado. -
ECR_IMAGE_NOT_FOUND— o repositório de cache existe, mas a imagem nunca foi importada para ele. -
ECR_PERMISSION_ERROR— O Amazon ECR nega acesso.
Se o repositório de cache estiver ausente, o comando a seguir não retornará nenhum repositório para o prefixo:
aws ecr describe-repositories \ --regionregion\ --query "repositories[?starts_with(repositoryName, 'ecr-repository-prefix/')]"
Um resultado vazio para um prefixo do qual nada foi extraído ainda é esperado e não é um problema de configuração por si só. Quando a execução do URI da imagem falha, um repositório ausente geralmente significa que o Amazon ECR não conseguiu criá-lo. Se o repositório existir, confirme se a imagem chegou até ele:
aws ecr describe-images \ --repository-namecache-repository-name\ --image-ids imageTag=tag\ --regionregion
Uma imagem retornada significa que a tag está em cache. ImageNotFoundException significa que o repositório existe, mas essa tag não está nele, e RepositoryNotFoundException significa que o nome do repositório está errado ou que nada foi extraído do prefixo ainda. Passe --image-ids: sem ela, o comando relata cada tag no repositório, então a presença de outra tag pode parecer um sucesso para a tag que sua execução precisa.
Causa—A política de registro não concede HealthOmics o que ela precisa: não há política, a política está faltando uma ação ou sua Resource a lista não cobre esse prefixo de cache.
Solução—Adicione ou corrija a política de registro conforme descrito em Etapa 2: Configurando permissões para o registro upstreame confirme-o conforme descrito em Etapa 5: Verificar sua configuração de cache de extração. Se a política de registro já abranger o prefixo do repositório de cache, a política de registro não é o problema. Para ECR_IMAGE_NOT_FOUND, onde o repositório existe, mas a imagem nunca chegou, a importação upstream falhou: confirme a credencial da regra com validate-pull-through-cache-rule, conforme descrito em Etapa 5: Verificar sua configuração de cache de extração. Para ECR_PERMISSION_ERROR em um repositório existente, continue com Resolvendo um modelo de criação de repositório ou política de repositório ausente. Em seguida, inicie a corrida novamente.
Resolvendo um modelo de criação de repositório ou política de repositório ausente
Sintoma—O repositório de cache existe com a imagem importada e a execução ainda falha com ECR_PERMISSION_ERROR para o URI da imagem.
Causa—Nenhum modelo de criação de repositório corresponde ao prefixo do repositório de cache, o modelo não inclui PULL_THROUGH_CACHE em appliedFor, ou o modelo não tem política de repositório. O repositório, portanto, não tem uma política que permita HealthOmics retire-se disso.
Solução—Crie ou atualize o modelo conforme descrito em Etapa 3: Criação de modelos de repositório. Como os repositórios já existem, aplique também a política a eles, conforme descrito em Atualização de repositórios criados antes do modelo.
Atualização de repositórios criados antes do modelo
Sintoma—Você criou ou corrigiu o modelo de criação do repositório, describe-repository-creation-templates mostra que está correto, e uma execução ainda falha com um erro de acesso ao Amazon ECR para a mesma imagem. Confirme a política ausente em um repositório afetado:
aws ecr get-repository-policy \ --repository-namecache-repository-name\ --regionregion
O policyText valor deve ser concedido omics.amazonaws.com pelo menos as ações que a política de repositório do modelo concede. Se o repositório não tiver nenhuma política, o comando falhará com RepositoryPolicyNotFoundException. Se falhar com RepositoryNotFoundException, o nome do repositório está errado ou o repositório ainda não existe.
Causa—Um modelo se aplica somente quando o Amazon ECR cria um repositório, portanto, os repositórios criados antes de você adicionar o modelo não têm política de repositório para HealthOmics.
Solução—Atualize os repositórios existentes de uma das seguintes maneiras.
Atenção
A exclusão de um repositório também exclui todas as imagens em cache nele, e você não pode desfazê-las. Não exclua um repositório enquanto uma execução o estiver usando.
-
Defina a política diretamente em cada repositório existente. Salve a política de repositório do modelo em um arquivo e execute o seguinte comando para cada repositório afetado:
aws ecr set-repository-policy \ --repository-namecache-repository-name\ --policy-text file://repository-policy-file.json \ --regionregion -
Exclua cada repositório afetado. A extração do cache a recria a partir do modelo na próxima vez que uma tarefa extrair a imagem, então a imagem em cache não estará disponível até que a extração seja concluída.
aws ecr delete-repository \ --repository-namecache-repository-name\ --force \ --regionregion
Alterando uma regra de cache enquanto uma execução está ativa
Sintoma—Depois de alterar ou recriar uma regra de pull through cache, uma execução que já está usando o repositório afetado pode falhar com NÃO É POSSÍVEL INICIAR_CONTAINER_ERROR ou FALHA_VERIFICAÇÃO_DE IMAGEM, ou pode concluir usando uma imagem que você não esperava.
Causa—O prefixo do repositório de cache agora é resolvido para um repositório upstream diferente, enquanto as execuções já estão sendo retiradas dos repositórios criados pela regra antiga.
Solução—Aguarde até que as execuções ativas terminem antes de alterar a regra, conforme observado em Etapa 1: Criando uma regra de pull through cache descreve. Para confirmar qual imagem uma tarefa realmente usou, marque imageDetails na get-run-task saída, conforme descrito em Etapa 5: Verificar sua configuração de cache de extração. Se uma execução usou uma imagem em cache obsoleta, exclua essa imagem do repositório de cache para que a próxima extração a atualize do registro upstream.
