Workloads .NET no Amazon ECS e no AWS Fargate

MÓDULO 1

Módulo 1: compreensão do Amazon ECS, ECR e AWS Fargate

 MÓDULO DE APRENDIZADO

Visão geral

Este módulo apresenta o Amazon ECS, o Amazon ECS no AWS Fargate e o Amazon ECR. Você aprenderá sobre clusters, contêineres e imagens, tarefas e definições de tarefas, serviços e tipos de inicialização para contêineres em execução no Linux e no Windows. Por fim, você juntará todos esses elementos para examinar os cenários e os caminhos que podem ser seguidos para chegar à melhor solução de contêineres usando o Amazon ECS ou o Amazon ECS no AWS Fargate para suas aplicações .NET.

 Tempo para a conclusão

30 minutos

Introdução ao Amazon ECS

O Amazon ECS é um serviço usado para executar aplicações baseadas em contêineres na nuvem. Ele fornece um gerenciamento de contêineres altamente escalável e rápido e se integra a outros serviços da AWS para fornecer segurança, orquestração de contêineres, integração e implantação contínuas, descoberta de serviços, monitoramento e observabilidade.

Você pode iniciar contêineres usando imagens de contêineres, da mesma forma que inicia máquinas virtuais de imagens de máquinas virtuais. O Amazon ECS implanta e executa contêineres de imagens de contêineres implantados no Amazon Elastic Container Registry (Amazon ECR) ou no Docker Hub.

O Amazon ECS usa definições de tarefas para definir os contêineres que compõem a sua aplicação. Uma definição de tarefa especifica como os contêineres da sua aplicação são executados. Você pode definir e usar uma tarefa individual, que é executada e interrompida após a conclusão, ou pode definir que a tarefa seja executada em um serviço. Os serviços executam e mantêm continuamente um número específico de tarefas simultaneamente, o que é adequado para aplicações de execução mais longa, como aplicações da Web.

Se necessário, você pode optar por configurar e gerenciar a infraestrutura que hospeda seus contêineres ou usar o Amazon ECS no AWS Fargate para se beneficiar de uma abordagem sem servidor em que a AWS gerencia a infraestrutura de contêineres e você se concentra na sua aplicação. O Amazon ECS fornece dois modelos para a execução de contêineres, chamados de tipos de lançamento.

Tipo de inicialização do EC2

O tipo de inicialização do EC2 é usado para executar contêineres em uma ou mais instâncias do Amazon Elastic Compute Cloud (EC2) configuradas em clusters. Ao usar o tipo de inicialização do EC2, você tem controle total sobre a configuração e o gerenciamento da infraestrutura que hospeda seus contêineres.

Escolha o tipo de inicialização do EC2 para seus contêineres quando você precisar gerenciar sua infraestrutura ou quando suas aplicações exigirem um uso consistentemente alto do núcleo da CPU e da memória, quando precisarem ser otimizadas em termos de preço ou quando precisarem de armazenamento persistente.

Tipo de inicialização do Fargate

O tipo de inicialização do Fargate é uma opção de tecnologia sem servidor paga conforme o uso para executar seus contêineres. Tecnologia sem servidor significa que você não precisa configurar a infraestrutura para hospedar suas instâncias de contêiner, ao contrário do tipo de inicialização do EC2, que exige que você entenda como configurar e gerenciar clusters de instâncias para hospedar seus contêineres em execução.

Recursos do Amazon ECS

Além de usar os tipos de inicialização para controlar como você deseja gerenciar sua infraestrutura de contêineres, você encontrará e usará vários tipos de recursos ao trabalhar com o Amazon ECS.

Cluster

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.

Contêiner

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ê.

Definição de tarefa

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" 
    ]
}

Tarefa

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.

Tarefa programada

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).

Serviço

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.

Persistência dos dados da aplicação

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.

Opções de armazenamento persistente para contêineres do Linux

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.

Amazon Elastic Block Store (Amazon EBS)

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.

Amazon Elastic File System (Amazon EFS)

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"
    }
  ]
                                            

Amazon FSx para Lustre

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.

Opções de armazenamento persistente para contêineres do Windows

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.

Amazon FSx para Windows File Server

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"
            }
        }
    ]
}

Outras opções de armazenamento persistente

A AWS fornece vários outros serviços especializados de sistema de arquivos para lidar com as necessidades de armazenamento persistente para tarefas no ECS. Este curso não abordará esses sistemas e serviços de arquivos. Em vez disso, recomendamos que você consulte os detalhes do produto abaixo.

  • O Amazon FSx para OpenZFS oferece um armazenamento de arquivos totalmente gerenciado usando o sistema de arquivos OpenZFS. O OpenZFS é um sistema de arquivos de código aberto para workloads que exigem armazenamento de alto desempenho e recursos que incluem snapshots de dados instantâneos, criptografia e clonagem. O armazenamento do OpenZFS é acessível usando o NFS e permite a migração fácil de servidores de arquivos do Linux para a nuvem para uso com contêineres de aplicações .NET.
  • O Amazon FSx para NetApp ONTAP é outro serviço de armazenamento de arquivos totalmente gerenciado que oferece recursos de acesso e gerenciamento de dados. As aplicações acessam os sistemas de arquivos NetAPP ONTAP usando os protocolos NFS, SMB e iSCSI.

Introdução ao AWS Fargate

Uma abordagem com tecnologia sem servidor para provisionar e gerenciar a infraestrutura de nuvem é atraente para muitos desenvolvedores e organizações. Com a tecnologia sem servidor, a AWS lida com o provisionamento e o gerenciamento indiferenciados dos recursos de infraestrutura para hospedar aplicações para você. Isso permite que você, o desenvolvedor, fique mais livre para se concentrar na sua aplicação. Você especifica o que as aplicações precisam para serem executadas e escalonadas. O “como” é de responsabilidade da AWS.

O AWS Fargate é uma abordagem com tecnologia sem servidor para hospedar contêineres na nuvem. Quando você escolhe o Fargate para aplicações baseadas no Amazon ECS ou Amazon EKS, não é mais necessário gerenciar servidores ou clusters de instâncias do Amazon EC2 para hospedar aplicações baseadas em contêineres. O Fargate lida com o provisionamento, a configuração e o aumento e a redução da escala vertical da infraestrutura de contêineres, conforme necessário.

Como desenvolvedor, você se preocupa em definir a criação de suas imagens de contêiner usando um Dockerfile e a implantação dessas imagens criadas no Amazon ECR ou no Docker Hub. Para a infraestrutura de runtime das aplicações, basta especificar o sistema operacional, a CPU e a memória, a rede e as políticas do IAM. Em seguida, o Fargate provisiona e escalona a infraestrutura de contêineres de acordo com esses requisitos. O Fargate é compatível com a execução de aplicações .NET e .NET Framework como serviços, tarefas e tarefas programadas.

Os desenvolvedores de .NET que desejam usar o Amazon ECS no AWS Fargate podem escolher entre ambientes Windows Server ou Linux. As aplicações do .NET Framework devem usar contêineres do Windows Server. No entanto, aplicações criadas com o .NET têm a opção de ambientes Windows Server ou Linux.

Observação: para aplicações que usam uma combinação de contêineres do Windows Server e do Linux, são necessárias tarefas separadas para os diferentes ambientes.

.NET em contêineres do Linux no AWS Fargate

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.

.NET em contêineres do Windows no AWS Fargate

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.

Como escolher entre o Amazon ECS e o Amazon ECS no AWS Fargate

Use as seguintes informações para determinar se você deve escolher o Amazon ECS ou o Amazon ECS no AWS Fargate para hospedar suas aplicações .NET:

  • Se você preferir provisionar, gerenciar e escalar clusters e outras infraestruturas para hospedar suas tarefas, ou se precisar autogerenciar essa infraestrutura, escolha o Amazon ECS.
  • Se você preferir permitir que a AWS provisione, gerencie e escale a infraestrutura que comporta suas aplicações em contêineres, escolha o AWS Fargate. O AWS Fargate é compatível com contêineres do Windows para aplicações .NET Framework ou .NET, ou contêineres do Linux para aplicações .NET.
  • Para aplicações .NET que usam o Amazon FSx para Windows File Server para fornecer volumes adicionais de armazenamento persistente aos seus contêineres, escolha o Amazon ECS. O AWS Fargate não era compatível com essa opção de armazenamento no momento da escrita deste artigo.

Imagens de contêineres e o Amazon Elastic Container Registry (Amazon ECR)

O Amazon ECR é um registro de contêineres totalmente gerenciado, seguro e escalável para imagens de contêineres do Docker e da Open Container Initiative (OCI). Seus recursos facilitam o armazenamento, o gerenciamento e a implantação de imagens de contêineres, independentemente de você estar usando o Amazon ECS ou o Amazon ECS no AWS Fargate. Por ser um serviço totalmente gerenciado, o Amazon ECR fornece, gerencia e escala a infraestrutura necessária para comportar seus registros.

Observação: você também pode usar o Docker Hub para armazenar suas imagens de contêineres ao trabalhar com o Amazon ECS e o AWS Fargate.

O Amazon ECR fornece a cada conta um registro privado padrão em cada região da AWS. O registro é usado para gerenciar um ou mais repositórios privados que contêm imagens de contêineres. Antes de as imagens serem inseridas em, ou extraídas de, um repositório, os clientes devem obter um token de autorização que é usado para autenticar o acesso a um registro. À medida que as imagens são inseridas nos repositórios, o Amazon ECR fornece uma verificação automatizada de vulnerabilidades como um recurso opcional. Os repositórios também são compatíveis com a criptografia por meio do AWS Key Management Service (KMS), com a opção de usar uma chave fornecida pela AWS ou uma chave personalizada e gerenciada pelo usuário.

Para controlar o acesso, o Amazon ECR se integra ao AWS IAM. As permissões refinadas baseadas em recursos permitem o controle de quem (ou o que) pode acessar imagens de contêineres e repositórios. Políticas gerenciadas, fornecidas pelo Amazon ECR, também estão disponíveis para controlar níveis variados de acesso.

Ao usar uma configuração por registro, os repositórios podem ser replicados entre regiões e outras contas. As políticas adicionais de ciclo de vida da imagem também são configuráveis. Por exemplo, você pode configurar (e testar) uma política de ciclo de vida que resulta na limpeza de imagens não utilizadas em um repositório.

Registros públicos e privados estão disponíveis no Amazon ECR. Um cache de pull-through, para imagens de contêineres extraídas de outros registros públicos, também está disponível. Os caches de pull-through isolam as compilações e implantações de interrupções em registros upstream e repositórios, além de ajudar as equipes de desenvolvimento sujeitas à auditoria de conformidade para dependências.

Analise os recursos abaixo para saber mais sobre os registros públicos e privados no Amazon ECR, os repositórios que eles contêm e os repositórios de cache de pull-through.

Registro privado e repositórios

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.

Repositórios e registros públicos

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.

Repositórios de cache de pull-through

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.

Inserção e extração de imagens

As contas têm acesso de leitura e gravação aos repositórios em seus registros privados e públicos por padrão. No entanto, as entidades principais do IAM dentro dessas contas e as ferramentas executadas no escopo dessas entidades principais do IAM devem obter permissões para usar os comandos de inserção e extração e a API do Amazon ECR. Essas permissões são fornecidas como um token de autorização, que deve ser fornecido ao autenticar o acesso a um registro público ou privado do Amazon ECR.

Observação: embora as entidades principais do IAM precisem de permissões para inserir e extrair imagens de repositórios privados e inserir imagens em repositórios públicos, qualquer pessoa pode extrair imagens de repositórios públicos no registro público de uma conta sem autenticação, o que é chamado de extração não autenticada.

Autorização de acesso ao repositório na linha de comando

Muitas das ferramentas da AWS mencionadas no módulo 2 deste curso serão responsáveis por obter o token para você e usá-lo para autenticação no seu registro privado, mas você mesmo pode executar as mesmas etapas, se necessário, por exemplo, ao acessar um registro de um pipeline de CI/CD. Como alternativa, um assistente de credenciais do Amazon ECR está disponível no GitHub. Consulte o assistente de credenciais do Amazon ECR Docker para obter mais detalhes (este curso não aborda o uso do assistente).

A AWS CLI e as ferramentas da AWS para PowerShell contêm comandos para obter facilmente um token de autorização, que é por sua vez usado com ferramentas como o Docker Client para inserir e extrair imagens. Ambos os comandos processam a saída do serviço e emitem o token necessário. Para cenários em que o uso da linha de comando não é adequado ou para ferramentas personalizadas, uma chamada da API GetAuthorizationToken do Amazon ECR está disponível.

Observação: as permissões no token de autorização não excedem as permissões fornecidas à entidade principal do IAM que o solicita. O token é válido por 12 horas.

Para autenticar o Docker com um registro do Amazon ECR usando a AWS CLI, use o comando get-login-password e envie a saída para o login do Docker, especificando a AWS como o nome de usuário e o URL do registro:

aws ecr get-login-password --region region | docker login --username AWS --password-stdin aws_account_id.dkr.ecr.region.amazonaws.com

Para usar as ferramentas da AWS para PowerShell para autenticar um cliente do Docker, use Get-ECRLoginCommand (disponível no módulo AWS.Tools.ECR ou nos módulos herdados AWSPowerShell e AWSPowerShell.NetCore). Envie a propriedade Password no objeto de saída para o comando de login do Docker, especificando a AWS como o nome de usuário e o URL do registro:

(Get-ECRLoginCommand -Region region).Password | docker login --username AWS --password-stdin aws_account_id.dkr.ecr.region.amazonaws.com

Depois que o cliente do Docker obtém autorização, as imagens podem ser inseridas ou extraídas de repositórios no registro. Observe que são necessários tokens de autorização separados para registros em regiões diferentes.

Inserção de uma imagem

As permissões do IAM são necessárias para inserir imagens em repositórios públicos e privados. Como prática recomendada, considere restringir o escopo das permissões das entidades principais do IAM a repositórios específicos. O exemplo de política abaixo mostra as operações da API do Amazon ECR (“Ação”) exigidas por uma entidade principal para inserir imagens, com escopo para um repositório específico. Quando os repositórios são especificados, o nome do recurso da Amazon (ARN) é usado para identificá-los. Observe que vários repositórios podem ser especificados (em um elemento de matriz), ou use um curinga (*) para ampliar o escopo para todos os seus repositórios.

Para usar a política abaixo, substitua 111122223333 pelo ID da sua conta da AWS, region pela região em que o repositório existe e defina o nome do repositório.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecr:CompleteLayerUpload",
        "ecr:GetAuthorizationToken",
        "ecr:UploadLayerPart",
        "ecr:InitiateLayerUpload",
        "ecr:BatchCheckLayerAvailability",
        "ecr:PutImage"
      ],
      "Resource":
          "arn:aws:ecr:region:111122223333:repository/repository-name"
    }
  ]
}

Com uma política do IAM semelhante à mencionada acima em vigor e depois de se autenticar no seu registro, você pode enviar imagens usando a CLI do Docker ou outras ferramentas. Antes de inserir uma imagem em um repositório, ela deve ser marcada com o nome do registro, do repositório e da tag de imagem opcional (se o nome da tag de imagem for omitido, o mais recente será assumido). O exemplo a seguir ilustra o formato da tag e o comando para marcar uma imagem local antes de enviá-la para o Amazon ECR.

Substitua 111122223333 pelo ID da sua conta da AWS, region pelo identificador da região que contém o repositório (us-east-1, us-west-2 etc.) e repository-name pelo nome real do repositório.

docker tag ab12345ef 111122223333.dkr.ecr.region.amazonaws.com/repository-name:tag

Por fim, insira a imagem:

docker push 111122223333.dkr.ecr.region.amazonaws.com/repository-name:tag

Extração de uma imagem

As imagens são extraídas usando o mesmo formato de tag para identificar a imagem que foi usada quando a imagem foi inserida:

docker pull 111122223333.dkr.ecr.region.amazonaws.com/repository-name:tag

Para repositórios no seu registro privado, você deve autenticar seu cliente com o registro, conforme descrito anteriormente, antes de extrair a imagem. Para registros públicos, você pode extrair imagens com ou sem autenticação.

Verificação de conhecimento

Você concluiu o Módulo 1, uma introdução ao Amazon ECS e ao AWS Fargate. O teste a seguir permitirá que você verifique o que você aprendeu até agora.

Pergunta 1: o que é o Amazon Elastic Container Registry?

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

Pergunta 2: as opções de armazenamento persistente são as mesmas para contêineres do Windows/Linux em execução no Amazon ECS?

a. Verdadeiro

b. Falso

Pergunta 3: em relação ao ECS, o que é um cluster?

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

Conclusão

Neste módulo, você aprendeu primeiro sobre contêineres: como eles diferem das máquinas virtuais e contêineres Docker do Linux vs. contêineres do Windows. Eles são leves, padronizados e portáteis, fáceis de movimentar, permitem que você envie mais rapidamente e podem economizar dinheiro. Os contêineres na AWS são seguros, confiáveis e são compatíveis com uma variedade de serviços de contêineres, e são profundamente integrados à AWS.

Em seguida, você aprendeu sobre tecnologias sem servidor, que permitem que você crie aplicações sem ter que pensar em servidores. Os benefícios incluem a eliminação da sobrecarga operacional, o ajuste de escala automático, a redução de custos e a criação de aplicações com mais facilidade por meio de integrações incorporadas a outros serviços da AWS. Os casos de uso são aplicações da Web, processamento de dados em lote e ingestão de eventos.

Você aprendeu sobre os serviços de computação da AWS para contêineres e como escolher um serviço de computação. Você aprendeu que o AWS App Runner é um serviço totalmente gerenciado para hospedar contêineres também sem servidor.

Esta página foi útil?

Ferramentas para desenvolvedores de contêineres .NET na AWS