Escolar Documentos
Profissional Documentos
Cultura Documentos
A primeira ferramenta oficial de linha de comando para o Amazon Elastic Container Service (Amazon ECS) foi
criada em 2015. Em dezembro de 2019, compartilhamos a visualização de uma nova experiência de linha de
comando (em inglês), refeita do zero para facilitar o deploy de seus aplicativos no Amazon ECS. Hoje,
compartilhamos alguns de nossos avanços nesta ferramenta de linha de comando, bem como seu novo nome
oficial: AWS Copilot
O AWS Copilot foi projetado para usuários ECS novos e existentes que desejam ir além do gerenciamento manual
de infraestrutura de baixo nível e começar a pensar em seu aplicativo e ciclo de vida. O AWS Copilot cria
distribuições modernas de aplicativos com base em configurações prontas para produção que incluem melhores
práticas recomendadas por engenheiros e clientes do ECS ao longo dos anos.
Se você está projetando um novo aplicativo, você provavelmente começa com um diagrama mental que tem
caixas para cada serviço e linhas sobre como eles vão se comunicar uns com os outros Conforme esta aplicação
evolui, mais tarde, quando chegar a hora de criar essa arquitetura, há muitos mais componentes de nuvem para
se pensar: sub-redes da Virtual Private Cloud (VPC), balanceadores de carga, fluxos de implantação e
armazenamento persistente de seu aplicativo. O AWS Copilot lida com todos esses detalhes para você. Basta
fornecer seu contêiner e deixar o AWS Copilot lidar com deploys de alta disponibilidade e criação e configuração
do balanceador de carga. Você pode até mesmo fazer com que o AWS Copilot crie um fluxo de deploy que faça
automaticamente o deploy de uma versão mais recente do seu aplicativo toda vez que você enviar um novo
commit para seu repositório.
Resumindo, se você usar o AWS Copilot, poderá passar da ideia para o deploy muito mais rapidamente, com a
confiança de que a infraestrutura tem uma configuração pronta para produção.
Você pode instalar o AWS Copilot por meio do Homebrew ou baixando os binários diretamente.
Usando Homebrew
Se você não quiser usar o Homebrew, você pode instalá-lo manualmente baixando a versão mais recente do
GitHub em sua máquina de desenvolvimento.
Mac
Linux
O AWS Copilot usa as mesmas credenciais que a AWS CLI (Command Line Interface), portanto, se você já usa a
CLI da AWS em sua máquina de desenvolvimento, está pronto para usar. Se você ainda não instalou ou
configurou a CLI da AWS, siga estas instruções. Certifique-se de executar o comando aws configure depois de
instalar o AWS CLI.
Por último, mas não menos importante, você precisará se certificar de que o Docker está instalado em sua
máquina de desenvolvimento. AWS Copilot usará o Docker para criar e empacotar seu aplicativo.
Primeiro, vamos dar uma olhada rápida nos comandos de alto nível disponíveis no AWS Copilot:
Aplicação: Uma aplicação é um mecanismo para agrupar partes do seu sistema. Seguindo a Lei de Conway,
você dividiria seus componentes em aplicativos AWS Copilot que correspondem às diferentes equipes de
desenvolvimento de sua organização. Por exemplo, se sua organização é pequena e você tem uma equipe de
desenvolvimento unificada que trabalha em um pouco de tudo, provavelmente você pode organizar as coisas
como um único aplicativo composto por um ou mais serviços. Mas se você tem várias equipes, cada uma
responsável por um único grupo de componentes, e, portanto, há muito pouco trabalho entre as equipes,
então cada equipe deve ter seu próprio aplicativo AWS Copilot.
Ambiente: Um ambiente é um estágio no deploy de um aplicativo. Por exemplo, você pode primeiro instalar
um aplicativo em um ambiente de “Q&A” para que ele possa ser testado sem afetar seus clientes. Depois de
ter sido verificado que ele funciona como pretendido, você instalar essa versão do aplicativo no ambiente de
“Produção” para que seus clientes possam acessá-lo.
Serviço: Um serviço é um processo de código exclusivo e de longa duração dentro de um contêiner. Um
aplicativo consiste em um ou mais serviços. Se você estiver usando uma arquitetura monolítica, é provável
que cada aplicativo tenha um único serviço. Uma arquitetura altamente distribuída usará vários serviços para
cada aplicativo. Por exemplo, você pode ter um serviço um site com um balanceador de carga conectado à
Internet, um serviço interno “API” que só pode ser acessado por meio da descoberta de serviços e um serviço
de trabalho em segundo plano (Daemon) que executa trabalhos em uma fila. Juntos, esses serviços compõem
os componentes de um único aplicativo.
A primeira etapa para qualquer aplicativo em contêineres é o Dockerfile. O Dockerfile é um pequeno arquivo
que descreve quais dependências e arquivos seu aplicativo precisa, bem como qual programa executar no
contêiner. Para este caso de exemplo, usaremos NGINX, um servidor web simples para um aplicativo de
demonstração, meu Dockerfile ficará assim:
FROM nginx:alpine
EXPOSE 80
COPY . /usr/share/nginx/html
Este Dockerfile diz ao Docker para começar com um contêiner pré-configurado que já tem NGINX dentro e, em
seguida, adicionaremos arquivos HTML ao contêiner. Também incluímos uma declaração EXPOSE para que o
AWS Copilot saiba qual porta de aplicativo precisa ser exposta ao mundo por meio de um balanceador de carga.
$copilot init
O AWS Copilot localiza automaticamente o arquivo Dockerfile que você criou. Fará algumas perguntas, como
por exemplo, se você quer nomear o aplicativo. Em seguida, você criará um ambiente para instalar o serviço.
Então ele construirá e enviará o contêiner para a nuvem. Por último, mas não menos importante, ele irá fornecer-
lhe uma URL onde podemos acessar o aplicativo.
Agora que o aplicativo está funcionando, podemos acessar diretamente a URL no navegador e enviar algumas
solicitações:
Depois de fazer algumas solicitações da Web para meu serviço NGINX em contêineres, posso usar o AWS Copilot
para exibir os logs da aplicação executando o seguinte comando em um terminal ssh:
Nesse caso, os logs do serviço são somente logs de acesso NGINX, mas se estivéssemos executando qualquer
outra aplicação, qualquer entrada de log (debug ou erros) impressos na saída padrão seriam exibidos aqui.
O primeiro aplicativo que você fizer o deploy no AWS Copilot começará com a configuração padrão, que instala
apenas um pequeno contêiner usando AWS Fargate, um serviço de contêiner sem servidor que funciona com o
Amazon Elastic Container Service (ECS) e Amazon Elastic Kubernetes Service (EKS). Essa configuração é
otimizada para baixo custo e ideal para fins de desenvolvimento, mas ainda não está pronta para o tráfego de
produção.
Para se preparar para o tráfego em um ambiente de produção, você precisará configurar um novo ambiente.
Execute o seguinte comando em um terminal ssh
Agora, antes de implementar este serviço nesse ambiente de produção, precisamos fazer algumas alterações na
configuração desse ambiente de produção. Podemos encontrar o arquivo de manifesto de configuração do meu
serviço no seguinte caminho: applicationname/manifest.yml
Esse arquivo de manifesto contém todas as configurações padrão do meu aplicativo como a porta, a quantidade
de CPU e memória necessária e quantas cópias do aplicativo deve ser executado. Vamos alterar essas
configurações para o ambiente de produção adicionando as seguintes instruções ao arquivo de manifesto:
environments:
production:
count: 2
cpu: 1024
memory: 2048
Isso diz ao AWS Copilot que quando façamos o deploy do nosso aplicativo em produção, teremos duas cópias do
aplicativo, cada uma com 1 CPU e 2 GB de memória.
$copilot svc deploy —env production
Desta vez, a AWS Copilot faz o deploy do aplicativo no ambiente de produção como um conjunto de réplicas de
alta disponibilidade distribuídas pelas Zonas de disponibilidade, e cada contêiner tem mais CPU e memória.
Podemos executar um teste de carga simples usando o ApacheBench para ter uma idéia de quanto tráfego essa
implementação pode lidar. Execute o seguinte comando em um terminal
ab -n 5000 -c 25 http://nyan-Publi-WI97060DJP1B-2041999651.us-east-1.elb.amazonaws.com
Este comando diz ao Apachebench para fazer 5000 solicitações ao serviço, com uma 25 solicitações simultâneas
de cada vez.
Os resultados finais mostram 353 requisições aceitas por segundo, p99 de apenas 165 ms e um tempo médio por
solicitação de 70 ms.
Concurrency Level: 25Time taken for tests: 14.140 secondsComplete requests: 5000Faile
Se decidirmos que precisamos suportar um tráfego maior do que isso, podemos facilmente modificar o
manifesto do aplicativo para escalar horizontalmente aumentando o número de containers em produção ou
escala adicionando mais CPU ao meu serviço e, em seguida, executar o comando copilot svc deploy novamente.
Conclusão
Como você pode ver, o AWS Copilot foi projetado para ajudá-lo a fazer deploys de serviços de contêiner prontos
para produção com apenas alguns comandos. Você fornece seu Dockerfile e permite que o AWS Copilot crie,
envie e inicie seu contêiner na AWS.
Mas este é apenas o começo das poderosas características do AWS Copilot. Ao usar o AWS Copilot, você também
obtém uma maneira fácil de:
Configurar um fluxo Integração Continua ou Deploy Continuo automaticamente para que você possa fazer
deploys simplesmente sincronizando com um repositório Git
(Em breve) Provisione armazenamento para seus serviços, incluindo buckets S3, bancos de dados NoSQL e
SQL
Em um artigo futuro, aprofundaremos esses recursos poderosos. Enquanto isso, envie-nos seus comentários ou
solicitações de recursos no repositório oficial do GitHub do projeto. Solicitações de download também são bem-
vindas!
Mais informações:
https://aws.amazon.com/blogs/containers/introducing-aws-copilot/
Sobre o autor
Nathan Peck is a developer advocate for Elastic Container Service at Amazon Web Services. He focuses on
highlighting the developer community that has embraced Amazon ECS, and connecting new developers to open
source projects that can help them succeed at using ECS.
Sobre o tradutor