O blog da AWS
Executando containers multi-arquitetura com o Amazon EKS
Por Lucas Duarte, Solutions Architect, WWPS Brazil,
Vinicius Silva, Solutions Architect, WWPS Brazil e
Ernesto dos Santos, Solutions Architect, WWPS Brazil
Clientes tem buscado utilizar arquiteturas mistas para otimizar custos ou melhorar a relação preço e performance, podemos citar por exemplo um dos pilares do Well-Architected Framework em relação a performance, a capacidade de utilizar recursos de computação de forma eficiente para atender aos requisitos do sistema e manter essa eficiência conforme a demanda muda e as tecnologias evoluem.
Os processadores AWS Graviton são personalizados pela Amazon Web Services, usando núcleos ARM Neoverse de 64 bits para oferecer o melhor custo para suas cargas de trabalho de nuvem em execução no Amazon EC2.
Diversas perguntas surgiram após o lançamento do AWS Graviton2 no AWS re:Invent 2020, como:
- Podemos executar qualquer aplicação em processadores com arquitetura ARM?
- O que precisamos modificar em nossa aplicação para que ela consiga ser executada em processadores ARM?
- Quais benefícios podemos ter utilizando AWS Graviton2 em comparação com AMD ou Intel?
Instâncias EC2 baseadas no AWS Graviton2 oferecem uma performance até 40% superior, com custos até 20% melhores, se comparado com instâncias que também podem ser encontradas na versão Intel ou AMD. Dessa forma os processadores AWS Graviton2 adicionam ainda mais opções para ajudar os clientes a otimizar o desempenho e os custos de suas cargas de trabalho.
Nesse blog post iremos mostrar como criar uma imagem Docker que suporta uso de multi-arquitetura (x86 e ARM), com pouca ou quase nenhuma modificação no código fonte da aplicação, efetuando o deploy desta imagem em um cluster de Amazon EKS.
E o que são imagens multi-arquitetura?
Usualmente quando criamos uma imagem Docker, nos baseamos em uma arquitetura específica de processadores, mas existe uma maneira que nos permite criar uma imagem que possa contemplar múltiplas arquiteturas de processadores.
Estamos aqui falando da funcionalidade “docker manifest“.
Para construir uma imagem Docker que consegue ser executada em arquiteturas ARM na maioria das vezes não necessitamos modificar o código de nossa aplicação, basta construí-la em uma instância com arquitetura de processador ARM.
O AWS CodeBuild suporta nativamente a utilização tanto de instâncias Intel/AMD, assim como de instâncias ARM para a construção (build) de imagens Docker. Desta maneira as imagens que são construídas para suportar ARM são executadas em instâncias com arquitetura ARM, e as construídas para suportar x86 (Intel/AMD) são executadas em instâncias com arquitetura x86.
No console do AWS CodeBuild, é possível selecionar a arquitetura de processador da instância que será utilizada para o build da imagem Docker.
Figura 1: Escolha da imagem no console do AWS CodeBuild
E como vou saber qual imagem escolher no momento de executar minha aplicação?
No exemplo que trouxemos, construímos uma imagem para duas arquiteturas: x86 e ARM. Cada uma das imagens construídas possui uma URI, e essa URI precisa ser informada no manifesto de deployment baseada na arquitetura do node.
Para endereçar esse detalhe, o Amazon ECR suporta o armazenamento de imagens multi-arquitetura, criadas via Docker Manifest.
Idealmente, uma lista de manifesto é criada a partir de imagens que são idênticas em função, para diferentes combinações de sistemas operacionais e/ou arquitetura.
Por este motivo, as listas de manifesto são frequentemente chamadas de “imagens de múltiplas arquiteturas”.
No entanto, um usuário pode criar uma lista de manifesto que aponte para duas imagens, por exemplo: uma para Windows em AMD64, e outra para Darwin em AMD64.
A Arquitetura do Cluster Amazon EKS
Em nossa demonstração, utilizaremos um cluster do Amazon EKS com dois Managed Nodegroups distintos, um deles utilizando x86 como arquitetura, e o outro utilizando ARM.
Iremos utilizar a imagem Docker multi-arquitetura construída, para executar a aplicação em nosso cluster utilizando a mesma URI para ambos os nodes, sem precisar alterar o manifesto de deploy, pois o Amazon EKS irá identificar qual a arquitetura da imagem e executá-la no node correto.
Figura 2: Arquitetura do cluster Amazon EKS utilizado na demostração.
Ao executarmos o comando abaixo, podemos ver que para cada um dos nodes do nosso cluster temos uma label de arquitetura específica.
~> kubectl get nodes --show-labels
O funcionamento ocorre dessa forma devido ao mecanismo de labels do Kubernetes, onde o label kubernetes.io/arch identifica a arquitetura da instância onde o agente do kubernetes é executado, colocando o POD correto do Node com a arquitetura adequada.
A pipeline para criar as imagens multi-arquitetura
Em nossa demonstração desenvolvemos uma pipeline para criar imagens multi-arquitetura utilizando serviços AWS como o AWS CodePipeline e o AWS CodeBuild. Utilizamos o GitHub para hospedar nossos arquivos, que serão utilizados pelo AWS CloudFormation e pelo AWS CodeBuild para, respectivamente, provisionamento da stack necessária e o build das imagens Dockers compatíveis com cada arquitetura de processador (x86 e ARM).
O AWS CodePipeline é responsável por automatizar as fases de: compilação, teste e implantação do processo de liberação sempre que ocorre uma mudança no código, de acordo com o modelo de liberação que você definiu. Você pode integrar facilmente o AWS CodePipeline com serviços de terceiros como o próprio GitHub.
Em nosso pipeline do AWS CodePipeline definimos estágios, que são unidades lógicas que você pode usar para isolar um ambiente e limitar o número de mudanças simultâneas nesse ambiente. Cada estágio contém ações que são executadas nos artefatos do aplicativo e é composto de uma série de ações seriais ou paralelas.
Para o nosso caso, definimos três estágios: o primeiro estágio Source responsável por identificar mudanças no repositório do GitHub e, caso alguma mudança aconteça, iniciar a pipeline. O segundo estágio Build possui duas ações sendo executadas em paralelo, sendo uma para a criação de uma imagem Docker compatível com a arquitetura ARM, e a outra para a criação de uma outra imagem compatível com arquiteturas x86. O terceiro estágio BuildManifest cria uma imagem Docker, que é resultado da união das duas imagens construídas no segundo estágio de Build. Esta imagem será utilizada pelo nosso cluster do Amazon EKS para o suporte à multi-arquitetura.
Segue abaixo um desenho da arquitetura proposta para o que foi mencionado acima:
Figura 3: Arquitetura do pipeline de construção das imagens Docker
Implantando a Solução
Para que você possa experimentar este cenário na prática, criamos um repositório no Github com os detalhes técnicos da implantação desta Pipeline. Você encontrará o repositório neste link.
Conclusão
Neste blogpost mostramos, de forma simples, como é possível construir e utilizar imagens de containers em multiplas arquiteturas, desde o build até o deploy, no caso em um cluster Kubernetes gerenciado pelo Amazon EKS.
As imagens de Container que rodam em instâncias do Graviton 2 apresentam uma economia e um desempenho superior de performance se comparado com instâncias de mesma configuração x86, assim podemos utilizar desse novo lançamento para otimizar os nossos workloads executados em um cluster Kubernetes.
Sobre os autores
Lucas Duarte, é Arquiteto de Soluções na AWS. Atua com clientes do setor público, é entusiasta de automação, Cloud, e cultura DevOps. Com experiência prévia em projetos focados nesse segmento em empresas como IFood, Guiabolso e Mandic. Tem trabalhado em diferentes projetos relacionados principalmente a orquestração de containers e microsserviços.
Vinicius Silva é Arquiteto de Soluções na AWS. Apoia clientes do setor de educação, governo, organizações sem fins lucrativo e saúde a atingirem seus objetivos com a nuvem da AWS. Interessado em desenvolvimento e na cultura DevOps, possui contribuições anteriores no desenvolvimento de plataformas web distribuídas e escaláveis.
Ernesto dos Santos é Arquiteto de Soluções na AWS. Atua auxiliando eapoiando clientes do setor público em sua jornada para a nuvem AWS, trabalhando em projetos que envolvam arquiteturas distribuídas e escaláveis. Tem grande interesse na área de segurança da informação, infraestrutura, networking e serverless.
Referências: