É aquela época do ano novamente! Esta postagem faz parte de nosso Rumo ao AWS re:Invent 2017 série de blogs. Nas semanas que antecedem o AWS re:Invent, em Las Vegas, em novembro, postaremos sobre vários tópicos relacionados à execução do MongoDB na nuvem pública. Veja todas as postagens aqui.
Em minha última postagemcomeçamos a preparar um aplicativo baseado em Node.js e MongoDB Atlas para operações CRUD simples. Concluímos a configuração inicial do código e agora estamos prontos para colocá-lo em produção.
Conforme mencionado na primeira parte, quero minimizar a manutenção de longo prazo do ambiente de hospedagem desse aplicativo. Da mesma forma que usamos o MongoDB Atlas para transferir muitas das responsabilidades operacionais do nosso banco de dados, podemos usar o Amazon EC2 Container Service para implementar nossos aplicativos Docker no AWS. Ao reduzir a quantidade de patches, a manutenção de sistemas e as preocupações de segurança de longo prazo tanto para o nosso banco de dados quanto para o front-end do aplicativo, podemos dedicar mais tempo ao desenvolvimento do aplicativo.
Preparar o Docker e o coldbrew-cli para implantação
O Docker e o coldbrew-cli têm arquivos de configuração simples que analisaremos e escreveremos no diretório raiz do nosso repositório.
Docker
Vamos dar uma olhada no Dockerfile:
| DE node:boron | |
| CORRER mkdir -p /usr/src/app | |
| WORKDIR /usr/src/app | |
| CÓPIA . /usr/src/app | |
| EXPOSE 3000 | |
| CMD [“npm”, “start”] |
Esse arquivo dirá ao Docker para seguir as instruções para usar a versão “boron” LTS do Node.js, o que significa que não precisaremos instalá-lo manualmente para trabalhar com nosso aplicativo. Depois de estabelecer a versão apropriada do Node.js a ser usada, criaremos um diretório de trabalho no contêiner informando onde o aplicativo ficará. O aplicativo será copiado para o diretório de trabalho, "/usr/src/app"e, finalmente, será iniciado usando o comando npm start indicado em nosso package.json .
Coloque o conteúdo do Dockerfile na raiz do repositório de código e salve-o.
echo "FROM node:boron > > RUN mkdir -p /usr/src/app >WORKDIR /usr/src/app > >COPY . /usr/src/app > >EXPOSE 3000 > >CMD ["npm", "start"]" > Dockerfile
Em seguida, começaremos a trabalhar com o coldbrew-cli. Assim como no Docker, criaremos um arquivo de configuração de texto simples que conterá instruções básicas sobre como configurar nossa infraestrutura para nosso aplicativo.
coldbrew-cli
Vamos criar um arquivo chamado coldbrew.conf na raiz do diretório do nosso repositório e armazenar o seguinte conteúdo nele:
touch coldbrew.conf
| nome: mern-demo | |
| cluster: mern-demo | |
| port: 3000 | |
| unidades: 2 | |
| cpu: 1.0 | |
| memória: 500m | |
| load_balancer: | |
| habilitado: true | |
| health_check: | |
| path: / | |
| status: 200 |
Para obter uma análise completa de todos os termos deste arquivo, dê uma olhada no documentação do coldbrew-cli. Forneci um arquivo de configuração simples que configurará nosso balanceamento de carga elástica (ELB) com uma instância de computação para nosso contêiner e 500 MB de memória disponível por aplicativo. Podemos até configurar uma verificação de integridade simples para nosso ELB para garantir que nossas instâncias estejam on-line.
Agora podemos criar nosso ambiente com o coldbrew-cli. Para fins deste passo a passo, digamos que queremos implantar nosso cluster ECS na região us-east-2 e que não precisamos acessar nossos nós via SSH; podemos iniciar usando o seguinte comando:
$ coldbrew --aws-region="us-east-2" cluster-create mern-demo --disable-keypair
Depois de executar isso, será exibida uma lista de recursos que serão criados:
Determining AWS resources to create... ECS Cluster: coldbrew-mern-demo IAM Role for ECS Services: coldbrew-mern-demo-ecs-service-role EC2 Launch Configuration for ECS Container Instances: coldbrew-mern-demo-lc EC2 Auto Scaling Group for ECS Container Instances: coldbrew-mern-demo-asg IAM Instance Profile for ECS Container Instances: coldbrew-mern-demo-instance-profile EC2 Security Group for ECS Container Instances: coldbrew-mern-demo-instance-sg Do you want to create these resources? [y/N]:
Responda “Yes”, e seus recursos começarão a ser criados em segundo plano.
[+] Creating IAM Instance Profile [coldbrew-mern-demo-instance-profile]... [+] Creating EC2 Security Group [coldbrew-mern-demo-instance-sg]... [*] Adding inbound rule [tcp:22:0.0.0.0/0] to EC2 Security Group [coldbrew-mern-demo-instance-sg]... [+] Creating EC2 Launch Configuration [coldbrew-mern-demo-lc]... (this may take long) [+] Creating EC2 Auto Scaling Group [coldbrew-mern-demo-asg]... (this may take long) [+] Creating ECS Cluster [coldbrew-mern-demo]... [+] Creating IAM Role [coldbrew-mern-demo-ecs-service-role]...
Podemos consultar o status com o seguinte comando:
$ coldbrew --aws-region="us-east-2" cluster-status mern-demo
Aqui está a saída do comando semelhante ao que obteríamos:
Cluster
Name: mern-demo
AWS
Region: us-east-2
VPC: vpc-7935db10
Subnets: subnet-70f0df3a subnet-58e01531 subnet-49d4db31
ECS
ECS Cluster: coldbrew-mern-demo
IAM Role for ECS Services: coldbrew-mern-demo-ecs-service-role
ECS Services: 0
ECS Tasks (running/pending): 0/0
ECS Container Instances: 1
Auto Scaling
EC2 Launch Configuration: coldbrew-mern-demo-lc
IAM Instance Profile: coldbrew-mern-demo-instance-profile
Instance Type: t2.micro
Image ID: ami-bd3e64d8
Key Pair:
Security Groups: coldbrew-mern-demo-instance-sg
EC2 Auto Scaling Group: coldbrew-mern-demo-asg
Instances (current/desired/min/max): 1/1/0/1
ECS Container Instance
ID: a56d40d1-7095-45a0-af81-5f309bbbd728
Status: ACTIVE
Tasks (running/pending): 0/0
CPU (remaining/registered): 1.00/1.00
Memory (remaining/registered): 995M/995M,
EC2 Instance ID: i-03fdc038f3d1c71c8
Private IP: 172.31.44.140
Public IP: 18.221.72.130
Uau, isso é muito trabalho poupado. Tudo, desde a nossa VPC até o ELB, foi criado para nós. Está vendo o IP público da nossa instância de computação? Vamos nos certificar de que ele esteja na lista de permissões do nosso cluster do Atlas para que nossos dados possam ser salvos.
Se o senhor substituísse o cluster gratuito M0 por um dos clusters dedicados do Atlas, teria acesso ao nosso módulo de peering VPC para AWS, o que lhe daria a capacidade de colocar na lista de permissões toda a gama de servidores host por meio de uma entrada de grupo de segurança na lista de permissões.
Agora é hora de criar nossa imagem do Docker com o coldbrew-cli e implementar nosso aplicativo.
Primeiro, uma imagem do Docker é criada e salva:
$ coldbrew --aws-region="us-east-2" deploy [*] Checking cluster availability [mern-demo]... [+] Creating ECR Repository [coldbrew/mern-demo]... [*] Building Docker image [722245653955.dkr.ecr.us-east-2.amazonaws.com/coldbrew/mern-demo:latest]... (this may take long) > docker build -t 722245653955.dkr.ecr.us-east-2.amazonaws.com/coldbrew/mern-demo:latest -f /Users/jaygordon/work/mern-crud/Dockerfile /Users/jaygordon/work/mern-crud
Em seguida, a imagem é enviada para os nós apropriados no cluster:
[*] Pushing Docker image [722245653955.dkr.ecr.us-east-2.amazonaws.com/coldbrew/mern-demo:latest]... (this may take long) > docker push 722245653955.dkr.ecr.us-east-2.amazonaws.com/coldbrew/mern-demo:latest The push refers to a repository [722245653955.dkr.ecr.us-east-2.amazonaws.com/coldbrew/mern-demo] a791685d46cb: Pushed e71eccb6eee4: Pushed b7f1d9d858aa: Pushed 246ae56dbdbd: Pushed e271ac6d0c18: Pushed 682e7cee9d37: Pushed d359ab38b013: Pushed latest: digest: sha256:c58153d1fe62dacb1644966ffe4acca6b76cb383aee1f76e0efd97ceaa1a306e size: 2425 [*] Updating ECS Task Definition [mern-demo]... [+] Creating ELB Target Group [mern-demo-elb-tg]... [+] Creating EC2 Security Group [mern-demo-elb-sg]... [*] Adding inbound rule [tcp:80:0.0.0.0/0] to EC2 Security Group [mern-demo-elb-sg]... [*] Adding inbound rule [tcp:0:sg-f8ab7190] to EC2 Security Group [coldbrew-mern-demo-instance-sg]... [+] Creating ELB Load Balancer [mern-demo-elb]... [+] Adding listener (HTTP) for ELB Load Balancer [mern-demo-elb]... [+] Creating ECS Service [mern-demo]... Application deployment completed.
Nosso aplicativo agora está implantado. Vamos obter o ELB e verificar:
coldbrew --aws-region="us-east-2" status |egrep elb
ELB Target Group: mern-demo-elb-tg
ELB Load Balancer: mern-demo-elb
Endpoint: http://mern-demo-elb-2131866240.us-east-2.elb.amazonaws.com:80
O ELB agora nos fornece um endpoint http para acessar nosso aplicativo. Não há necessidade de usar o nginx ou qualquer outro servidor http para fazer proxy reverso da porta do Node.js. O processo de implantação do coldbrew-cli configurará o encaminhamento de porta com base nas informações do arquivo coldbrew.conf. A criação e a implantação do cluster levam cerca de cinco minutos. Para testar se estamos on-line e em funcionamento, basta acessar o URL fornecido pelo coldbrew e adicionar um registro ao nosso aplicativo (o primeiro carregamento pode levar um minuto):
Parabéns, agora temos todas as ferramentas para criar e configurar nosso próprio cluster ECS usando o MongoDB Atlas! Destruir o aplicativo também é bastante simples – basta executar esses dois comandos para encerrar todos os recursos associados ao ECS.
$ coldbrew --aws-region="us-east-2" delete Determining AWS resources that need to be deleted... ECS Service: mern-demo ECR Repository: coldbrew/mern-demo ELB Target Group: mern-demo-elb-tg ELB Load Balancer: mern-demo-elb EC2 Security Group for ELB Load Balancer: mern-demo-elb-sg > Do you want to delete these resources? [y/N]: y
Depois que respondermos “sim”, os recursos criados começarão a ser encerrados:
[*] Updating ECS Service to stop all tasks [mern-demo]... [-] Deleting ELB Load Balancer [mern-demo-elb]... [-] Deleting ELB Target Group [mern-demo-elb-tg]... (this may take long) [-] Removing inbound rule [tcp:0:sg-f8ab7190] from EC2 Security Group [coldbrew-mern-demo-instance-sg]... [-] Deleting EC2 Security Group for ELB Load Balancer [mern-demo-elb-sg]... (this may take long) [-] Deleting ECR Repository [coldbrew/mern-demo]... [-] Deleting (and draining) ECS Service [mern-demo]... (this may take long)
E agora exclua os elementos restantes do cluster:
$ coldbrew --aws-region="us-east-2" cluster-delete mern-demo Determining AWS resources that need to be deleted... ECS Cluster: coldbrew-mern-demo IAM Role for ECS Services: coldbrew-mern-demo-ecs-service-role EC2 Launch Configuration for ECS Container Instances: coldbrew-mern-demo-lc EC2 Auto Scaling Group for ECS Container Instances: coldbrew-mern-demo-asg IAM Instance Profile for ECS Container Instances: coldbrew-mern-demo-instance-profile EC2 Security Group for ECS Container Instances: coldbrew-mern-demo-instance-sg > Do you want to delete these resources? [y/N]: y
Responda “yes” e veremos os elementos restantes do cluster de computação serem encerrados:
[*] Terminating instances in EC2 Auto Scaling Group [coldbrew-mern-demo-asg]... (this may take long) [-] Deleting EC2 Auto Scaling Group [coldbrew-mern-demo-asg]... (this may take long) [-] Deleting EC2 Launch Configuration [coldbrew-mern-demo-lc]... [-] Deleting IAM Instance Profile [coldbrew-mern-demo-instance-profile]... [-] Deleting EC2 Security Group [coldbrew-mern-demo-instance-sg]... [-] Deleting ECS Cluster [coldbrew-mern-demo]... [-] Deleting IAM Role [coldbrew-mern-demo-ecs-service-role]...
O que vem a seguir?
Experimente esse processo com seu próprio aplicativo ou até mesmo com um cluster dedicado do MongoDB Atlas para habilitar o emparelhamento VPC. O senhor pode obter um tutorial completo sobre como configurar o emparelhamento VPC no MongoDB Atlas, visualizando o “Emparelhando seu cluster do MongoDB Atlas com o AWS” vídeo. O senhor poderá usar uma implementação totalmente baseada em serviços do seu aplicativo que não exige o gerenciamento de sistemas operacionais, a atualização de kernels e menos trabalho manual geral.
Se quiser se inscrever para um cluster gratuito do MongoDB Atlas, consulte nossa página de inscrição aqui!
Sobre Jay Gordon
Jay Gordon é um defensor do desenvolvedor no MongoDB, focado em fornecer aos usuários uma ótima experiência com produtos em nuvem. Ele entrou para a MongoDB em 2016, depois de muitos anos trabalhando como administrador de sistemas e profissional de DevOps.