Migrar uma aplicação .NET para a AWS: do GitHub à EC2

A sua aplicação .NET Core roda só na sua máquina e você quer vê-la funcionando na AWS. Aqui eu levo uma aplicação assim para uma instância EC2, acessível pelo navegador na porta 80, sem mexer no código: SSH, git clone, .NET SDK e dotnet run.

O ponto de partida: o projeto já roda local, está publicado no GitHub e existe uma instância EC2 criada na AWS.

A meta: primeiro levar, depois desacoplar

A proposta do minicurso é romper a barreira de levar a sua aplicação para a AWS. Quebrar a aplicação nos vários serviços da nuvem, o que eu chamo de desacoplamento, vem depois que ela já está lá dentro. Então o primeiro passo é copiar o que você tem para uma máquina na nuvem e fazer funcionar do jeito que já era.

Neste modelo a nuvem é só o host. A aplicação, o banco de dados e os serviços integrados ficam todos dentro da mesma EC2, parecido com o que você tem local. A diferença é que, estando na AWS, você passa a ter à disposição os serviços dela para ir tirando as peças dali, uma de cada vez.

Antes de ligar: o que a instância custa parada

Deixei a instância parada de propósito, para mostrar um benefício natural da nuvem: o poder computacional só é cobrado enquanto a instância está ligada. Parada, o que continua cobrando é o disco de 10 GB que alocamos, em torno de 1 dólar por mês.

Quando liguei a instância, a cobrança pelo processamento voltou a correr, e ela é fracionada: você paga pelo tempo de uso, por segundo. Por isso fica barato montar cases, ambientes de desenvolvimento e ambientes de homologação.

O valor do disco é o da gravação, em 2019. Confira o preço atual na página do Amazon EBS antes de planejar.

1Conectar na instância por SSH

Com a instância ligada, copie o endereço público dela no console (o Public DNS). Eu já tinha colocado a chave PEM, baixada na aula anterior, na raiz do projeto, e conectei com ssh:

ssh -i "sua-chave.pem" ec2-user@<DNS público da instância>

Troque sua-chave.pem pelo nome do arquivo que você baixou e o endereço pelo da sua instância. A máquina que abre é um Amazon Linux 2. Eu trabalhei com privilégio de administrador (sudo) para instalar os pacotes.

2Instalar o Git e clonar o projeto

O projeto está no GitHub, então o caminho é clonar. Na instância, o Git não vem instalado. Instale com o gerenciador de pacotes:

yum install git

Eu estava com o sudo ativo na sessão, por isso rodei sem prefixo. Confirme a instalação e crie uma pasta para o projeto:

mkdir projeto
cd projeto
git clone <URL HTTPS do seu repositório>

Entre na pasta que o clone criou. No meu caso, exemplo_migrando_para_aws. Eu disse na aula que deixaria o projeto de exemplo disponível para quem quiser clonar e testar.

3Instalar o .NET SDK

A aplicação é .NET Core, então a instância precisa do SDK. Na página de download da Microsoft, escolhi a distribuição CentOS 7 e rodei os dois comandos que ela mostra: o primeiro registra o repositório de pacotes da Microsoft, o segundo instala o SDK.

sudo rpm -Uvh https://packages.microsoft.com/config/centos/7/packages-microsoft-prod.rpm
sudo yum install dotnet-sdk-3.0

Esses são os comandos da época da gravação, para o .NET Core 3.0. Pegue os da página da Microsoft para a versão e a tecnologia que você usa. A instalação na AWS é rápida. Com o SDK instalado, restaure as dependências dentro da pasta do projeto:

dotnet restore

4Rodar na porta 80

Por padrão, o meu projeto sobe nas portas 5000 e 5001. Quero acessar pelo endereço da instância, na porta 80. O dotnet run --help mostra o parâmetro que resolve:

dotnet run --urls http://<DNS público da instância>

Eu passei o DNS público da instância, sem porta, e a aplicação respondeu que estava escutando na 80. Na primeira tentativa esqueci o http:// na frente do endereço e o .NET recusou a URL como inválida; com o http://, subiu.

Abra http:// seguido do DNS público da instância. A aplicação aparece, rodando na AWS.

Para atualizar, o fluxo é o de sempre: faça a mudança, dê o push para o GitHub e, na instância, um pull no projeto.

Onde você chegou e o que vem depois

Neste cenário, a sua aplicação inteira está numa instância EC2: o código, o banco de dados e os demais serviços integrados a ela. Você usa a nuvem como host, e isso não é o modelo ideal para a nuvem. É o ponto de partida, e a partir dele você desacopla aos poucos:

A ordem que eu sugeri para ir quebrando a aplicação:

• Banco de dados. Tire o banco de dentro da EC2 e use o serviço aderente ao seu banco, no caso o RDS.
• Aplicação sem estado. Transforme a aplicação em stateless, para que ela possa ter escalabilidade.
• Balanceamento e escala. Coloque um load balancer e o auto scaling na frente.

Cada um desses é assunto de outro tópico. A próxima aula do minicurso mostra um cenário simples para você ter uma prévia do custo que a sua aplicação teria na AWS, porque muita gente acha que a nuvem custa caro.

Checklist

• A chave PEM está fora do repositório, com *.pem no .gitignore.
• A instância está ligada e você copiou o DNS público dela.
• Você conectou por SSH como ec2-user.
• O Git está instalado e o projeto foi clonado numa pasta da instância.
• O .NET SDK foi instalado com os comandos da página da Microsoft para a sua versão.
• O dotnet restore terminou sem erro.
• O security group libera a porta 80 de entrada.
• O dotnet run --urls com o DNS público sobe a aplicação e ela abre no navegador.

Levar a aplicação como ela está é o passo que destrava os outros. Só depois de rodar na AWS faz sentido decidir o que desacoplar primeiro.