Workloads .NET no Amazon ECS e no AWS Fargate

Um cluster é um grupo lógico de recursos de computação em uma região específica. Os clusters mantêm as instâncias de contêineres em execução hospedando suas aplicações e componentes de aplicações, o que ajuda a isolá-las para que elas não usem a mesma infraestrutura subjacente. Isso melhora a disponibilidade, caso um item específico da infraestrutura que hospeda sua aplicação falhe. Somente o cluster afetado precisará ser reiniciado.

Independentemente de usar o Amazon ECS ou o Amazon ECS no AWS Fargate, você trabalhará com clusters. O que difere é o nível de gerenciamento que é esperado de você. Se você especificar o tipo de inicialização do EC2 ao criar clusters, você assumirá a responsabilidade de configurar e gerenciar esses clusters. No entanto, quando você usa o tipo de lançamento do Fargate, é responsabilidade do Fargate gerenciá-los.

Um contêiner contém todo o código, o runtime, as ferramentas e as bibliotecas do sistema necessárias para a execução da aplicação ou do componente da aplicação no contêiner. Quando você inicia instâncias de contêiner para hospedar suas aplicações, elas são executadas na infraestrutura de computação associada a um cluster.

Modelos somente leitura, conhecidos como imagens de contêiner, são usados para inicializar contêineres. Antes de usar uma imagem para executar seus contêineres, é necessário implantar a imagem do contêiner em um registro, por exemplo, o Amazon Elastic Container Registry (Amazon ECR) ou o Docker Hub.

Você define imagens de contêineres usando um recurso chamado Dockerfile. Um Dockerfile é um arquivo de texto que detalha todos os componentes e recursos que você deseja incluir na imagem. O Amazon ECS usa o mesmo Dockerfile usado ao definir imagens de contêiner para aplicações .NET em outros lugares, sem alterações. Por meio do comando docker build, você transforma os comandos e as configurações definidos no Dockerfile em uma imagem de contêiner que pode ser inserida em um registro ou executada localmente no Docker. As ferramentas de contêineres disponíveis na AWS, detalhadas no módulo 2, geralmente cuidam da criação e da inserção da imagem para você.

Uma definição de tarefa é um arquivo de texto no formato JSON usado para descrever os contêineres que compõem a sua aplicação. Uma única definição de tarefa pode descrever até dez contêineres.

Você pode pensar em uma definição de tarefa como um esquema do ambiente da aplicação, especificando os parâmetros da aplicação e do sistema operacional. Alguns exemplos são quais portas de rede devem estar abertas e quaisquer volumes de dados que precisem ser anexados, entre outros recursos.

O Amazon ECS não restringe sua aplicação a uma única definição de tarefa. Na verdade, é recomendável combinar contêineres relacionados a um componente que faz parte da sua aplicação em uma única definição de tarefa e usar várias definições de tarefa para descrever a aplicação inteira. Isso permite que os diferentes componentes lógicos que compõem a sua aplicação sejam escalonados de forma independente.

Considere uma aplicação da Web típica de n níveis, que inclui um nível de front-end de interface do usuário da Web, um nível de API, um nível intermediário e níveis de componentes de banco de dados. A imagem abaixo mostra como você pode agrupar esses níveis de componentes em diferentes definições de tarefas. Isso permite, por exemplo, que o nível da interface do usuário da Web seja escalonado horizontalmente, independentemente dos outros componentes e vice-versa, se houver um aumento no uso. Se você definisse todos os níveis em uma única definição de tarefa, toda a aplicação seria escalonada sob carga, inclusive os níveis que não estivessem passando por um aumento de uso, o que aumentaria o tempo para aumentar a escala horizontalmente (se a aplicação for grande) e potencialmente aumentaria seus custos financeiros.

Abaixo, você encontra um exemplo de definição de tarefa. Ele configura um servidor da Web usando contêineres do Linux no tipo de inicialização do Fargate.

{
   "containerDefinitions": [ 
      { 
         "command": [
            "/bin/sh -c \"echo '<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>' >  /usr/local/apache2/htdocs/index.html && httpd-foreground\""
         ],
         "entryPoint": [
            "sh",
            "-c"
         ],
         "essential": true,
         "image": "httpd:2.4",
         "logConfiguration": { 
            "logDriver": "awslogs",
            "options": { 
               "awslogs-group" : "/ecs/fargate-task-definition",
               "awslogs-region": "us-east-1",
               "awslogs-stream-prefix": "ecs"
            }
         },
         "name": "sample-fargate-app",
         "portMappings": [ 
            { 
               "containerPort": 80,
               "hostPort": 80,
               "protocol": "tcp"
            }
         ]
      }
   ],
   "cpu": "256",
   "executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole",
   "family": "fargate-task-definition",
   "memory": "512",
   "networkMode": "awsvpc",
   "runtimePlatform": {
        "operatingSystemFamily": "LINUX"
    },
   "requiresCompatibilities": [ 
       "FARGATE" 
    ]
}

Quando o Amazon ECS instancia uma definição de tarefa, ele cria uma ou mais tarefas que são executadas em um cluster. Uma tarefa é uma instância de contêiner em execução. Além de outras configurações de ambiente, a definição de tarefa especifica o número de tarefas, ou instâncias de contêiner, a serem executadas no cluster.

Você pode configurar tarefas para serem executadas de forma autônoma, o que faz com que o contêiner pare quando a tarefa for concluída, ou você pode executar tarefas continuamente como um serviço. Quando executado como parte de um serviço, o Amazon ECS mantém um número especificado de tarefas em execução simultânea, substituindo automaticamente os contêineres com falha.

Use uma tarefa autônoma para o código da aplicação que não precisa ser executado continuamente. O código é executado uma vez dentro da tarefa e depois termina, o que encerra a instância de contêiner. Um exemplo seria o processamento em lote de alguns dados.

As tarefas autônomas podem ser configuradas para serem executadas em uma programação ou em resposta a um evento. Elas são chamadas de tarefas programadas. Em ambos os casos, o Amazon EventBridge é usado para definir uma programação Cron ou um evento que fará com que sua tarefa seja executada. As programações Cron configuram uma tarefa para ser executada a cada N minutos, horas ou dias. Para que as tarefas programadas sejam executadas quando ocorrer um evento, você pode se inscrever em eventos definidos pela AWS ou em seus próprios eventos personalizados no Amazon EventBridge. Quando os eventos ocorrerem, o Amazon ECS executará a tarefa automaticamente.

Use tarefas programadas para códigos de aplicações que precisam ser executadas periodicamente sem a intervenção do operador para iniciar a tarefa manualmente. Exemplos de cenários são códigos para realizar uma inspeção de logs, operações de backup ou trabalhos periódicos de extração, transformação e carregamento (ETL).

Um serviço é uma coleção de uma ou mais tarefas que são executadas continuamente. Na definição da tarefa, você define o número de tarefas que o serviço deve manter, e o Amazon ECS monitora os contêineres para garantir que o número solicitado de tarefas esteja sempre disponível.

O Amazon ECS executa um agente em cada instância de contêiner em um cluster. Não é necessário instalar ou manter esse agente por conta própria. O agente relata informações sobre as tarefas em execução e a utilização das instâncias de contêineres, permitindo que o Amazon ECS detecte tarefas que falham ou param. Quando isso acontece, o Amazon ECS substitui as tarefas com falha por novas instâncias para manter o número especificado de tarefas no serviço, sem exigir que você mesmo monitore e adote medidas.

Use um serviço para o código da aplicação que precisa ser executada continuamente. Exemplos são o front-end de um site ou uma API da Web.

O código da aplicação executado em uma instância de contêiner geralmente precisa ler ou gravar dados com estado. Alguns exemplos são arquivos de dados temporários, dados obtidos de um serviço externo que você deseja armazenar em cache localmente por um curto período e bancos de dados, incluindo aqueles que usam o SQL Server em instâncias do Amazon EC2, instâncias do Amazon Relational Database Service (RDS) e outros contêineres. Como alternativa, as aplicações que são escalonadas em várias instâncias de contêineres podem precisar acessar o armazenamento compartilhado para dados temporários e de longo prazo.

As instâncias de contêiner em execução têm uma camada gravável que pode armazenar dados. No entanto, a camada gravável é transitória e destruída quando a instância de contêiner termina, seja por ação do usuário, seja porque a instância tornou-se não íntegra e o Amazon ECS a substituiu. Isso torna a camada gravável uma abordagem inadequada para o armazenamento de dados de longo prazo, como os dados em um banco de dados. Além disso, os dados na camada gravável só podem ser acessados pelo código executado na instância individual do contêiner, o que a torna inadequada para os dados que você precisa compartilhar em uma aplicação que abrange várias instâncias de contêiner.

Para permitir que os dados da aplicação sejam armazenados por um período maior do que o tempo de vida útil de uma instância de contêiner ou para que possam ser compartilhados entre várias instâncias de contêiner, a AWS oferece vários serviços de armazenamento. Esses serviços de armazenamento desacoplam o armazenamento de dados das instâncias de computação. O uso do armazenamento desacoplado das instâncias de computação permite que os dados da aplicação sobrevivam às instâncias de contêiner em que a aplicação está sendo executada e torna os dados compartilháveis entre várias instâncias.

Os serviços de armazenamento disponíveis para aplicações .NET em contêineres dependem do fato de as aplicações estarem sendo executadas em contêineres do Linux ou Windows.

Atualmente, os contêineres do Linux são compatíveis com o mais amplo conjunto de serviços de armazenamento para aplicações .NET quando executados no Amazon ECS ou no Amazon ECS no AWS Fargate. A escolha do serviço de armazenamento dependerá do fato de a aplicação precisar de acesso compartilhado e simultâneo aos dados.

O Amazon Elastic Block Store (Amazon EBS) é um serviço de armazenamento que fornece volumes de armazenamento em nível de bloco. Um volume do EBS fornece aplicações com armazenamento que pode ser montado em contêineres do Linux, acessado como um dispositivo de unidade normal. O Amazon EBS replica automaticamente os dados em volumes do EBS em uma zona de disponibilidade, o que o torna uma solução de armazenamento confiável que ajuda a aumentar a confiabilidade da aplicação em caso de falha de um volume de armazenamento.

Os volumes do EBS são redimensionáveis dinamicamente, são compatíveis com criptografia e também com snapshots para fazer cópias. Se necessário, é possível desvincular volumes de um contêiner e recolocá-los em outro. Para atender aos requisitos de desempenho e preço de sua aplicação, o Amazon EBS oferece diferentes tipos de volume.

Os volumes do EBS são criados em uma zona de disponibilidade específica em uma região. Em seguida, o volume pode ser montado em uma instância de contêiner, usando as configurações na definição da tarefa, em execução na mesma zona. Para acessar os mesmos dados de uma zona de disponibilidade diferente, faça um snapshot do volume e use-o para criar um novo volume em outro lugar na mesma região ou em outra região. Um snapshot único pode criar muitos volumes em regiões e zonas de disponibilidade. Essa é uma abordagem a ser considerada para dados de aplicações somente leitura que devem ser consumidos por aplicações que exigem alta disponibilidade e que você implantou em várias instâncias de contêineres que abrangem diferentes regiões e zonas de disponibilidade.

O Amazon EBS é uma boa solução de armazenamento a ser considerada para aplicações que exigem acesso rápido e de baixa latência a dados que não são compartilhados simultaneamente, pois as aplicações são escalonadas horizontalmente (ou seja, executadas em várias instâncias de contêineres). Os exemplos incluem sistemas de arquivos gerais e bancos de dados que são acessados de uma única instância de contêiner.

O Amazon EBS não é compatível com o acesso simultâneo a um volume. Para aplicações em que é necessário compartilhar um único sistema de arquivos montado em vários contêineres, considere o Amazon Elastic File Service ou um dos sistemas de arquivos disponíveis no Amazon FSx.

O Amazon EFS fornece um serviço de sistema de arquivos escalonável, que é acessado por meio do Network File System (NFS) e não exige que você gerencie o armazenamento. Os sistemas de arquivos gerenciados pelo Amazon EFS podem ser anexados a várias instâncias de contêineres baseadas no Linux simultaneamente, com consistência de leitura e gravação e bloqueio de arquivos. Isso permite o compartilhamento de dados em uma unidade, para acesso de leitura e gravação, em vários contêineres que hospedam uma aplicação escalonada. O armazenamento do Amazon EFS também é dinâmico e expande (e diminui) a capacidade automaticamente à medida que as necessidades de armazenamento das aplicações mudam.

Você só paga pelo armazenamento que suas aplicações consomem. Por padrão, os dados em sistemas de arquivos criados no Amazon EFS são armazenados em várias zonas de disponibilidade em uma região para fornecer resiliência e durabilidade. O Amazon EFS refere-se a esse modo como a classe de armazenamento Standard. Se uma aplicação não precisar de armazenamento multi-AZ completo, use a classe de armazenamento One Zone para reduzir os custos. As classes de armazenamento Standard-Infrequent Access e One Zone-Infrequent Access também estão disponíveis para hospedar dados que as aplicações acessam de forma não regular para reduzir mais os custos.

Os sistemas de arquivos do Amazon EFS são adequados para uma ampla variedade de aplicações, incluindo aplicações da Web, sistemas de gerenciamento de conteúdo, pastas pessoais para usuários e servidores de arquivos em geral. Os sistemas de arquivos são compatíveis com autenticação, autorização e criptografia. O controle de acesso usa permissões POSIX padrão.

O exemplo de snippet de definição de tarefa abaixo mostra como montar um sistema de arquivos do EFS para uma tarefa.

"containerDefinitions":[
    {
        "mountPoints": [ 
            { 
                "containerPath": "/opt/my-app",
                 "sourceVolume": "Shared-EFS-Volume"
            }
    }
  ]
...
"volumes": [
    {
      "efsVolumeConfiguration": {
        "fileSystemId": "fs-1234",
        "transitEncryption": "DISABLED",
        "rootDirectory": ""
      },
      "name": "Shared-EFS-Volume"
    }
  ]
                                            

O Lustre é um sistema de arquivos de código aberto projetado para atender às necessidades de desempenho de machine learning, computação de alta performance (HPC), processamento de vídeo e modelagem financeira. Para aplicações .NET que abordam essas soluções ou outros cenários que exigem latências inferiores a milissegundos, o Amazon FSx para Lustre pode fornecer a camada de armazenamento persistente para contêineres do Linux.

Observação: no momento em que este artigo foi escrito, as tarefas executadas no AWS Fargate não eram compatíveis com sistemas de arquivos do FSx para Lustre.

Os sistemas de arquivos criados no FSx para Lustre são compatíveis com POSIX. Isso significa que você pode continuar a usar os mesmos controles familiares de acesso a arquivos que já usa para suas aplicações .NET executadas no Linux. Os sistemas de arquivos hospedados no FSx para Lustre também oferecem consistência de leitura e gravação e bloqueio de arquivos.

Dependendo das necessidades da aplicação, está disponível uma opção de armazenamento de estado sólido (SSD) e de disco rígido (HDD), otimizado para diferentes requisitos de workload. O armazenamento SSD é adequado para aplicações com uso intensivo de IOPS que são sensíveis à latência e que normalmente apresentam operações de arquivo pequenas e de acesso aleatório. O tipo de armazenamento HDD é adequado para aplicações com requisitos de throughput elevado, geralmente envolvendo operações de arquivos grandes e sequenciais. Com o armazenamento HDD, também é possível adicionar um cache SSD somente para leitura, dimensionado para 20% do armazenamento HDD, de modo a permitir uma latência de menos de um milissegundo e IOPS mais alta, o que melhora o desempenho dos arquivos acessados com frequência.

Os sistemas de arquivos no FSx para Lustre também podem ser vinculados a um bucket do Amazon S3, com acesso total de leitura e gravação. Isso oferece à aplicação .NET a capacidade de processar objetos no bucket S3 como se já estivessem residentes em um sistema de arquivos, uma opção para aplicações criadas para processar dados de grandes conjuntos de dados baseados em nuvem já no S3, sem a necessidade de copiar esses dados em um sistema de arquivos antes de acessá-los e atualizá-los.

Observe que também é possível montar sistemas de arquivos Lustre usando um comando no contêiner do Docker com o pacote lustre-client; isso permite montar sistemas de arquivos dinamicamente dentro do contêiner.

Para contêineres do Windows que executam aplicações .NET e .NET Framework, o armazenamento de arquivos fornecido pelo Amazon FSx para Windows File Server está disponível para persistência e compartilhamento de dados em um ou mais contêineres em execução em uma tarefa.

O FSx para Windows File Server usa instâncias reais do Windows File Server, que podem ser acessadas por meio de compartilhamentos de arquivos padrão do Windows via SMB, para armazenar e fornecer dados de aplicações. Os compartilhamentos de arquivos padrão do Windows permitem o uso de recursos e ferramentas administrativas já familiares aos administradores do Windows File Server, como a restauração de arquivos do usuário final usando cópias de sombra, cotas de usuário e listas de controle de acesso (ACLs). O SMB também permite a conexão com um compartilhamento do FSx para Windows File Server de contêineres do Linux.

Os sistemas de arquivos no FSx para Windows File Server podem ajudar a reduzir os custos de armazenamento para aplicações que usam desduplicação e compactação de dados. Os recursos adicionais incluem criptografia de dados, acesso auditável a arquivos e backups automáticos programados. O acesso aos compartilhamentos do sistema de arquivos pode ser controlado por meio da integração com um Microsoft Active Directory (AD) on-premises ou com o Managed AD na AWS.

O FSx para Windows File Server é adequado para a migração de servidores de arquivos on-premises baseados no Windows para a nuvem, a fim de funcionar junto com aplicações .NET/.NET Framework em contêineres. Ele também é adequado para uso com aplicações .NET e .NET Framework que precisam de acesso à nuvem híbrida e a armazenamentos de dados on-premises (com o Gateway de Arquivos do Amazon FSx). Para aplicações que usam o SQL Server, o FSx para Windows File Server permite a execução dessas workloads de banco de dados sem a necessidade de licenciamento do SQL Server Enterprise.

O exemplo de snippet de definição de tarefa abaixo mostra como montar um sistema de arquivos criado no FSx para Windows File Server para uma tarefa.

{
    "containerDefinitions": [
        {
            "entryPoint": [
                "powershell",
                "-Command"
            ],
            "portMappings": [],
            "command": [...' -Force"],
            "cpu": 512,
            "memory": 256,
            "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
            "essential": false,
            "name": "container1",
            "mountPoints": [
                {
                    "sourceVolume": "fsx-windows-dir",
                    "containerPath": "C:\\fsx-windows-dir",
                    "readOnly": false
                }
            ]
        },
...
    ],
    "family": "fsx-windows",
    "executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole",
    "volumes": [
        {
            "name": "fsx-windows-vol",
            "fsxWindowsFileServerVolumeConfiguration": {
                "fileSystemId": "fs-0eeb5730b2EXAMPLE",
                "authorizationConfig": {
                    "domain": "example.com",
                    "credentialsParameter": "arn:arn-1234"
                },
                "rootDirectory": "share"
            }
        }
    ]
}

As aplicações baseadas em .NET (.NET 6 ou superior) podem usar a infraestrutura de contêineres provisionada e mantida pelo Fargate. O Fargate usa o Amazon Linux 2, que está disponível nas arquiteturas X86_64 ou ARM64. A definição da tarefa especifica a arquitetura necessária.

Observação: também é possível executar aplicações mais antigas baseadas em .NET Core 3.1 e .NET 5 no Fargate. No entanto, essas duas versões estão sem suporte da Microsoft, ou em breve estarão. O .NET 5 não era uma versão com suporte de longo prazo (LTS), e agora está sem suporte. No momento em que este artigo foi escrito, o .NET Core 3.1 estava na fase de suporte de manutenção, o que significa que ele está a seis meses ou menos do fim do suporte e está recebendo patches apenas para problemas de segurança.

Os contêineres do Windows no Fargate podem executar aplicações .NET Framework e .NET. Atualmente, o Fargate é compatível com duas versões do Windows Server para aplicações: Windows Server 2019 Full e Windows Server 2019 Core. Independentemente da versão usada, a AWS gerencia as licenças do sistema operacional Windows para você.

Observação: nem todos os recursos do Windows Server, e alguns recursos da AWS, estão disponíveis com contêineres do Windows no AWS Fargate. Consulte a documentação de serviço para obter informações atualizadas sobre as limitações e considerações dos recursos. Alguns exemplos de recursos não compatíveis estão listados abaixo.

• Contas de serviços gerenciado em grupo (gMSA).
• Sistemas de arquivos do Amazon FSx (que não sejam FSx para Windows File Server).
• Armazenamento temporário configurável.
• Volumes do Amazon Elastic File Store (Amazon EFS).
• Volumes de imagem.
• Serviço App Mesh e integração de proxy para tarefas.
  

A AWS fornece a cada conta um único registro privado em cada região da AWS, e cada registro pode conter zero ou mais repositórios (é necessário pelo menos um repositório para armazenar imagens). Cada registro regional em uma conta pode ser acessado usando um URL no formato https://aws_account_id.dkr.ecr.region.amazonaws.com, por exemplo, https://123456789012.dkr.ecr.us-west-2.amazonaws.com.

Os repositórios em um registro privado contêm imagens e artefatos do Docker e da Open Container Initiative (OCI). É possível usar tantos ou poucos repositórios quantos forem necessários para imagens e artefatos. Por exemplo, você pode usar um repositório para manter imagens para um estágio de desenvolvimento, outro para imagens em um estágio de teste e outro para imagens liberadas para um estágio de produção.

Os nomes de imagem em uma imagem de repositório devem ser exclusivos; no entanto, os repositórios do Amazon ECR também são compatíveis com namespaces. Isso permite que os nomes das imagens, que identificam imagens diferentes, sejam reutilizados em diferentes estágios do ambiente ou equipes em um único repositório.

Por padrão, as contas têm acesso de leitura e gravação aos repositórios em um registro privado. No entanto, as entidades principais do IAM e as ferramentas executadas no escopo dessas entidades principais devem obter permissões para usar a API do Amazon ECR e emitir comandos de extração/inserção usando ferramentas como a CLI do Docker em repositórios. Muitas das ferramentas detalhadas no módulo 2 deste curso lidam com esse processo de autenticação em seu nome.

Os repositórios privados podem ser criados usando o painel do Amazon ECR no Console de Gerenciamento da AWS, na visualização do AWS Explorer do kit de ferramentas da AWS para Visual Studio ou na linha de comando usando a AWS CLI ou as ferramentas da AWS para PowerShell. A captura de tela abaixo mostra a criação de um repositório privado de dentro do Visual Studio. Para fazer isso, expanda a entrada do Amazon Elastic Container Service na visualização do AWS Explorer e, no menu de contexto da entrada Repositórios, selecione Criar repositório:

O kit de ferramentas da AWS para Visual Studio não é compatível com o funcionamento do registro público do ECR nem com a ativação de recursos como a verificação automatizada e a criptografia de repositórios para novos repositórios no seu registro privado. Se esses recursos forem necessários, crie repositórios usando o Console de Gerenciamento da AWS ou as ferramentas de linha de comando, como a AWS CLI e as ferramentas da AWS para PowerShell.

Os repositórios e registros públicos do Amazon ECR estão disponíveis para qualquer pessoa para a extração de imagens que você publicar. Cada conta recebe um registro público que pode conter vários repositórios públicos. Assim como nos repositórios privados, os repositórios públicos armazenam imagens e artefatos do Docker e da Open Container Initiative (OCI).

Os repositórios em registros públicos são listados na Galeria pública do Amazon ECR. Isso permite que a comunidade encontre e extraia imagens públicas. A conta da AWS que possui um registro público tem acesso total de leitura e gravação aos repositórios que ele contém. As entidades principais do IAM que acessam os repositórios devem obter permissões que são fornecidas em um token e usar esse token para autenticação para a inserção de imagens (assim como acontece com os repositórios privados). No entanto, qualquer pessoa pode extrair imagens de seus repositórios públicos com ou sem autenticação.

Os repositórios da galeria são acessados por meio de um URL no formato https://gallery.ecr.aws/registry_alias/repository_name. O registry_alias é criado quando o primeiro repositório público é criado, e pode ser alterado. O URI para extrair uma imagem de um repositório público possui o formato public.ecr.aws/registry_alias/repository_name:image_tag.

A inserção de imagens em um repositório público requer permissões e autenticação no registro público. As permissões são fornecidas em um token, que deve ser fornecido durante a autenticação no registro. As imagens podem ser extraídas de um repositório público com ou sem autenticação prévia.

Imagens de cache de caches de pull-through de registros públicos upstream em seu registro privado no Amazon ECR. Atualmente, o Amazon ECR é compatível com o Amazon ECR Public e o Quay como registros upstream. O Amazon ECR verifica o upstream em busca de uma nova versão de imagem e atualiza o cache, caso haja uma nova versão disponível, uma vez a cada 24 horas. Os caches de pull-through podem ajudar a isolar seus processos de compilação e implantação de interrupções ou outros problemas que afetam os registros upstream.

Os repositórios de cache são criados automaticamente na primeira vez que uma imagem é extraída de um registro upstream configurado. As extrações de imagens usam endereços IP da AWS e não são afetadas pelas cotas de taxa de extração em vigor no registro upstream. As extrações de imagens para repositórios de cache são configuradas usando regras. Um número máximo de dez regras de cache de pull-through pode ser configurado para seu registro privado.

A imagem abaixo apresenta dois exemplos de regras, uma para armazenar em cache imagens do Amazon ECR Public e a segunda do Quay. Nessa configuração, na primeira vez em que as imagens forem extraídas do Amazon ECR Public, um repositório será criado automaticamente no namespace ecr-public usando o nome do repositório upstream e, da mesma forma, para as imagens extraídas do Quay.

O kit de ferramentas da AWS para Visual Studio não é compatível com o funcionamento do registro público do ECR nem com a ativação de recursos como a verificação automatizada e a criptografia de repositórios para novos repositórios no seu registro privado. Se esses recursos forem necessários, crie repositórios usando o Console de Gerenciamento da AWS ou as ferramentas de linha de comando, como a AWS CLI e as ferramentas da AWS para PowerShell.

As imagens extraídas de registros upstream para caches de pull-through são compatíveis com recursos adicionais do Amazon ECR disponíveis para seus repositórios privados, como a replicação e a verificação automatizada de vulnerabilidades.

a. Um registro para armazenar imagens de contêineres

b. Um registro de contêineres em execução

c. Um registro de tarefas em execução

d. Um registro de volumes de armazenamento mapeados para contêineres

a. Verdadeiro

b. Falso

a. Uma instância de um contêiner em execução

b. Uma definição de contêiner que será executado

c. Uma definição da composição de sua aplicação

d. Um grupo lógico de recursos computacionais

Respostas: 1-a, 2-b, 3-d