O blog da AWS
Utilizando runtimes customizados no Amazon ECS
Vinicius Schettino, Engenheiro DevOps, Passei Direto
Rodrigo Martins, Engenheiro DevOps, Passei Direto
Gabriel Bella Martini, Arquiteto de Soluções, AWS Brasil Setor Público
Thiago Pádua, Arquiteto de Soluções, AWS Brasil Setor Público
A PasseiDireto criou uma solução para executores self-hosted do GitHub Actions com o Amazon ECS, fornecendo aos times de engenharia uma plataforma escalável e dinâmica para a execução de centenas de workflows de CI/CD. Contudo, com a crescente adoção da proposta, o modelo Docker-in-a-Docker (DinD) escolhido apresentou algumas limitações durante a execução de dezenas de tarefas em paralelo. Essa limitação era esperada pela abordagem de compartilhar o socket de comunicação Docker entre os containers, com a opção privileged. Para aumentar a segurança e a confiabilidade da solução apresentada, foi disponibilizado o sysbox no cluster Amazon ECS, um runtime Docker alternativo que fornece maior isolamento entre os containers. Através de uma AMI personalizada, as instâncias do cluster podem suportar dezenas de executores autocontidos, cada um com sua instalação Docker independente e prontos para desempenhar todas as funções do GitHub Actions sem interferência externa.
Problemas encontrados
Antes do modelo paralelo, para executar diferentes tipos de testes no código de uma aplicação, era necessário criar um executor e instanciar cada um dos testes dentro de uma mesma tarefa, com etapas sequenciais:
Esse processo tem algumas limitações. Primeiro, o funcionamento sequencial aumenta o tempo de build consideravelmente, especialmente quando existem várias etapas custosas que poderiam ser paralelizadas. Segundo, não é possível usar o construtor matrix do GitHub Actions para lançar várias tarefas parecidas em instâncias diferentes (como por exemplo testes em várias versões do Node ou do Python, como iremos mostrar no final desse artigo). Assim, o objetivo era permitir a execução do seguinte fluxo utilizando os executores self-hosted escaláveis no ECS:
O fluxo acima, apesar de funcionar bem em condições de teste ou com poucas etapas, encontrou problemas na execução em escala. Essa situação começa a emergir com dezenas de usuários ou até mesmo com workflows contendo diversas tarefas em paralelo, como exemplificado na imagem:
Em situações como essa, tarefas começam a falhar aleatoriamente, por falta de disponibilidade do socket de comunicação docker:
Nas próximas seções são detalhados os principais desafios com a abordagem até então utilizada e como é possível utilizar recursos do ECS, AMIs e o EC2 Image Builder para permitir mais escalabilidade e performance nas builds paralelas com o GitHub Actions utilizando executores self-hosted.
Visão geral da solução
Ao criar um cluster ECS, o usuário pode escolher entre dois tipos de recursos computacionais para hospedar tarefas e serviços: instâncias Amazon EC2 ou AWS Fargate, sendo esse último um serviço para containers serverless. As instâncias EC2 contém uma instalação Docker e um ECS Agent, que é um container responsável pela comunicação com o cluster, atribuição de tarefas e controle dos recursos disponíveis. O Docker precisa de um ambiente de runtime, responsável por executar os containers e isolar os recursos necessários de acordo com a especificação da imagem e do usuário. O runtime padrão do Docker é o runC, compatível com o padrão da Open Container Initiative (OCI) e referência para sua definição original. Apesar da sua popularidade e versatilidade, o runC não oferece um isolamento suficiente para execução de containers dentro de containers de forma segura e escalável, abordagem essencial para executores self-hosted do GitHub Actions com todas as funcionalidades utilizando containers. A única abordagem viável requer duas configurações arriscadas: a utilização da configuração privileged durante a execução, que dá ao container poderes administrativos também no hospedeiro e o compartilhamento do caminho /var/lib/docker em vários containers ao mesmo tempo. Além de insegura, essa abordagem não escala bem quando vários containers são disparados em paralelo:
“This means that if you share your /var/lib/docker directory between multiple Docker instances, you’re gonna have a bad time. Of course, it might work, especially during early testing. “Look ma, I can docker run ubuntu!” But try to do something more involved (pull the same image from two different instances…) and watch the world burn.” — Jérôme Petazzoni
Com isso, foi necessário buscar uma solução de runtime que permitisse maior isolamento, incluindo o uso de containers dentro de containers sem efeitos colaterais de segurança e impacto na performance/confiabilidade da plataforma. Essa é a proposta do sysbox, que proporciona um ambiente com funcionalidades de isolamento parecidas com máquinas virtuais, com maior separação de recursos e compatibilidade a OCI e, consequentemente, com o runC. Além disso é possível observar maior desempenho na solução quando existe a necessidade de aninhamento de containers, substituindo o mapeamento de volumes padrão do Docker por alternativas mais modernas.
Contudo, o ECS ainda não suporta configurações personalizadas de runtime. Ou seja, não existe uma configuração a nível de Task Definition, Cluster ou Capacity Provider para que o usuário possa escolher diferentes runtimes arbitrariamente de acordo com o perfil das tarefas que precisam ser executadas. A alternativa é criar uma imagem de máquina (AMI) com o sysbox disponível, além das configurações padrão do ECS, como detalhado na imagem:
Apesar de ser possível realizar mudanças nas instâncias EC2 dentro de um cluster ECS a partir das configurações de inicialização, a instalação do sysbox é relativamente demorada e aumentaria o tempo de inicialização dos clusters nos eventos de escalabilidade. Com a abordagem de uma AMI personalizada é possível manter o tempo de inicialização muito próximo da configuração padrão, uma vez que todo o processo de instalação do sysbox e suas dependências ocorre durante a construção da imagem, processo anterior à disponibilização das instâncias. Na próxima seção, são detalhados os passos para a criação da AMI com o AWS Image Builder.
Criando a AMI com Sysbox
A imagem construída através dos passos detalhados aqui está publicamente disponível nesta AMI e é semanalmente atualizada (etapa que também será explicada). A AWS fornece através do serviço Image Builder uma maneira de construir imagens sob demanda ou de forma agendada. A principal entidade desse serviço é a pipeline que pode ser agendada ou manual.
As pipelines contêm 3 outras entidades que merecem destaque:
- Receita (recipe): define as etapas de instalação e configuração do SO e demais software (onde iremos dar maior enfâse a seguir);
- Configuração de infraestrutura: define o tipo de instância EC2, volumes EBS, configurações de rede, grupo de segurança, logs e mais;
- Distribuição: define se o acesso à AMI será público ou privado, a região de distribuição e o padrão de nomenclatura das versões que vão sendo geradas a cada nova execução da pipeline.
Para se configurar a receita da imagem é necessário escolher uma imagem base, seja as fornecidas pela AWS ou através de um AMI ID personalizado. A escolha foi usar uma imagem Linux Ubuntu 20.04 LTS para compatibilidade com todas as funcionalidades do sysbox.
Além da escolha da imagem base, é preciso adicionar a instalação personalizada de software que é separada em componentes reaproveitáveis. É possível utilizar alguns componentes fornecidos pela própria AWS. Na imagem abaixo é possível ver os componentes da nossa receita.
Exceto pela receita, as demais entidades podem ser configuradas direto da criação de pipeline (imagem da esquerda) e posteriormente podem ser gerenciadas de fora da mesma (imagem da direita).
O principal desafio foi criar o componente que instala o sysbox. Isso porque não há um pacote atualizado disponível via yum, apt-get ou similares, e várias dependências precisam ser manualmente instaladas. A definição do componente é data por um arquivo YAML, conforme a seguir:
name: InstallSysboxECSAgent
description: Install Sysbox and ECS Agent
schemaVersion: 1
phases:
- name: build
steps:
- name: InstallDeps
action: ExecuteBash
inputs:
commands:
- id
- sudo -s
- export TZ=UTC
- apt-get update
- |
apt-get -y install\
apt-transport-https \
ca-certificates \
curl \
gnupg-agent \
wget \
jq \
software-properties-common \
git \
make \
dkms
- name: InstallDocker
action: ExecuteBash
inputs:
commands:
- sudo -s
- >-
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
- >-
add-apt-repository "deb [arch=amd64]
https://download.docker.com/linux/ubuntu $(lsb_release -cs)
stable"
- apt-get update
- apt-get -y install docker-ce docker-ce-cli containerd.io
- usermod -aG docker ubuntu
- name: InstallSysbox
action: ExecuteBash
inputs:
commands:
- sudo -s
- git clone https://github.com/toby63/shiftfs-dkms.git shiftfs-dkms
- cd shiftfs-dkms && make -f Makefile.dkms
- modprobe shiftfs
- lsmod | grep shiftfs
- >-
echo '{"default-runtime": "sysbox-runc", "runtimes": {
"sysbox-runc": { "path": "/usr/local/sbin/sysbox-runc" } } }' | jq
'.' > /etc/docker/daemon.json
- "git config --system url.https://github.com/.insteadOf git@github.com:"
- git clone --recursive git@github.com:nestybox/sysbox.git
- cd sysbox && make sysbox && make install
- service docker restart
- name: InstallECSAgent
action: ExecuteBash
inputs:
commands:
- sudo -s
- >-
sh -c "echo 'net.ipv4.conf.all.route_localnet = 1' >>
/etc/sysctl.conf"
- sysctl -p /etc/sysctl.conf
- >-
echo iptables-persistent iptables-persistent/autosave_v4 boolean
true | debconf-set-selections
- >-
echo iptables-persistent iptables-persistent/autosave_v6 boolean
true | debconf-set-selections
- apt-get -y install iptables-persistent
- >-
iptables -t nat -A PREROUTING -p tcp -d 169.254.170.2 --dport 80
-j DNAT --to-destination 127.0.0.1:51679
- >-
iptables -t nat -A OUTPUT -d 169.254.170.2 -p tcp -m tcp --dport
80 -j REDIRECT --to-ports 51679
- iptables -A INPUT -i eth0 -p tcp --dport 51678 -j DROP
- sh -c 'iptables-save > /etc/iptables/rules.v4'
- mkdir -p /etc/ecs && touch /etc/ecs/ecs.config
- >-
curl -o ecs-agent.tar
https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/ecs-agent-latest.tar
- docker load --input ./ecs-agent.tarAs etapas InstallDeps e InstallDocker são triviais, com a instalação de dependências básicas do sistema e a instalação padrão do Docker. Já no item InstallSysbox, algumas ações importantes são realizadas:
- Instalação do shiftfs, utilizando as recomendações oficiais, módulo do kernel Linux que possibilita criação de sistemas de arquivo virtuais utilizando user namespaces. Essa é a principal tecnologia que dá suporte ao nível de isolamento que o sysbox oferece. A maior parte dos provedores serviços de nuvem não habilita o shiftfs por padrão nos Ubuntus mais novos.
- Configuração do Docker deamon para utilizar o sysbox como runtime padrão através da configuração no arquivo
/etc/docker/daemon.json. Esse passo precisa necessariamente ser executado antes da instalação do sysbox, evitando assim que o processo de instalação solicite interação do usuário para decidir se o sysbox deve ser o runtime padrão, bloqueando o processo totalmente automático. - Compilação e instalação do sysbox, utilizando o guia oficial. O pacote
apt-getdo sysbox é relativamente desatualizado e por isso a opção pela compilação.
Na etapa InstallECSAgent são executados as instruções da configuração do ECS manuais, sem maiores modificações. Como todos os passos acima são executados em tempo de compilação da imagem, algumas configurações rápidas são necessárias durante a inicialização das instâncias, para garantir que o agente de controle do cluster ECS seja corretamente executado utilizando o runtime runC e as configurações recomendadas:
sudo -s
/usr/local/sbin/sysbox
docker restart
echo ECS_CLUSTER=${cluster.clusterName} | tee /etc/ecs/ecs.config
echo ECS_DATADIR=/data | tee -a /etc/ecs/ecs.config
echo ECS_ENABLE_TASK_IAM_ROLE=true | tee -a /etc/ecs/ecs.config
echo ENABLE_TASK_IAM_ROLE_NETWORK_HOST=true | tee -a /etc/ecs/ecs.config
echo ECS_LOGFILE=/log/ecs-agent.log | tee -a /etc/ecs/ecs.config
echo ECS_AVAILABLE_LOGGING_DRIVERS=[\"json-file\",\"awslogs\"] | tee -a /etc/ecs/ecs.config
echo ECS_LOGLEVEL=info | tee -a /etc/ecs/ecs.config
curl -o ecs-agent.tar https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/ecs-agent-latest.tar
docker load --input ./ecs-agent.tar
docker run --name ecs-agent --privileged --detach=true --restart=on-failure:10 --volume=/var/run:/var/run --volume=/var/log/ecs/:/log:Z --volume=/var/lib/ecs/data:/data:Z --volume=/etc/ecs:/etc/ecs --net=host --userns=host --runtime=runc --env-file=/etc/ecs/ecs.config amazon/amazon-ecs-agent:latestOs comandos acima podem ser configurados na configuração de execução das instâncias do grupo de autoscaling.
Implantação de exemplo
É possível ilustrar o funcionamento da solução com worfklows do GitHub Actions que envolvem várias etapas em paralelo. Um exemplo comum nos projetos de software é a execução de testes e verificações estáticas em diferentes versões do Node.js. Nesse caso essa etapa é necessária para aprovação de um Pull Request, garatindo que novas modificações não impactem negativamente usuários em nenhuma das versões suportadas do Node.js. Utilizando a action que inicializa um conjunto de executores self-hosted em um cluster ECS, esse fluxo pode ser descrito na sintaxe do GitHub Actions assim:
jobs:
pre-job:
runs-on: ubuntu-latest
steps:
- uses: aws-actions/configure-aws-credentials@v1
with:
aws-access-key-id: ${{ secrets.AWS_ID }}
aws-secret-access-key: ${{ secrets.AWS_KEY }}
aws-region: ${{ secrets.AWS_REGION }}
- name: Provide a self hosted to execute this job
uses: PasseiDireto/gh-runner-task-action@main
with:
github_pat: ${{ secrets.MY_SECRET_TOKEN }}
task_definition: 'gh-runner'
cluster: 'gh-runner'
task_count: 9 # 3 scripts x 3 versions
test:
needs: pre-job
runs-on: self-hosted
strategy:
matrix:
version: [ 13, 14, 15 ]
script: ["lint", "test-unit -- --coverage=true", "test-integration"]
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
with:
node-version: ${{ matrix.version }}
- name: Perform checks
run: |
npm ci
npm run ${{ matrix.script }}Nesse caso, três tipos de ação (testes unitários, integração e linting) são executados em três versões diferentes do Node.js. Por isso, 9 executores são criados no cluster ECS:
De acordo com os limites do Capacity Provider do cluster, novas instâncias vão sendo criadas para hospedar a nova carga de trabalho. Aos poucos, os novos executores vão sendo absorvidos e começam a processar as tarefas:
Depois de alguns segundos, todos os executores estão processsando as tarefas especificadas na matrix do GitHub:
Com o término das tarefas, o workflow é concluído com sucesso e o Pull Request pode ser aprovado:
Conclusão e próximos passos
O modelo tradicional com workflows sequenciais apresenta vários desafios à Engenharia de Software Contínua e à cultura DevOps, deixando automações mais lentas. A construção de pipelines paralelas diminui o tempo de espera dos desenvolvedores na aprovação dos Pull Requests e no feedback do impacto de suas mudanças do ponto de vista dos usuários. A solução proposta permite reduções significativas no tempo de execução das pipelines, evitando problemas de escala e isolamento do runtime Docker padrão com a introdução do sysbox no cluster ECS através de uma AMI personalizada.
Com a solução atuando durante dois meses, foi possível reunir alguns aspectos passíveis de melhorias nas próximas versões da AMI e da arquitetura como um todo:
- Modelo de atualização automática das instâncias do cluster, garantindo que a versão mais nova da AMI seja sempre utilizada. Essa mudança busca disponibilizar melhorias de performance e segurança automaticamente de acordo com o lançamento semanal de novas versões da AMI.
- Criação de testes para AMIs, garantindo que as novas versões estejam funcionais antes da disponibilização para o público geral.
- Automação da infraestrutura do imagem builder com CDK, utilizando os contrutores equivalentes ao passo a passo apresentando utilizando o console da AWS.
Sobre os autores
Vinícius Schettino é DevOps Engineer na Passei Direto com mais de 10 anos de experiência em engenharia de software. Focado em Data CI/CD, MLOps, qualidade de software e automação.
Rodrigo Martins é DevOps Engineer na Passei Direto com mais de 10 anos de experiência em redes de computadores e arquitetura de software. Focado em melhorias no processo de CI/CD e segurança da informação.
Gabriel Bella Martini é um Arquiteto de Soluções na AWS com foco em clientes de Educação. Tem experiência em diferentes projetos relacionados a Inteligência Artificial e tem grande interesse na área de computação gráfica.
Thiago Pádua é Arquiteto de Soluções na AWS atua com o desenvolvimento e apoio aos parceiros do Setor Público. Trabalhou anteriormente com desenvolvimento de software e integração de sistemas, principalmente na indústria de Telecomunicações. Tem um interesse especial em arquitetura de microserviços, serverless e containers.