Microsserviços e .NET6: deploy na AWS

Problemas dos containers - Apresentação

Boas-vindas ao Curso de Microsserviços e .NET6: deploy na AWS. Me chamo Daniel Artine e serei o seu instrutor neste curso.

Daniel é um homem branco, de olhos castanhos, e cabelos pretos curtos. Veste uma camiseta clara e de tecido liso, está sentado em um ambiente que possui uma parede branca com uma iluminação na cor azul.

Antes de começarmos, vamos verificar o que precisamos.

Pré-requisitos:

• Curso de Microsserviços e .NET6: implementando a comunicação
• Conhecimentos prévios sobre AWS (Amazon Web Services)
• Conhecimentos prévios sobre Kubernetes

Vamos juntar esses conteúdos para realizar o deploy e a entrega da aplicação que fizemos no curso anterior. Isto é, vamos mover esse ambiente para a nuvem.

Na tela, o instrutor exibe a tela esperada ao finalizar este curso. Na página, há o logo do Swagger no canto superior esquerdo e, à direita, o texto "Select a definition" (em português, "Selecione uma definição") com um campo escrito "RestauranteService v1".

Abaixo e à esquerda, temos o título "RestauranteService" e, mais para baixo, uma seção chamada "Restaurante" em que temos as subseções com alguns métodos, como: get, post e get com id. Mais adiante, temos a seção "Schemas".

Essa página é a do Restaurante Service, gerada pelo load balancer que fizemos o deploy.

Na tela, o instrutor exibe outra tela esperada ao finalizar este curso. Na página, há o logo do Swagger no canto superior esquerdo e, à direita, o texto "Select a definition" (em português, "Selecione uma definição") com um campo escrito "ItemService v1".

Abaixo e à esquerda, temos o título "ItemService" e, mais para baixo, uma seção chamada "Item" em que temos as subseções com alguns métodos, como: get, post e get com id. Mais adiante, temos a seção "Restaurante", com os métodos get e post.

A página "ItemService" também foi gerada por outro load balancer que criamos. Fizemos tudo isso, no curso anterior, utilizando a parte de AWS.

As questões de banco de dados, se a aplicação vai voltar de forma automática se for derrubada e como comunicar a aplicação de forma mais eficiente e performática, serão abordadas neste curso.

Em suma, o que faremos no curso é: o deploy das nossas aplicações, entendendo o processo através da AWS com EKS (Amazon Elastic Kubernetes Service), fazendo a comunicação de banco de dados com RDS (Relational Database Service).

Como mencionado, faremos tudo isso com o serviço da AWS. Logo, teremos que criar uma conta e, por isso, colocamos o curso de AWS como pré-requisito.

Por fim, aprenderemos sobre clusterização. No curso anterior, aprendemos bastante sobre conteinerização e neste curso a questão é como o Kubernetes vai nos ajudar na criação do Cluster. Isso porque iniciamos com a parte de Docker e, agora, queremos migrar para o ambiente Kubernetes.

Neste "Para saber mais", temos as Ferramentas necessárias para realizar este curso.

Espero que você goste do curso. Te espero no próximo vídeo!

Problemas dos containers - Revisando o projeto

Nesta aula, faremos uma breve revisão do que fizemos até o final do curso anterior.

Atualmente, temos dois serviços: "RestauranteService" e o "ItemService". Fizemos a comunicação entre esses serviços de forma síncrona por HTTP e, também, de maneira assíncrona através de mensageria, usando o RabbitMQ.

Toda execução dessas aplicações, do Item Service ou Restaurante Service, do RabbitMQ ou do banco de dados que usamos com o Restaurante Service, fizemos através do Docker. Logo, não nos preocupamos muito com o ambiente que estávamos rodando. Apenas efetuamos o comando docker run para a nossa aplicação já conteinerizada estar em execução.

Porém, quais os possíveis cenários?

No terminal, vamos rodar o comando docker ps. Perceba que no retorno já temos alguns containers na coluna "CONTAINER ID". Temos o Restaurante Service, o Item Service, o RabbitMQ e o MySQL, este é responsável por persistir os dados do Restaurante Service. Lembrando que o Item Service armazena os dados em memória.

Retorno:

Para fins didáticos, não exibimos todas as linhas da tabela.

Fizemos, também, o mapeamento de portas e graças a isso conseguimos acessar a aplicação do navegador. E se acontecesse algum problema com a aplicação?

Por exemplo, ao executarmos o comando docker stop f6 no terminal, para simular uma parada repentina ou um problema. O que pode acontecer?

• f6 é o início do ID do Restaurante Service.

Após executar o comando, se voltarmos ao navegador na página do Restaurante Service e atualizar, será exibida a mensagem: "Não é possível acessar esse site". Isso acontece porque o serviço não está mais sendo executado.

Dessa forma, temos o nosso primeiro problema: caso o container fique indisponível, não vamos mais conseguir acessá-lo. O Docker não possui nenhuma regra para manter a aplicação disponível e, em caso de falhas, subir uma nova aplicação de forma automática.

Para analisar o segundo problema, voltaremos no terminal. Todo esse deploy que fizemos do Restaurante, do Item, do RabbitMQ e do MySQL, foi pelo comando docker run, isto é, estamos executando a aplicação por comandos. Qual o problema de subir tudo por comandos?

Por comandos, perdemos a rastreabilidade de como está o estado atual da nossa aplicação. Por exemplo, se quisermos alterar alguma informação de algum serviço, precisamos executar o comando novamente. Dessa forma, o monitoramento ficará bem complexo a partir do momento em que fizermos várias alterações ou quisermos saber o estado atual da aplicação.

Por fim, tivemos que lidar com as questões de rede, através do comando docker network. Isso para colocar os containers em redes criadas por nós, para fazermos a comunicação via host name das aplicações. Ou seja, nos preocupamos com detalhes não tão relevantes para o nosso objetivo.

Com isso, precisamos buscar alguma forma de tornar esses detalhes em algo secundário. Isso para focarmos em deixar a aplicação mais robusta, pronta para ser incrementada, facilitar o acesso e contornar os possíveis problemas de indisponibilidade.

Aprenderemos sobre tudo isso no próximo vídeo. Te espero lá!

Problemas dos containers - Por que usar o Kubernetes?

Neste vídeo, abordaremos alguns conceitos já aprendidos anteriormente, como, por exemplo, o Docker. Podemos executar diferentes aplicações conteinerizadas, como o Nginx, o Java e o C#. Neste curso, focaremos em C# no ambiente .NET.

Caso tenha algum container sendo executado com uma aplicação C# nele, por falta de recurso na máquina, pela aplicação ter algum comportamento inesperado ou o container cair, essa aplicação pode ficar indisponível. Isso porque se a aplicação dentro do container parar, o container também para. Assim, nada fica disponibilizado para o usuário.

O que mais de problemas pode acontecer? Temos o nosso host usando o Docker - você tem o seu e eu tenho o meu. Como vimos, podemos subir containers dentro do nosso host. É possível subirmos quantos containers quisermos, dado que podemos ter diversas aplicações conteinerizadas interagindo.

Porém, o que pode acontecer no nosso cenário? Uma vez que cada container que está em execução no host funciona como processo. Pode ocorrer do host não suportar toda essa carga, há um limite de processamento na nossa máquina. Logo, em algum momento, ao executarmos muitas aplicações, a máquina pode não resistir.

Sem máquina, ficamos sem container e sem aplicação.

Outro problema é: termos os containers em execução e um deles ficar indisponível. Além da aplicação ficar indisponível, vai ser trabalhoso, no meio de tantos containers, identificar qual deu problema.

Podemos pensar em algumas soluções para esse problema. Por exemplo, ter uma rede de computadores em que, ao invés de termos os containers em somente uma máquina, colocamos em várias. Desse modo, o nosso primeiro problema da máquina não suportar estaria resolvido, dado que teríamos agora uma rede de computadores para outras máquinas executarem os containers, caso algum deles dê problema.

Além de mais espaço para executar os containers, conseguimos uma maior confiabilidade que a aplicação ficará disponível. Isso porque teremos outras máquinas para executá-la.

Chamamos esse conjunto de máquinas de cluster.

Vamos precisar de uma plataforma para simular esse conjunto de máquinas e rodar esses containers. No caso, usaremos o Kubernetes, ele acessa a ferramenta responsável por controlar o cluster, enviando cada container para determinada máquina, conforme os recursos estabelecidos.

Isto é, o Kubernetes é o responsável por distribuir os containers e não vamos precisar nos preocupar com isso. Caso algum container que estamos efetuando o deploy pare de funcionar, o próprio Kubernetes sobe um novo com as mesmas características.

Nesta aula, vimos que o Kubernetes vai nos auxiliar nesse problema. Porém, ainda fica a pergunta: como vamos rodar o Kubernetes? Como criaremos as máquinas? Precisamos interagir com esse cluster que vamos criar e ter o Kubernetes instalado.

Aprenderemos tudo isso no próximo vídeo. Até lá!

Sobre o curso Microsserviços e .NET6: deploy na AWS

O curso Microsserviços e .NET6: deploy na AWS possui 128 minutos de vídeos, em um total de 43 atividades. Gostou? Conheça nossos outros cursos de .NET em Programação, ou leia nossos artigos de Programação.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Problemas dos containers
• Migrando para Cloud
• Criando os pods
• Subindo o banco
• Expondo a aplicação