O blog da AWS
Explorando as 5 principais funcionalidades do Amazon Elastic Container Registry (Amazon ECR).
Por Gerson Itiro Hidaka, Enterprise Solution Architect na AWS e
Ricardo Tasso, Partner Solutions Architect na AWS
O Amazon Elastic Container Registry (Amazon ECR) é o repositório de imagens de container totalmente gerenciado, que oferece hospedagem de alta performance para que você possa armazenar as imagens de forma segura e confiável.
Figura 1 – Amazon ECR
O Amazon ECR foi construído, inicialmente, para atender a demanda de repositórios privados com permissões granulares integrados ao AWS Identity and Access Management (IAM) e com funcionalidades de criptografia de dados em repouso integrado ao AWS Key Management Service (AWS KMS). Com o passar do tempo, o Amazon ECR ganhou uma versão pública que permite hospedar imagens de containers para que qualquer pessoa (com ou sem uma conta da AWS) procure e copie esse artefato.
Neste AWS Blog Post vamos explorar as 5 principais funcionalidade do Amazon ECR Privado e como essas funcionalidades podem te ajudar na construção da sua próxima aplicação.
-
Política de Ciclo de Vida (Lifecycle Policy)
Controlar o ciclo de vida de uma única imagem de container é algo simples, mas em cenário onde temos centenas ou milhares de imagens esse controle pode se tornar uma tarefa muito complexa. A Lifecycle Policy do Amazon ECR é uma forma automatizada de controle do ciclo de vida das imagens de container em um repositório privado. Através de regras, os desenvolvedores e administradores das aplicações, criam automações como a limpeza de imagens não utilizadas, expiração das imagens com base na idade (tempo de armazenamento) ou mesmo a expiração das imagens com base na contagem.
Uma Lifecycle Policy consiste em uma ou mais regras que determinam quais imagens em um repositório devem expirar. Ao considerar o uso de Lifecycle Policy, é importante usar a visualização para confirmar quais imagens a política expira antes de aplicá-la a um repositório. Depois que uma Lifecycle Policy é aplicada a um repositório você deve esperar que as imagens, que estão sujeitas as regras, expirem em 24 horas. O diagrama a seguir mostra o fluxo de trabalho da Lifecycle Policy.
Figura 2 – Workflow da Lifecycle Policy
-
Replicação entre Regiões
A replicação automática de imagens de containers entre regiões (Cross Region Replication – CRR) no Amazon ECR foi um recurso bastante soliticado pelos clientes que, ao se depararem com um cenário de disaster recovery ou mesmo com um cenário de equipes dispersas geograficamente, implementavam a replicação por conta própria, utilizando recursos como o AWS Lambda por exemplo.
A replicação é configurada no nível de registro privado do Amazon ECR. Isso significa que, ao ativá-lo, todos os repositórios privados do registry do Amazon ECR copiam automaticamente as imagens para outros repositórios, em diferentes contas e/ou regiões, reduzindo a latência que faz com que seus containers sejam inicializados mais rapidamente, já que agora podem extrair imagens na mesma região.
Imagens em diferentes regiões também ajudam a cumprir os requisitos de recuperação de desastres, pois os artefatos estão dispersos geograficamente. Para começar a utilizá-la, basta habilitar a replicação, escolher as contas e regiões de destino para as quais deseja que o Amazon ECR copie as imagens. Depois disso, sempre que você enviar uma imagem para o repositório privado, o Amazon ECR replicará automaticamente a imagem. Se o repositório ainda não existir na região de destino, o CRR criará, automaticamente, o novo repositório. Se você replicar entre contas, sua conta de destino deve primeiro conceder as permissões necessárias à conta de origem.
Figura 3 – Replicação entre as regiões
-
Imagens Multi Arquitetura
Um dos principais benefícios da tecnologia dos containers é a portabilidade, ou seja, a capacidade de execução do mesmo em diferentes servidores/instâncias. No entanto há limitações neste benefício. Alguns aplicativos têm requisitos específicos como por exemplo o sistema operacional (Linux vs Windows) e a arquitetura do processador (Intel/AMD vs AWS Graviton). Com o anúncio da funcionalidade de multi arquitetura no ECR, podemos construir imagens com arquiteturas diferentes (x86, ARM64, etc) e armazená-las facilmente no serviço.
Figura 4 – Multi Architecture
-
Pull Through Cache
Lançado em 29 de novembro de 2021, o Pull Through Cache do Amazon ECR melhora o desempenho, segurança e disponibilidade para repositórios públicos de imagens.
As empresas utilizam registradores públicos de imagem para construir ou complementar suas aplicações em containers. Utilizando os repositórios do Amazon ECR Pull Through Cache não é necessária nenhuma outra solução ou ferramenta para gerenciar.
Utilizando o Pull Through Cache, clientes podem fazer cache de imagens publicas no Amazon ECR e contar com todos os benefícios do Amazon ECR sem precisar realizar nenhum trabalho para sincronizar as imagens públicas para o repositório.
Com os repositórios Pull through cache contamos com benefícios como utilizar o AWS PrivateLink para manter todo o trafego de rede privado, escanear as imagens em busca de vulnerabilidades com o Image Scanning, fazer a criptografia com chaves do AWS Key Management Service (KMS), fazer a replicação para outras regiões, e utilizar lifecycle policies.
Além disso quando são feitos os pulls das imagens em cache através do Amazon ECR, o Amazon ECR checa o repositório de origem para verificar se houveram atualizações nas imagens. E como o container é criado utilizando a imagem em cache no Amazon ECR, o pull da imagem é inicializado por um endereço IP da AWS, fazendo com que não sejam excedidas as cotas que o registry publico tem.
Após habilitada e criada a regra de Pull Through Cache basta referenciar a imagem utilizando o namespace na URL de pull, se a imagem não estiver em cache, será feito o pull do repositório de origem e a imagem ficará disponível em um repositório do ECR.
Figura 5 – Pull Through Cache
-
Escaneamento de Imagens
O Image Scanning do Amazon ECR é um recurso criado para listar as possíveis vulnerabilidades das imagens de container. Ao utilizar o Image Scanning, as imagens de container são examinadas para detectar uma ampla variedade de vulnerabilidades e exposições mais comuns (CVEs – Common Vulnerabilities and Exposures) no seu conteúdo. Há a opção de analisar também as vulnerabilidades no pacote de linguagem de programação quando escolhemos o tipo de verificação avançado.
Você pode habilitar o Image Scanning para imagens já existentes no seu repositório Amazon ECR e para novas imagens ao fazer o envio para o repositório, garantindo que suas imagens sejam verificadas automaticamente. A verificação automática de imagens pode ajuda-lo para que em sua pipeline a detecção e as respostas a vulnerabilidades sejam realizadas antes de promove-las para o ambiente de produção.
Há dois tipos de verificações oferecidos:
Verificação básica: Neste tipo, o Amazon ECR utiliza o banco de dados de CVEs do projeto de código aberto Clair para examinar as vulnerabilidades das imagens de container. Com a verificação básica podem ser configuradas verificações durante o envio das imagens para o repositório ou executar verificações manuais. Cada imagem do container pode ser verificada uma vez a cada 24 horas. Na verificação básica você pode configurar a execução da análise com filtros de envio para especificar quais repositórios vão fazer a verificação de vulnerabilidades quando novas imagens forem enviadas. Se o repositório não corresponder a um filtro de verificação no envio, você precisará acionar manualmente a verificação.
Verificação avançada: Neste tipo, o Amazon ECR se integra ao Amazon Inspector para realizar verificações automatizadas e contínuas dos seus repositórios. Essas verificações são realizadas para vulnerabilidades no sistema operacional e para o pacote de linguagem de programação e à medida em que novas vulnerabilidades aparecem, os resultados das verificações são atualizados e o Amazon Inspector emite um evento para o Amazon EventBridge notificar você. É necessário fornecer permissões do IAM para que o Amazon ECR tenha acesso para fazer chamadas API do Amazon Inspector para que a verificação avançada ocorra com sucesso e para que o Amazon ECR tenha acesso para enviar eventos para o EventBridge.
Conclusão
Neste Blog Post, exploramos as 5 principais funcionalidades do serviço Amazon ECR. Entender cada uma delas é primordial para que você possa montar uma arquitetura robusta, segura e de baixo custo. Para maiores detalhes técnicos sobre as 5 funcionalidades, deixamos o link de cada um deles na sessão de Referências e Materiais Adicionais.
Convido você a nos enviar perguntas, comentários e feedback usando os links e formulários abaixo. Até nosso próximo Blog Post!
Referências e Materiais Adicionais
- Amazon ECR Pull Through Cahe.
- Lançamento: 29 de novembro de 2021.
- https://aws.amazon.com/blogs/aws/announcing-pull-through-cache-repositories-for-amazon-elastic-container-registry/
- Amazon ECR Cross Region Replication.
- Lançamento: 08 de dezembro de 2020.
- https://aws.amazon.com/blogs/containers/cross-region-replication-in-amazon-ecr-has-landed/
- Amazon ECR Multi Architecture.
- Lançamento: 01 de maio de 2020.
- https://aws.amazon.com/blogs/containers/introducing-multi-architecture-container-images-for-amazon-ecr/
- Amazon ECR Image Scanning
- Lançamento: 28 de outubro de 2019.
- https://aws.amazon.com/about-aws/whats-new/2019/10/announcing-image-scanning-for-amazon-ecr/
- https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html
Amazon Inspector for vulnerability management.
- Lançamento: 29 de novembro de 2021.
- https://aws.amazon.com/about-aws/whats-new/2021/11/amazon-inspector-continual-vulnerability-management/
- Amazon ECR Lifecycle Policy.
- Lançamento: 11 de Outubro de 2017.
- https://docs.aws.amazon.com/AmazonECR/latest/userguide/LifecyclePolicies.html
- Lançamento da funcionalidade
- Como funciona o Lifecycle Policy
- Como criar uma Lifecycle Policy
- Exemplos de regras
Sobre os autores
Gerson Itiro Hidaka atualmente trabalha como Enterprise Solution Architect na AWS e atua no atendimento a clientes na área de Mid-Enterprise no Brasil. Entusiasta de tecnologias como Internet das Coisas (IoT), Drones, Devops e especialista em tecnologias como virtualização, serverless, container e Kubernetes. Trabalha com soluções de TI a mais de 25 anos, tendo experiência em inúmeros projetos de otimização de infraestrutura, redes, migração, disaster recovery e DevOps em seu portifólio.
Ricardo Tasso atualmente trabalha como Partner Solutions Architect na AWS e atua junto aos parceiros AWS ajudando na jornada de parceria com a AWS e a entregar a melhor solução aos clientes. Trabalha com Administração de Sistemas e Soluções de TI há mais de 15 anos, com experiência em redes, storage, Sistemas Operacionais, filas e messaging, sendo que nos últimos anos teve maior proximidade com a cultura DevOps, e tecnologias como serverless, containers, Infra como Código, CI/CD, além de arquitetura e modernização de aplicações.
Revisor(es)
Daniel Abib é Enterprise Solution Architect na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, Serverless e segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem.
João Helena Filho atualmente trabalha como Partner Solutions Architect na AWS, com 20 anos de experiência em TI trabalhando na entrega e desenvolvimento de soluções em inúmeros projetos de virtualização, otimização de infraestrutura, colaboração e soluções baseadas em Microsoft. Atua junto aos parceiros AWS na habilitação e criação de estratégias para melhoria contínua na entrega aos clientes. Em seu tempo livre João dedica parte do seu tempo ao antigomobilismo e à música.