AWS

Segurança em VPC com Network ACL e Security group

Após criar uma VPC na AWS, não podemos nos descuidar com relação a segurança dessa rede. Existem duas formas de garantir a segurança em VPC no nível de rede: com Network ACL e security groups.

Nesse artigo vamos conhecer como funciona cada um deles e quais suas principais diferenças.

Amazon Web Services (AWS) - Fundamentos
Curso de Amazon Web Services (AWS) - Fundamentos
CONHEÇA O CURSO

Network ACL

A primeira forma de implementar segurança na camada de rede da nossa VPC é através do Network ACL.

Com ele, você pode definir um conjunto de regras diretamente nas suas subnets, muito parecido com a configuração de um Firewall tradicional, o que acaba sendo uma boa opção para administradores de redes.

Essas regras são compostas pelas seguintes partes:

  • Uma numeração, que define a sequência que as regras são avaliadas;
  • Porta ou range de portas, ou um tipo de serviço tratado nessa regra, como por exemplo, HTTP é um tipo de serviço já conhecido que permite liberar a porta 80;
  • Qual o protocolo de comunicação, como TCP, UDP, entre outros. Essa configuração pode ser definida em conjunto pelo tipo de serviço;
  • Qual a origem ou destino desse tráfego, definido como um endereçamento de CIDR (182.168.0.1/24 por exemplo);
  • Uma ação, seja ela para permitir (ALLOW) ou negar (DENY) o tráfego;
  • Uma descrição amigável para essa regra.

É bom lembrar que o Network ACL funciona tanto para o tráfego de inbound como de outbound.

Entenda como inbound todo tráfego que vai entrar na sua subnet. Por exemplo, ao acessar um servidor web, é enviado uma requisição na porta 80, sendo possível você permitir ou negar essa requisição, dependendo do CIDR de origem. Já o outbound se refere a todo tráfego de saída, como por exemplo, uma requisição enviada para uma API externa, ou a resposta de uma query no banco de dados.

Exemplo de uma Network ACL

Logo abaixo temos um exemplo de configuração de um Network ACL. Ela abrange regras tanto de inbound como de outbound para serviços comuns, como HTTP, HTTPS, SSH e RDP. Além das portas convencionais, em alguns casos vai ser necessário liberar as portas efêmeras, como é o caso da regra 120 de outbound, necessária para utilizar SSH por exemplo.

Regras de Inbound

Regras de Outbound

As portas efêmeras, também conhecidas como portas dinâmicas ou portas altas, são portas utilizadas por um curto período de tempo para a continuação da conexão entre um cliente com um servidor para responder a conexões em uma porta comum (como a porta 22 de SSH). Portanto, tenha em mente que pode ser preciso permitir o tráfego nessas portas, caso seja necessário.

Security group

A segunda forma de implementar segurança na camada de rede na nossa VPC é através dos security group. Ao contrário do Network ACL, as regras de security group são associadas ao nível do recurso. Isso permite a construção de regras mais granulares e funciona de forma mais integrada com um ambiente Cloud, sendo uma forma igualmente segura e amplamente utilizada.

A definição de uma regra de security group é dividida pelas seguintes partes:

  • Um tipo de tráfego, seja um serviço, uma porta ou um range de portas;
  • Um protocolo, sendo os mais utilizados TCP ou UPD;
  • Qual a origem ou destino do tráfego, que pode ser tanto um endereçamento CIDR ou outro security group;
  • Uma descrição amigável.

O security group também funciona tanto para inbound como para outbound, sendo que é mais comum configurar somente o inbound pela forma que o security group funciona.

Exemplo de um security group

Podemos observar abaixo um exemplo de algumas regras em um security group, definindo regras bastante semelhantes das configuradas com Network ACL:

Regras de security group

Nessas regras, estamos permitindo o tráfego de qualquer rede nas portas 80 e 443 (HTTP e HTTPS), além de portas para administração dessa máquina virtual com SSH ou RDP, a partir de um bastion host. Não é preciso definir o outbound dessas conexões em um security group pois se o tráfego de entrada é permitido, o seu retorno automaticamente é permitido. Isso inclui serviços que usam portas efêmeras também.

Além disso, as regras de outbound definidas permitem a conexão com banco de dados SQL Server ou MySQL que tenham um security group específico anexado a eles, limitando de forma bem granular o que aquele recurso pode de fato acessar.

Vale lembrar que, mesmo podendo associar um mesmo security group em vários recursos, você tem um limite de até 5 security groups em cada recurso. Então lembre-se que pode não ser uma boa ideia criar security groups muito granulares, contendo uma única regra para maximizar seu reaproveitamento. Prefira security groups descritivos e que tenham uma responsabilidade clara, mesmo que envolva duplicar algumas regras.

Rede de Computadores - Protocolo TCP/IP
Curso de Rede de Computadores - Protocolo TCP/IP
CONHEÇA O CURSO

Comparação

Agora que conhecemos cada uma das formas de deixar nossa VPC mais segura, vamos a uma breve comparação de cada uma dessas:

Network ACL:

  • Aplicado na subnet: permite definir regras mais globais, que sejam efetivas em uma subnet completa;
  • Transparente para os recursos: todos os recursos dessa subnet tem seu tráfego filtrado, o que pode resultar em uma grande quantidade de regras;
  • Pode permitir ou negar tráfego: funciona de forma mais similar a um firewall convencional, podendo permitir (ALLOW) ou negar o tráfego (DENY);
  • Interpretado sequencialmente: cada regra é interpretada individualmente, onde a sequência que as regras são configuradas importa;
  • Stateless: necessário especificar tanto uma regra de inbound como outbound para liberar uma porta específica.

Security group:

  • Aplicado no recurso: permite definir regras granulares, que sejam efetivas em um único recurso;
  • Precisa ser aplicado em todos recursos: para funcionar corretamente, o security group precisa estar associado com todos os recursos necessários, sendo fácil esquecer de configurar em algum recurso;
  • Pode apenas permitir tráfego: não é possível criar uma regra para negar o tráfego (DENY) em um security group;
  • Interpretado de forma compilada: como ele funciona anexado a um recurso, todas as regras dos security groups associadas nesse recurso são combinadas e as regras com maior abrangência são consideradas;
  • Statefull: todo o tráfego liberado em um security group tem seu retorno previamente liberado, o que facilita a sua configuração.

Entretanto, nada impede que ambos sejam utilizados em conjunto. Você pode, por exemplo, permitir que os administradores de rede da sua empresa defina regras globais de acesso entre as subnets usando Network ACLs e criar regras mais granulares, para dividir ambientes de produção e desenvolvimento nas mesmas subnets usando security groups.

Conclusão

Conhecemos aqui as principais formas de deixar nossa VPC segura. Primeiramente vimos como funciona o Network ACL, em segundo lugar vimos o security group, ambos com regras de exemplos e uma comparação entre cada um deles.

Nas próximas semanas será lançado o curso AWS – Ferramentas de Rede e Distribuição de Conteúdo – Fundamentos que irá abordar com muito mais detalhes como funciona a configuração de cada um desses recursos.

Amazon Web Services (AWS) - RDS - Fundamentos
Curso de Amazon Web Services (AWS) - RDS - Fundamentos
CONHEÇA O CURSO

Fiquem ligados e nos sigam nas nossas redes sociais, como Twitter, Instagram, Facebook e LinkedIn. Assim que esse curso for lançado você saberá em primeira mão!

Criando e publicando uma função AWS Lambda com o CLI do .NET Core

AWS Lambda é um serviço da AWS que nos permite criar aplicações no modelo serverless. Fornecendo suporte para as versões 2.1 e 3.1 do .NET Core, este serviço disponibiliza uma série de ferramentas que permite a criação, publicação e execução de uma função do AWS Lambda pelo CLI do .NET Core.

Amazon Web Services (AWS) - Lambda - Fundamentos
Curso de Amazon Web Services (AWS) - Lambda - Fundamentos
CONHEÇA O CURSO

.NET Core CLI

A interface de linha de comando do .NET Core é uma ferramenta multiplataforma que disponibiliza nativamente recursos para a criação, desenvolvimento, execução e publicações de aplicações .NET Core. Além disso, também permite que terceiros forneçam pacotes NuGet que expandem seus recursos.

Neste artigo conheceremos os pacotes disponibilizados pela AWS Lambda, que nos permite gerenciar uma função diretamente pela linha de comando desta ferramenta.

Criando uma função AWS Lambda com CLI do .NET Core

Antes de mais nada é importante que tenha o SDK do .NET Core instalado na sua máquina. No momento da criação deste artigo, só há suporte para as versões 2.1 e 3.1 do .NET Core, então é necessário que instale uma dessas versões. Caso já tenha suporte para uma versão superior, opte por ela.

Também é importante que tenha uma conta na AWS e o AWS CLI configurado na sua máquina (esta configuração será utilizada para publicar a função Lambda). Você pode ver como fazer isso, no artigo sobre a instalação e configuração do AWS CLI do Gabriel.

Para criar uma função Lambda com o CLI do .NET Core, é necessário instalar o pacote Amazon.Lambda.Templates, que fornece uma série de templates do AWS Lambda. Esta instalação pode ser realizada com o comando abaixo:

dotnet new --install Amazon.Lambda.Templates

Note que ao instalar o pacote já serão listados os templates do AWS Lambda que foram disponibilizados na ferramenta:

No nosso caso iremos utilizar o template lambda.EmptyFunction, que permite a criação de uma função Lambda vazia:

dotnet new lambda.EmptyFunction --name ExemploFuncaoLambda

Este template irá criar um projeto com duas pastas: src e test; que contém, respectivamente, o projeto da função e o projeto de testes:

Estrutura do projeto da função Lambda e do projeto de teste, exibido no Visual Studio Code

Outro arquivo importante é o aws-lambda-tools-defaults.json, presente no projeto da função. É nele que se deve informar as configurações do AWS Lambda que a função utilizará. Veremos isso em mais detalhes à frente.

Desenvolvendo a função AWS Lambda

Para este artigo criei uma função simples que retorna o nome da rua de acordo com o cep informado:

public class Function
{
    private static readonly HttpClient client = new HttpClient();

    /// <summary>
    /// A simple function that takes a brazilian zip code and return the street name
    /// </summary>
    /// <param name="input"></param>
    /// <param name="context"></param>
    /// <returns></returns>
    public async Task<string> FunctionHandlerAsync(string input, ILambdaContext context)
    {
        if(input != null){
            var streamTask = await client.GetStreamAsync($"https://viacep.com.br/ws/{input}/json/");
            var endereco = await JsonSerializer.DeserializeAsync<Endereco>(streamTask);
            return endereco.logradouro;
        }
        return "CEP não informado";
    }
}

Assim como o método Main do C#, a função Lambda pode ou não ser assíncrona. Neste exemplo estamos definindo uma função assíncrona.

Também note o uso da classe Endereco que possui a estrutura abaixo:

public class Endereco
{
    public string logradouro { get; set; }
}

Como o código da função mudou, é necessário alterar o projeto de teste:

public class FunctionTest
{
    [Fact]
    public void TestToUpperFunction()
    {
        var function = new Function();
        var context = new TestLambdaContext();
        var rua = function.FunctionHandlerAsync("01001000", context).Result;

        Assert.Equal("Praça da Sé", rua);
    }
}

Ele pode ser executado para verificar se está tudo certo com a função:

Com a função definida, podemos publicá-la no AWS Lambda.

Publicando a função no AWS Lambda com o CLI do .NET Core

Para publicar uma função no AWS Lambda, a primeira coisa que deve ser feita é configurar o arquivo aws-lambda-tools-defaults.json:

{
  "Information": [
    "This file provides default values for the deployment wizard inside Visual Studio and the AWS Lambda commands added to the .NET Core CLI.",
    "To learn more about the Lambda commands with the .NET Core CLI execute the following command at the command line in the project root directory.",
    "dotnet lambda help",
    "All the command line options for the Lambda command can be specified in this file."
  ],
  "profile":"default",
  "region" : "sa-east-1",
  "configuration": "Release",
  "framework": "netcoreapp3.1",
  "function-runtime": "dotnetcore3.1",
  "function-memory-size": 256,
  "function-timeout": 30,
  "function-handler": "ExemploFuncaoLambda::ExemploFuncaoLambda.Function::FunctionHandlerAsync"
}

Neste arquivo, na opção profile, deve ser informado qual credencial configurada com o AWS CLI será utilizada para a publicação da função. Esta credencial precisa ter permissão de criação de funções Lambda. Geralmente se apenas uma credencial estiver configurada, ela receberá o nome de default.

Nas demais opções temos:

  • region: Região do AWS que a função será publicada;
  • configuration: Tipo de configuração da função, pode ser “Debug” ou “Release”;
  • framework: Framework utilizado para compilar a função;
  • function-runtime: Framework utilizado para executar a função;
  • function-memory-size: Limite de memória utilizada pela função em MB. Deve ser informado um múltiplo de 64.
  • function-timeout: Tempo máximo de execução da função em segundos. Tempo máximo, 15 minutos;
  • function-handler: Caminho da função, segundo o padrão: Projeto::Namespace.Classe::Metodo.

Já para publicar a função iremos utilizar a global tool Amazon.Lambda.Tools, que pode ser instalada com o comando abaixo:

dotnet tool install -g Amazon.Lambda.Tools

Após a instalação dela, acesse a pasta do projeto da função e execute o comando:

dotnet lambda deploy-function FuncaoExemplo --function-role role

No atributo --function-role deve ser informado quais permissões a função terá. Isso determinará se ela terá acesso a outros serviços da AWS. Caso não seja informado, as permissões podem ser definidas durante a publicação da função. Como já tenho uma role de teste definida, vou utilizá-la para publicar a função:

Se a publicação não apresentou nenhum erro, podemos testar a nossa função.

DaVinci Resolve Fairlight - Edição de áudio
Curso de DaVinci Resolve Fairlight - Edição de áudio
CONHEÇA O CURSO

Executando a função no AWS Lambda com o CLI do .NET Core

Com a função publicada no Lambda, ela pode ser invocada pelo CLI do .NET Core utilizando a opção lambda invoke-function, seguido do nome da função. Por exemplo:

dotnet lambda invoke-function FuncaoExemplo --payload "01001000"

Também note o atributo --payload, onde pode ser informado os dados que serão passados para a função. Ao executar este comando, a função será chamada e será exibido no terminal o seu retorno:

Caso queira excluir a sua função, pode ser utilizado o comando abaixo:

dotnet lambda delete-function FuncaoExemplo

Por fim, mesmo que a maioria das opções que vimos aqui estejam disponíveis no AWS CLI, os recursos adicionados no CLI do .NET Core, facilitam e muito o trabalho de quem desenvolve funções Lambda em C#. Se este é o seu caso, também não deixe de dar uma olhada nos demais recursos disponíveis, utilizando o comando dotnet lambda --help.

É isso por hoje. Você pode ver o código completo da função no meu Github.

Até a próxima 🙂

O que é VPC e como ela funciona?

Ao criar uma conta na AWS, você irá utilizar uma Virtual Private Cloud (VPC) para provisionar a grande maioria dos seus recursos. A VPC estabelece uma seção isolada logicamente na nuvem da AWS para esses recursos.

Vamos entender em seguida qual é a sua importância e o que podemos fazer com uma VPC na AWS.

Amazon Web Services (AWS) - Fundamentos
Curso de Amazon Web Services (AWS) - Fundamentos
CONHEÇA O CURSO

O que é VPC?

A VPC é o principal serviço de rede privada na AWS. Ela tem uma ligação íntima em como suas aplicações estarão distribuídas dentro dos servidores da AWS, e principalmente com será o acesso de rede dessa aplicação para redes externas, como por exemplo a internet.

Como explicado anteriormente no artigo Introdução à AWS, a nuvem da AWS é distribuída entre regiões e zonas de disponibilidade espalhadas pelo mundo todo. Podemos ter acesso a essa infraestrutura, de forma isolada, graças as VPC e suas subnets.

Toda vez que selecionamos uma região no console da AWS, podemos perceber que já existe uma VPC padrão. Dessa forma, podemos utilizar determinada região sem precisar configurar uma VPC do zero:

Subnets em um VPC padrão

Como você pode ver na imagem acima, a VPC padrão conta com múltiplas subnets, uma para zona de disponibilidade daquela região. Os recursos nessa subnet pública se conectam com a internet através de um Internet Gateway. Vamos entender melhor o que é isso em seguida.

A VPC padrão também conta com um espaço de endereçamento de IPs privados já definido (172.31.0.0/16 nesse exemplo). Quando você cria uma VPC do zero, primeiramente você precisa definir esse espaçamento de rede. Você precisa utilizar um range de IPs privados para isso, como por exemplo 10.0.0.0/8, 172.16.0.0/16, 192.168.0.0/24.

Rede de Computadores - Protocolo TCP/IP
Curso de Rede de Computadores - Protocolo TCP/IP
CONHEÇA O CURSO

Diferentes formas de configuração de uma VPC

Embora você possa utilizar a VPC padrão, essa configuração é composta somente por subnets públicas, que permitem acesso direto a partir da internet. Assim como você precise utilizar um espaçamento de rede específico para integrar com uma rede on-premise.

Para reforçar a segurança do seu ambiente, é recomendado configurações diferentes, como incluir subnets privadas sem acesso direto à internet, para serviços como banco de dados, que só serão acessados por sua aplicação, como também para permitir acesso através de Virtual Private Network (VPN).

Em seguida, conheceremos alguns componentes que fazem parte da VPC para entender melhor como implementar essas configurações.

Componentes da VPC

Para atender as diferentes configurações possíveis, como aquelas com subnets privadas ou com acesso a redes on-premise através de um VPN gateway, precisamos conhecer os componentes que possibilitam isso.

  • Subnets: as subnets são espaços de rede menores que fazem parte da VPC. Como visto anteriormente, essas podem ser ou subnets privadas ou subnets públicas, dependendo da configuração desejada. Dependendo do tipo de subnet implementada, o acesso à internet dessa subnet é feito de uma forma diferente, seja por um Internet Gateway ou NAT Gateway.

  • Internet Gateway: o Internet Gateway é responsável por conectar a VPC com a internet. Todo tráfego de entrada e saída externo da VPC passa por ele. Ele é a forma de conexão utilizada por subnets públicas. Cada VPC pode ter no máximo um Internet Gateway.

  • NAT Gateway: já para subnets privadas, você precisa utilizar um NAT Gateway para fornecer acesso a internet para recursos nesses subnets. Ele é utilizado para tráfego de saída, expondo um único endereço IP para os endereços externos. O NAT Gateway é provisionado em uma subnet pública, e todo o tráfego externo das subnets privadas passa por ele.

  • Route Table: o Route Table é responsável por definir o comportamento das conexões de uma subnet para o destino correto. É ele que direciona o tráfego externo (0.0.0.0/0) de conexões da internet em subnets públicas para o Internet Gateway, ou que direciona o tráfego externo de uma subnet privada para um NAT gateway.

Podemos ver no diagrama abaixo como esses componentes se integram para uma configuração com subnet pública e privada:

VPC com subnet privada

Conclusão

Em resumo, nesse artigo tivemos uma breve introdução sobre a VPC. Conhecemos seus principais componentes e qual a importância de cada um. Nas próximas semanas será lançado o curso AWS – Ferramentas de Rede e Distribuição de Conteúdo – Fundamentos que irá abordar com muito mais detalhes esse serviço.

Amazon Web Services (AWS) - RDS - Fundamentos
Curso de Amazon Web Services (AWS) - RDS - Fundamentos
CONHEÇA O CURSO

Fiquem ligados e nos sigam nas nossas redes sociais, como Twitter, Instagram, Facebook e LinkedIn. Assim que esse curso for lançado você saberá em primeira mão!

Monitorar servidor em tempo real com o Netdata

O Netdata é uma ferramenta opensource para monitoramento em tempo real de sistemas baseados em Unix. Ela possui uma infinidade de coletores e métricas sobre o uso dos recursos do sistema como: memória, CPU, rede, operações de escrita/leitura no disco etc.

Painel do Netdata

Não obstante, a ferramenta também disponibiliza coletores para aplicações de bancos de dados, servidores web (como o Nginx) entre outros.

A melhor parte de usar o Netdata é que os resultados são imediatos, sem muitas configurações. Você instala e já começa a visualizar os dados coletados. Com o tempo você personaliza as configurações que julgar serem importantes pro seu caso de uso.

Esse artigo não tem o objetivo de teorizar todos os recursos do Netdata, para isso, você pode consultar o site oficial e a sua vasta documentação. A intenção aqui é ser um guia rápido de instalação para que você consiga monitorar o seu servidor em tempo real.

Você pode testar a interface fornecida pelo Netdata e ver as informações padrões que ela oferece através dessa demonstração: https://london.my-netdata.io/

Amazon Web Services (AWS) - EC2 - Fundamentos
Curso de Amazon Web Services (AWS) - EC2 - Fundamentos
CONHEÇA O CURSO

Instalando o Netdata

Existem diversos métodos de instalação do Netdata, sendo o mais simples, o que usa a ferramenta oficial de instalação automática e ela suporta todas as distribuições Linux.

Basta executar no seu servidor:

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

O processo pode demorar alguns minutos. Muitas das coisas serão compiladas.

É isso. Tá tudo pronto. Na pós-instalação ele inicia o agente e você pode validar isso:

sudo service netdata status

Se exibir active (running), está tudo no ponto:

Netdata service running

Caso ele não tenha sido iniciado, você pode tentar forçar essa inicialização:

sudo service netdata start

O Netdata abre a porta 19999 para acesso à sua interface web, você pode acessá-lo assim http://seuservidor.com:19999/. Mas não é uma boa coisa deixar isso público para todas as pessoas que entrarem em seu site. Vamos restringir esse acesso para localhost.

Restringindo o acesso à localhost

Isso pode ser feito editando o arquivo /etc/netdata/netdata.conf e na seção [web] remover o comentário # da linha abaixo e definir o valor dela para o IP local:

[web]
    bind to = 127.0.0.1

Depois de cada alteração nos arquivos de configuração do Netdata, é preciso reiniciá-lo

sudo service netdata restart

Estratégias para acesso à interface do Netdata

Agora que bloqueamos o acesso ao socket do Netdata apenas para localhost, temos que definir por onde vamos visualizar os dados e as métricas coletadas do servidor. Existem duas principais estratégias:

  • 1) Através do seu servidor mesmo, criando um proxy reverso no Nginx e definindo uma senha para acessá-lo na web. Por exemplo, você poderia acessar assim: www.seusite.com.br/netdata ou netdata.seusite.com.br;
  • 2) Utilizando o Netdata Cloud, que é a forma mais simples (e é grátis). O Netdata Cloud permite coletar em tempo real os dados e métricas do servidor e organizá-los em espaços e salas de uma forma descentralizada. O Netdata Cloud funciona apenas no modo leitura e toda a comunicação nas duas pontas é feita via uma conexão segura.

Depois de se cadastrar no Netdata Cloud, ele pedirá um nome para o espaço onde as salas de nós monitorados ficarão agrupadas. Você pode colocar o nome que quiser:

Criar o primeiro espaço no netdata

Na tela seguinte, ele pedirá para criar uma “War Room”, que basicamente é uma forma de agrupar nós comuns que você estará monitorando. Por exemplo, se você tem 2 ou 3 servidores EC2 para monitorar, uma possível sala (war room) poderia se chamar EC2:

Netdata Cloud - War Room

Na próxima etapa, é hora de adicionar o nó do seu servidor:

Adicionar nó no Netdata

Em “Rooms” selecione a sala que você acabou de criar. Em seguida é só copiar o comando indicado e executar no servidor onde o agente do Netdata foi instalado. Só avançar até chegar na tela principal, onde o seu nó estará listado. Um exemplo de uma sala com vários nós:

Netdata nodes

É possível adicionar N nós e N salas no Netdata Cloud. A partir desse momento, é só você entrar no nó e usufruir das informações fornecidas por ele.

O que mais posso fazer?

Não existe lugar melhor para consultar os recursos, configurações e opções que a própria documentação do Netdata. Portanto, recomendo enormemente que você dê uma atenção especial a ela.

O que mais pode ser feito no Netdata?

  • Personalização de alertas e configuração de notificações para serem enviadas no seu Telegram, Slack, E-mail, SMS etc;
  • Coletores de outros serviços e aplicações;
  • Outras features e características você pode visualizar na documentação oficial;

Em um próximo artigo veremos como configurar o Netdata para monitorar a stack PHP-FPM e Nginx.

Até a próxima!

Amazon Web Services (AWS) - Fundamentos
Curso de Amazon Web Services (AWS) - Fundamentos
CONHEÇA O CURSO

AWS CLI v2: confira as novidades da nova versão

O AWS CLI v2 é uma ferramenta em linha de comando capaz de gerenciar recursos na AWS. Com ela é possível listar todas as EC2 no seu ambiente, ou até mesmo criar um novo banco de dados com RDS com poucos comandos. Primeiramente, para conhecer um pouco mais sobre o AWS CLI, veja como pode ser feita a instalação e configuração da primeira versão.

Amazon Web Services (AWS) - Fundamentos
Curso de Amazon Web Services (AWS) - Fundamentos
CONHEÇA O CURSO

Novidades do AWS CLI v2

O AWS CLI v2 é a nova versão da ferramenta em linha de comando capaz de gerenciar seus recursos na AWS. Lançado em Fevereiro de 2020, o AWS CLI v2 conta com algumas novidades, como um novo script de instalação, novas formas de configuração e ao mesmo tempo um melhor suporte ao autocomplete.

A novidade ao ponto de vista da sua instação está eu não ter nenhuma dependência com o Python instalado na sua máquina. Agora o AWS CLI inclui internamente uma versão suportada do Python, configurado de forma isolada para evitando qualquer conflito com os pacotes já instalados.

Por fim, o AWS CLI v2 conta também com o auto-prompt e os assistentes. Com isso é possível criar seus recursos sem saber de cabeça todos os parâmetros necessários, bem como criar recursos mais complexos, que antes envolveriam um script com vários comandos.

Para utilizar o auto-prompt, basta inserir o parâmetro --cli-auto-prompt logo após o comando que você tem dúvida quais são os parâmetros necessários:

Demonstração do auto-prompt

Já para utilizar o assistente, utilize o subcomando wizard em determinados comandos do AWS CLI. No momento temos assistentes para os comandos configure, iam, dynamodb e lambda:

Demonstração do Wizard

Amazon Web Services (AWS) - Fundamentos
Curso de Amazon Web Services (AWS) - Fundamentos
CONHEÇA O CURSO

Instalação e configuração no Linux

Vamos agora acompanhar como pode ser feita a instalação e configuração do AWS CLI v2 em um sistema Linux. Antes de mais nada, caso você já tenha instalado o AWS CLI na versão 1 no seu ambiente, é recomendado que você faça a desinstalação:

# Instalação pelo pip
pip uninstall awscli

# Instalação pelo bundled installer
sudo rm -rf /usr/local/aws
sudo rm /usr/local/bin/aws

Agora, você pode realizar a instalação a partir do seguinte script:

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

Logo depois, verifique se o AWS CLI está disponível:

> aws --version
aws-cli/2.0.17 Python/3.7.3 Linux/4.19.104-microsoft-standard botocore/2.0.0dev21

Por último, fazer a configuração do AWS CLI com sua access e secret key ficou mais fácil. Ao gerar suas chaves no console da AWS, é possível baixar um arquivo CSV contendo essas credenciais. O AWS CLI v2 consegue reconhecer diretamente esse arquivo e se configurar usando o comando abaixo:

aws configure import --csv file://credentials.csv

Com isso, você não precisa copiar e colar manualmente suas chaves, a princípio basta você baixar o CSV de credenciais e apontar para aquele caminho.

Linux - Fundamentos para desenvolvedores
Curso de Linux - Fundamentos para desenvolvedores
CONHEÇA O CURSO

Conclusão

Nesse artigo conhecemos as principais novidades disponíveis no AWS CLI v2. Além de entregar uma ferramenta isolada das dependências da sua máquina, você ainda tem novas funcionalidades como o auto-prompt e os assistentes. Vale lembrar que os scripts que você já tinha com o AWS CLI v1 continuam funcionando com o AWS CLI v2, dessa forma você pode garantir a retrocompatibilidade.

Fiquem ligados e nos sigam nas nossas redes sociais, como Twitter, Instagram, Facebook e LinkedIn para receber mais dicas e novidades da TreinaWeb!

O que é AWS Lambda?

O AWS Lambda é um serviço de computação que executa suas aplicações em um modelo serveless, onde você pode desenvolver sem a necessidade de se preocupar com servidores.

É possível utilizar as principais linguagens do mercado, como Java, Pyhton, Node.JS, .NET Core, e Go, podendo expandir essa lista para outras linguagens utilizando um custom Lambda Runtime, adicionando suporte até para COBOL!

Além disso, com o Lambda você só paga pelo o que você consumir para executar sua função. Não é necessário pagar por capacidade ociosa e, por fim você pode publicar sua aplicação de forma mais ágil. Vamos entender a seguir como e quando utilizar o Lambda pode ser interessante.

Amazon Web Services (AWS) - Fundamentos
Curso de Amazon Web Services (AWS) - Fundamentos
CONHEÇA O CURSO

O que é serverless?

Antes de falarmos sobre Lambda, vamos esclarecer o que é Serveless. Muitos já devem ter ouvido falar sobre esse termo associando ao pensamento de executar sem precisar de um servidor.

Na verdade, serverless é um modelo de serviço de nuvem onde você não precisa se preocupar com a infraestrutura da sua aplicação. Esse servidor ainda existe, entretanto ele é totalmente gerenciado pelo provedor de nuvem, te permitindo focar somente na lógica do seu negócio.

Um diferencial do Serveless é que você paga somente o que sua aplicação utilizar. Ao contrário de uma EC2 tradicional, você pode ser cobrado pelo tempo ocioso nessa EC2, em momentos onde sua aplicação não tem nenhuma atividade.

Além do Lambda, temos outros exemplos de serviços da AWS que funcionam no modelo de Serveless. Alguns exemplos são o S3 para armazenamento de arquivos, o AWS RDS Aurora e DynamoDB para banco de dados, e SNS e SQS, serviços usados para gerenciar filas e mensageiria.

Amazon Web Services (AWS) - Ferramentas de Rede e Distribuição de Conteúdo – Fundamentos
Curso de Amazon Web Services (AWS) - Ferramentas de Rede e Distribuição de Conteúdo – Fundamentos
CONHEÇA O CURSO

Características do Lambda

Agora que já conhecemos um pouco mais sobre Serveless, podemos discutir quais as principais características do Lambda.

Com o Lambda podemos construir aplicações baseadas em pequenas funções, com uma responsabilidade única iniciada a partir de eventos. Essa é a principal diferença com uma aplicação web, pois nosso código implementa somente o que é necessário para ser executado. Podemos por exemplo, responder a uma requisição HTTP, ou redimensionar uma imagem salva no S3, ou processar uma mensagem enviada numa fila do SQS, com o mínimo de código possível.

Entretanto, para aproveitar de modo efetivo esse serviço, vamos levantar algumas considerações sobre o Lambda.

Quais os benefícios do Lambda?

Ao desenvolver uma solução com Lambda, primeiramente temos que conhecer quais serão os benefícios que podemos observar:

  • Quantidade de código reduzida: Ao contrário de uma aplicação web MVC, onde temos que configurar conexões com banco de dados, configurar rotas, entre outros, podemos ir direto ao ponto e executar só o que é necessário no Lambda. O gerenciamento de rotas, bem como conexões com o banco de dados, e outras configurações são delegados para outros serviços, como um API Gateway, e são configurados fora do seu código.

  • Escalabilidade instantânea: Para os casos onde nossa função recebe um pico de acessos, é possível escalar automaticamente sua função para atender um número maior de clientes. Como a AWS é responsável por gerenciar nossa infraestrutura, podemos delegar essa responsabilidade sem precisar se preocupar alocar previamente mais servidores.

  • Sem cobrança de recursos ociosos: Para soluções com tráfego pequeno ou pouco constante, temos um grande potencial economia, pois com o Lambda nós não precisamos pagar por recursos ociosos de uma EC2, mesmo com a menor máquina possível.

Quando não utilizar Lambda?

Contudo existem algumas situações onde não é interessante utilizar Lambda. A primeira situação é rodar uma aplicação web tradicional. Você até consegue fazer isso, mapeando os eventos enviados com uma requisição web que sua aplicação utiliza, porém você estará subutilizando o potencial do Lambda, publicando uma aplicação completa dentro de uma única função e executando trechos de código que podem ser redundantes, como a configuração de rotas.

Processos de longa duração também não são recomendados. O tempo limite de execução de uma função é de 15 minutos. Isso pode acontecer ao processar um grande volume de dados de uma só vez. O ideal nesse caso é quebrar esse processo em partes menores, e executar somente uma unidade por função, ao invés de processar várias unidades de uma vez.

Uma função lambda também não tem acesso a um disco permanente. A manipulação de arquivos pelo lambda acontece em um disco efêmero e de baixa capacidade, tornando impossível manipular arquivos muito grandes numa função. Dessa forma é necessário recorrer a um serviço de armazenamento externo como o S3.

Por fim, temos que considerar o vendor lock-in. Em outras palavras, ao desenvolver uma função lambda não será possível migrar o código para outro provedor no futuro. Para migrar o Lambda para Azure Functions, por exemplo, posteriormente você precisa reimplementar toda a lógica que trata os eventos e suas integrações com outros serviços. Praticamente, você irá criar uma nova função.

Conclusão

Essa foi uma breve introdução sobre o AWS Lambda. Vimos aqui algumas vantagens e quando utilizar esse serviço que é bastante famoso na AWS.

Confira o curso AWS Lambda Fundamentos para conhecer com muito mais detalhes esse serviço.

Amazon Web Services (AWS) - Lambda - Fundamentos
Curso de Amazon Web Services (AWS) - Lambda - Fundamentos
CONHEÇA O CURSO

Fiquem ligados e nos sigam nas nossas redes sociais, como Twitter, Instagram, Facebook e LinkedIn. Assim que esse curso for lançado você saberá em primeira mão!

O que é AWS S3?

O AWS S3 (Simple Storage Service) é um serviço de armazenamento de arquivos, também chamados de objetos ou blobs, com foco em escalabilidade, disponibilidade, segurança e performance, tudo isso com um custo extremamente acessível.

O AWS S3 é um serviço distribuído globalmente dentro da sua conta da AWS, com uma organização em buckets regionais. Isso quer dizer que, diferente das EC2, VPC, e RDS, ao acessar o S3 pelo console da AWS, teremos uma visão global do nosso ambiente, ao invés de uma visão de uma única região.

Como comentado anteriormente, o AWS S3 se destaca pelo seu custo extremamente acessível. Você só paga pelo armazenamento e transferência de saída dos seus arquivos, com um custo aproximado de cinco centavos para cada gigabyte armazenado, o que é muito mais barato se comparado com o custo de disco EBS de uma EC2 tradicional.

Amazon Web Services (AWS) - Fundamentos
Curso de Amazon Web Services (AWS) - Fundamentos
CONHEÇA O CURSO

Quando usar o S3?

O S3 é um serviço de armazenamento bastante flexível, que suporta diversos casos de uso, como por exemplo:

  • Armazenamento de arquivos para aplicações web: como arquivos CSS e JavaScript do frontend da sua aplicação, e imagens enviadas pelos seus usuários via upload.

  • Arquivos de backups e logs: você pode armazenar arquivos privados, como logs de alguma aplicação, ou até mesmo backups de longo prazo do seu banco de dados, usados para fins legais.

  • Archive para um grande volume de dados: é possível armazenar muita coisa no S3. É possível armazenar objetos com até 5 terabytes e um bucket suporta um número ilimitado de objetos. Para grandes volumes de dados você pode utilizar o S3 Glacier e economizar ainda mais o custo de armazenamento.

  • Replicação de dados entre diferentes regiões: para aplicações distribuídas globalmente, você pode replicar buckets inteiros em diferentes regiões da AWS com um Batch Operation.

  • Hospedagem de sites estáticos: se você tem uma aplicação web que consiste só em arquivos estáticos, ou uma Single Page Applications (SPA), você pode utilizar somente o S3 para hospedar essa aplicação em completo.

Amazon Web Services (AWS) - Elastic Beanstalk - Fundamentos
Curso de Amazon Web Services (AWS) - Elastic Beanstalk - Fundamentos
CONHEÇA O CURSO

O que o S3 não faz

Embora seja um serviço flexível, o S3 não é indicado para todos os casos de uso. Existem serviços mais apropriados dentro da própria AWS para alguns cenários.

Com o S3 não temos uma hierarquia de arquivos. Isso é a principal diferença ao comparar o S3 com nosso disco local. Imagine que no S3 todos os arquivos são salvos em um único diretório. Não é possível distinguir se os seus arquivos estavam armazenados numa determinada pasta ou não.

Visualmente você até acha que existe uma organização por pastas, mas na verdade o que você está vendo é um separador lógico no nome do seu arquivo. Se a sua aplicação depende de operações em diretórios, como listar ou mover diretórios inteiros, o S3 pode não ser a melhor alternativa.

Você também não tem suporte direto ao Hadoop ou HDFS. Essas são soluções muito utilizadas em Big Data e você não consegue fazer a ingestão de dados do S3 para um cluster Hadoop com HDFS. Para isso você pode utilizar o Amazon EMR, um serviço especializado para data lakes com suporte a HDFS e hierarquia de diretórios. Uma curiosidade, o EMR utiliza o S3 por debaixo dos panos, entregando uma camada de compatibilidade com HDFS, mantendo um preço bem acessível.

Com o S3 você também não pode montar um bucket como um disco numa EC2 ou utilizá-lo como um compartilhamento de arquivos de rede. Para usar o S3 você pode utilizar APIs REST, o AWS CLI, ou até mesmo as SDKs disponíveis para diversas linguagens. Para esses casos de uso, prefira outros serviços, como o EBS para montagem de discos, ou o EFS para o compartilhamento de arquivos em rede.

Amazon Web Services (AWS) - EC2 - Fundamentos
Curso de Amazon Web Services (AWS) - EC2 - Fundamentos
CONHEÇA O CURSO

Conclusão

Essa foi uma breve introdução sobre o AWS S3. Vimos aqui algumas vantagens e quando utilizar esse serviço que é um dos principais da AWS.

Confira o curso AWS S3 Fundamentos para conhecer com muito mais detalhes esse serviço.

Amazon Web Services (AWS) - S3 - Fundamentos
Curso de Amazon Web Services (AWS) - S3 - Fundamentos
CONHEÇA O CURSO

Fiquem ligados e nos sigam nas nossas redes sociais, como Twitter, Instagram, Facebook e LinkedIn, para receber dicas e saber em primeira mão quando novos cursos forem lançados!

Primeiros passos com o Amazon Aurora

O Amazon Aurora é um banco de dados relacional da AWS compatível com MySQL e PostgreSQL. Esse banco de dados foi construído pensando em alta disponibilidade e escalabilidade. Nesse artigo vamos entender os benefícios do Amazon Aurora e como podemos criar nosso primeiro cluster.

Benefícios do Amazon Aurora

Anunciado em 2014, o Amazon Aurora é um banco de dados relacional oferecido como um serviço na AWS. O Amazon Aurora busca entregar um banco de dados com features e performance de soluções comerciais mas com um custo de uso de um banco de dados open source, não requerendo o uso de licenças para seu uso. Você só paga pela infraestrutura ao provisionar o Amazon Aurora.

Apesar de ser oferecido juntamente com o Relational Database Service (RDS), o Aurora tem um funcionamento diferente das outras engines disponíveis no serviço. Além das funcionalidades já oferecidas com as outras engines, como suporte a múltiplas availability zones, réplicas de leitura e backup automático, o Aurora estende esses recursos e adiciona suporte a bancos de dados globais replicados em diferentes regiões da AWS, réplicas que permitem escrita de dados e até mesmo instâncias serveless, o que economiza bastante a conta com bancos de dados que tem grande tempo de ociosidade ou pouco uso.

Amazon Web Services (AWS) - EC2 - Fundamentos
Curso de Amazon Web Services (AWS) - EC2 - Fundamentos
CONHEÇA O CURSO

Isso é possível graças ao funcionamento da camada de storage do Amazon Aurora. Todas as réplicas e a instância principal compartilham de um mesmo storage replicado, reduzindo drasticamente a latência necessária para atividades de replicação entre as instâncias, se comparado com os mecanismos de replicação nativa dos bancos de dados:

Arquitetura de storage do Aurora

Isso permite ao Amazon Aurora alcançar números impressionantes de escalabilidade e performance. Segundo a Amazon, o Aurora chega a ser cinco vezes mais rápido que um banco de dados rodando MySQL tradicional e até três vezes mais rápido que o PostgreSQL. Além disso, o Amazon Aurora suporta de até 15 replicas de leitura, tem um RTO (Recovery time objective) de um minuto e o tempo replicação global entre as regiões da AWS é de aproximadamente um segundo.

Tendo em vista todos esses benefícios, podemos pelo menos cogitar seu uso com aplicações que já usam MySQL ou PostgreSQL, não é mesmo? Para ajudar nesse processo vamos aprender como criar nosso primeiro cluster com Amazon Aurora.

Criando um cluster do Amazon Aurora

Para criar nosso cluster de Amazon Aurora vamos utilizar o AWS CLI. É preciso que você instale essa ferramenta na sua máquina e configure junto a sua conta da AWS. Confira como instalar e configurar o AWS CLI aqui no nosso blog.

Amazon Web Services (AWS) - Fundamentos
Curso de Amazon Web Services (AWS) - Fundamentos
CONHEÇA O CURSO

A primeira coisa que precisamos fazer é criar o security group que será associado ao nosso cluster:

aws ec2 create-security-group --group-name sg_aurora --description "Allow MySQL Aurora access from internet"
aws ec2 authorize-security-group-ingress --group-name sg_aurora --protocol tcp --port 3306 --cidr 0.0.0.0/0
aws ec2 describe-security-groups --group-names sg_aurora

# salva o id do security group para ser usado a seguir
sg_id=$(aws ec2 describe-security-groups --group-names "sg_aurora" --query "SecurityGroups[0].GroupId" --output text)

O security group vai funcionar como uma camada de segurança extra no nível da rede. Configure a porta de configuração apropriada (3306 para MySQL e 5432 para o PostgreSQL) e o mais importante, o CIDR permitido. Para fins didáticos, esse security group vai aceitar conexões de qualquer lugar da internet, porém é altamente recomendado que você limite para o endereçamento da sua rede, por exemplo.

O próximo passo é criar o cluster do Amazon Aurora. No cluster será possível obter as informações para fazer a conexão com o Amazon Aurora, bem como suas credenciais de acesso e versão do banco de dados compatível:

aws rds create-db-cluster \
--db-cluster-identifier sample-cluster-mysql-aurora \
--engine aurora \
--engine-version 5.6.mysql_aurora.1.22.2 \
--master-username username \
--master-user-password password \
--vpc-security-group-ids $sg_id

Por fim, enquanto nosso cluster é criado, podemos adicionar nossa primeira instância de banco de dados. Utilize o comando abaixo, observando o tamanho de instância desejado:

aws rds create-db-instance \
--db-instance-identifier sample-instance \
--db-cluster-identifier sample-cluster-mysql-aurora \
--engine aurora \
--db-instance-class db.t3.small

Com isso, após aguardar alguns minutos, nosso cluster estará criado e pronto para ser utilizado:

Cluster RDS sendo criado no console

Referências e mais informações

Vimos aqui como podemos criar nosso primeiro cluster com Amazon Aurora, mas existem muitas outras configurações que você pode explorar para criar o seu banco de dados. Abaixo você pode conferir a documentação da AWS que te mostra algumas variações de como você pode criar seu cluster, bem como as referências dos comandos utilizados:

Como instalar e configurar o AWS CLI

O AWS CLI é uma ferramenta em linha de comando capaz de gerenciar recursos na AWS. Com ela é possível listar todas as EC2 no seu ambiente, ou até mesmo criar um novo banco de dados com RDS com poucos comandos, tudo isso sem precisar acessar o console da AWS. Nesse artigo vamos acompanhar como é o processo de instalação e configuração do AWS CLI.

Instalação

Por ser uma ferramenta desenvolvida em Python e recentemente ter seu código fonte aberto, o AWS CLI pode rodar em qualquer sistema, seja uma distribuição Linux, macOS ou Windows. Para sua instalação no Linux ou no macOS podemos utilizar o pip, gerenciador de dependência do Python para instalar o AWS CLI com alguns poucos comandos.

Para sistemas Windows, você pode utilizar um instalador que, além de instalar o AWS CLI, inclui uma versão do Python compatível com o AWS CLI e também adiciona o caminho do executável na variável de ambiente de PATH do seu sistema, deixando tudo pronto para usar.

Amazon Web Services (AWS) - Fundamentos
Curso de Amazon Web Services (AWS) - Fundamentos
CONHEÇA O CURSO

Para instalar o AWS CLI nos sistemas macOS e Linux, você precisa atender alguns requisitos mínimos. O AWS CLI requer pelo menos o Pyhton nas versões 2.7 ou 3.4 e versões superiores, e também que o pip esteja instalado. Você pode verificar a versão do Pyhton e do pip instalados no seu sistema utilizando os comandos:

$ python --version
Python 3.6.9

$ pip --version
pip 9.0.1 from /usr/lib/python3/dist-packages (python 3.6)

Podemos ver aqui que os requisitos foram atendidos. Em alguns sistemas, o Python e o pip podem estar disponíveis com os binários python3 e pip3. Caso esse seja seu caso, lembre-se de executar os comandos a seguir substituindo pelo comando disponível no seu sistema.

Para instalar o AWS CLI, vamos rodar então o comando do pip abaixo:

pip install awscli --user

Depois de instalado, é preciso adicionar o caminho onde o pip salva os binários no PATH do sistema. Isso vai variar dependendo do shell que você estiver utilizando. No meu caso, estudo usando o Bash com o Ubuntu 18.04, então vou adicionar a seguinte linha no final do meu arquivo ~/.bashrc:

export PATH=~/.local/bin:$PATH

Depois de recarregar o .bashrc (isso pode ser feito com source ~/.bashrc) ou abrir novamente o terminal, o AWS CLI já estará disponível para ser executado:

$ aws --version
aws-cli/1.17.4 Python/3.7.4 Linux/4.14.133-113.105.amzn2.x86_64 botocore/1.13

Para sistemas Windows, basta baixar e utilizar o instalador disponível nesse link e após executar o instalador, o AWS CLI estará disponível tanto no cmd como no PowerShell:

C:\> aws --version
aws-cli/1.17.4 Python/3.7.4 Windows/10 botocore/1.13

Configuração

Agora que temos o AWS CLI instalado, vamos configurar a linha de comando junto com a nossa conta da AWS. Vamos precisar de um access key e uma secret key que pode ser obtido a partir do console da AWS.

Para isso, faça o login com seu usuário no console da AWS e no canto superior direito, procure seu nome de usuário e selecione a opção My Security Credentials:

Menu para acessar My Security Credentials

Em seguida, procure a opção Access keys e gere uma nova access key para utilizar com o AWS CLI:

Opção para gerar uma nova access e secret key

É muito importante que você não compartilhe com ninguém esse access e secret key, pois com essas informações, qualquer um terá os mesmos privilégios que o seu usuário possui para executar ações dentro da AWS, incluindo criar recursos ou até mesmo excluir tudo que tem no seu ambiente, o que não é uma boa idéia.

Depois de gerar o access e secret key, você pode configurá-lo com o comando abaixo:

$ aws configure
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name [None]: us-west-2
Default output format [None]: json

Esse comando vai criar um diretório no home do seu sistema chamado .aws com dois arquivos: config e credentials. Esse último arquivo terá as informações que você acabou de utilizar com o comando aws configure:

# ls ~/.aws
config  credentials

# cat ~/.aws/credentials
[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Ressaltando, é importante você também proteger esses arquivos que estão salvos no seu usuário, pois a partir deles também é possível ter ao access e secret key da sua conta.

Amazon Web Services (AWS) - EC2 - Fundamentos
Curso de Amazon Web Services (AWS) - EC2 - Fundamentos
CONHEÇA O CURSO

Passo a passo

Veja no vídeo abaixo o passo a passo sobre como instalar e configurar o AWS CLI. Esse vídeo mostra na pratíca todos os passos descritos aqui nesse artigo:

Publicando uma aplicação .NET Core 3.0 no AWS Elastic Beanstalk

Hoje em dia uma realidade muito comum é utilizar soluções em nuvem para hospedar nossas aplicações. Provedores como a AWS facilitam esse processo oferecendo serviços especializadas para hospedar nossas soluções que se encaixam do modelo de Plataforma como um Serviço (PaaS).

Um desses serviços é o Elastic Beanstalk, que tem suporte nativo a várias linguagens de programação, como Java, Python, NodeJS, PHP, e inclusive .NET Core. Nesse artigo vamos aprender como publicar e configurar um projeto desenvolvido em ASP.NET Core 3.0 no Elastic Beanstalk.

Elastic Beanstalk

O Elastic Beanstalk é um serviço do tipo Plataforma como um Serviço da AWS. Através dele é possível criar ambientes escaláveis e com alta disponibilidade para aplicações web de forma simples e sem muitos conhecimentos aprofundados sobre infraestrutura. Isso o faz uma ótima solução para times pequenos que não tem especialistas em infraestrutura para gerenciar um ambiente na nuvem.

O Elastic Beanstalk suporta inúmeras linguagens, desde Java, NodeJS, PHP, Pyhton, até aplicações desenvolvidas com .NET Core. Recentemente foi adicionado suporte a versão 3.0 do .NET Core e em breve teremos suporte também ao .NET Core 3.1.

Requisitos para criar um projeto .NET Core 3.0

Vamos criar nesse artigo uma nova aplicação .NET Core 3.0 utilizando o Ubuntu 18.04. É preciso que você tenha o .NET Core SDK instalado na sua máquina.

Para instalar o .NET Core SDK, execute os comandos abaixo:

wget -q https://packages.microsoft.com/config/ubuntu/18.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb

sudo add-apt-repository universe
sudo apt-get update
sudo apt-get install apt-transport-https
sudo apt-get update
sudo apt-get install dotnet-sdk-3.0

Mais detalhes estão disponíveis na documentação oficial da Microsoft.

Criar uma aplicação ASP.NET Core MVC

Para acompanhar a publicação de uma aplicação no Elastic Beanstalk, vamos criar uma nova aplicação em ASP.NET Core MVC simples com o comando abaixo:

dotnet new mvc -o AspNetMvc

Isso irá criar um projeto na pasta AspNetMvc. Por enquanto não vamos alterar nada no projeto criado, em seguida veremos o que precisa ser configurado no seu projeto para publicá-lo no Elastic Beanstalk.

Publicando para o Elastic Beanstalk

O processo de publicação para o Elastic Beanstalk consiste em criar um build do nosso projeto e empacotá-lo num arquivo zip contendo algumas informações adicionais. Felizmente esse processo pode ser automatizado utilizando o AWS Extensions for .NET CLI. Sua instalação é feita como um utilitário global na sua máquina, assim você precisa instalá-lo só na primeira vez.

Para instalar o AWS Extensions for .NET CLI, execute o comando abaixo.

dotnet tool install -g Amazon.ElasticBeanstalk.Tools

Isso permitirá que você utilize o comando dotnet eb para trabalhar com o Elastic Beanstalk diretamente da linha de comando. Caso esse comando não funcione, verifique se o diretório do .NET CLI Tools está adicionado na variável de PATH da sua máquina.

export PATH="$PATH:~/.dotnet/tools"

Antes de efetuar a publicação da sua aplicação, você precisa configurar as credenciais da sua conta da AWS. Caso você tenha o AWS CLI instalado, execute o comando aws configure e preencha com as informações solicitadas:

~/
> aws configure
AWS Access Key ID [None]: ********************
AWS Secret Access Key [None]: ****************************************
Default region name [None]: us-east-1
Default output format [None]: json

Você também pode gerar um arquivo em $HOME/.aws/credentials com os seguintes conteúdo:

[default]
aws_access_key_id = ********************
aws_secret_access_key = ****************************************
Amazon Web Services (AWS) - Fundamentos
Curso de Amazon Web Services (AWS) - Fundamentos
CONHEÇA O CURSO

Por fim, você pode publicar sua aplicação usando o comando dotnet eb deploy-environment. Preencha as perguntas seguintes com o nome da application e environment desejados e, casos eles ainda não existam no Elastic Beanstalk, eles serão criados para você:

~/Code/AspNetMvc (master) ✔
> dotnet eb deploy-environment
Amazon Elastic Beanstalk Tools for .NET Core applications (3.2.0)
Project Home: https://github.com/aws/aws-extensions-for-dotnet-cli

Enter Elastic Beanstalk Application: (The name of the Elastic Beanstalk application.)
aspnetcore-app
Enter Elastic Beanstalk Environment: (The name of the Elastic Beanstalk environment.)
aspnetcore-dev
Enter AWS Region: (The region to connect to AWS services, if not set region will be detected from the environment.)
us-east-1

Para facilitar, você pode criar um arquivo chamado aws-beanstalk-tools-defaults.json com as configurações padrão utilizadas pelo dotnet eb

{
    "region": "us-east-1",
    "application": "aspnetcore-app",
    "environment": "aspnetcore-dev",
    "configuration": "Release"
}

Ao final desse processo, será exibido uma url para acessar o ambiente recém criado. Mas ainda não terminamos, agora vamos aprender como utilizar as configurações de ambiente presentes no Elastic Beanstalk.

Configurações de ambiente

Em uma aplicação .NET Core podemos definir valores dentro de appsettings.json e utilizá-los dentro do nosso código. Como exemplo, podemos adicionar uma configuração chamada Environment que irá conter o nome do nosso ambiente na home page do projeto. Para isso, vamos alterar alguns arquivos do nosso projeto.

No appsettings.json, adicionei a seguinte configuração:

"Environment": "Local"

Na minha view principal exibo essa mensagem:

@using Microsoft.Extensions.Configuration
@inject IConfiguration Configuration

<p>@Configuration["Environment"]</p>

Com isso, ao rodar dotnet run essa mensagem será exibida:

Por padrão, o .NET Core também vai carregar as variáveis de ambiente do sistema e seus valores podem sobrescrever o que está definido no appsettings.json. Ao rodar novamente nossa aplicação, mas alterando a variável de ambiente na sua execução, a mensagem será alterada:

~/Code/AspNetMvc
> Environment=Dev dotnet run

Configurações de ambiente no Elastic Beanstalk

Infelizmente o Elastic Beanstalk não faz isso por padrão com o .NET Core, o que pode frustrar alguns desenvolvedores (passei por isso na pele, nesse caso…), pois esse comportamento funciona em outras linguagens e plataformas do Elastic Beanstalk e só no .NET Core isso é diferente. Por ser um problema de longa data, presente desde a primeira versão do .NET Core disponível no Elastic Beanstalk, de acordo com essa pergunta no Stack Overflow, não acredito que esse problema será resolvido em breve.

Para contornar esse problema, podemos customizar o carregamento de configurações da nossa aplicação para ele poder consumir as configurações de ambiente do Elastic Beanstalk.

Instale a dependência TTRider.Aws.Beanstalk.Configuration no seu projeto executando o comando abaixo:

dotnet add package TTRider.Aws.Beanstalk.Configuration

Altere o Program.cs na definição do host builder, adicionando o seguinte método:

.ConfigureAppConfiguration((hostingContext, config) =>
{
    config.AddBeanstalkParameters();
})

No meu caso, o arquivo Program.cs ficou assim:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using TTRider.Aws.Beanstalk.Configuration;

namespace AspNetMvc
{
    public class Program
    {
        public static void Main(string[] args)
        {
            CreateHostBuilder(args).Build().Run();
        }

        public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .ConfigureAppConfiguration((hostingContext, config) =>
                {
                    config.AddBeanstalkParameters();
                })
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseStartup<Startup>();
                });
    }
}

Após feita essas alterações, vamos realizar um novo deploy para o Elastic Beanstalk e alterar as configurações desse ambiente no portal da AWS.

Execute então dotnet eb deploy-environment e adicione uma configuração de ambiente para alterar o valor da mensagem.

Podemos ver abaixo como era o retorno da nossa home no Elastic Beanstalk antes e depois dessa alteração:

Finalizando

Com isso aprendemos como publicar nossa aplicação e como configurar nossa aplicação para utilizar as configurações de ambiente do Elastic Beanstalk. O código completo desse exemplo se encontra disponível no GitHub da TreinaWeb: https://github.com/treinaweb/treinaweb-dot-net-core-aws-beanstalk

© 2004 - 2019 TreinaWeb Tecnologia LTDA - CNPJ: 06.156.637/0001-58 Av. Paulista, 1765, Conj 71 e 72 - Bela Vista - São Paulo - SP - 01311-200