Kubernetes com microsserviços: subindo e gerenciando uma aplicação

Preparando a aplicação - Apresentação

Olá, sou Leonardo Sartorello, e serei seu instrutor neste curso da Alura. Para que todas as pessoas possam acompanhar, vou me descrever.

Audiodescrição: Leonardo Sartorello se declara um homem de pele clara, com olhos azuis. Tem cabelos castanhos escuros curtos e barba. Veste camiseta verde e lisa, e está nos estúdios da Alura. Ao fundo, há uma estante com alguns enfeites e uma parede iluminada com luz azul e vermelha.

Boas-vindas a este curso de Kubernetes!

Para quem é este curso?

É direcionado a pessoas que já estudaram Kubernetes com Monolitos e estão interessadas em aprender sobre o mundo do Kubernetes com microsserviços.

O que vamos aprender?

1. Criar e gerenciar aplicação em microsserviços;
2. Comunicação entre serviços sem expor portas;
3. Serviços de registro e descobrimento;
4. Usaremos um projeto em Java com Spring.

Vamos explicar como criar e gerenciar uma aplicação de microsserviços no Kubernetes. Abordaremos métodos para permitir a comunicação entre esses microsserviços sem expor suas portas diretamente. Além disso, veremos como lidar com os serviços de registro e descobrimento de microsserviços no ambiente do Kubernetes.

Exploraremos esses conceitos usando qual projeto? Este projeto foi criado em um curso anterior da Alura, envolvendo Java com Spring. Se você estiver interessado em conhecer mais sobre ele, podemos indicar o curso onde ele foi desenvolvido. Dessa forma, você poderá compreender sua estrutura e todos os detalhes internos de seu funcionamento.

Aproveite todos os recursos da plataforma. Além dos vídeos, temos atividades, o apoio do fórum e a comunidade do Discord.

Vamos estudar!

Preparando a aplicação - Entendendo a aplicação

Antes de começarmos a trabalhar com a aplicação e tentar colocá-la em funcionamento, é importante entendermos um pouco sobre essa aplicação e também o que precisaremos para colocá-la em funcionamento.

Entendendo a aplicação

Atualmente, é uma aplicação baseada em microsserviços. Mas, por que microsserviços? Quais vantagens eles trazem para nós?

Vantagens dos microsserviços

1. Partes mais pesadas da aplicação podem crescer de forma independente
2. Se alguma máquina desligar, ou se desconectar da rede a aplicação não cai

Dentro de microsserviços, temos que as partes mais pesadas da aplicação podem crescer de forma independente. Ou seja, se muitas requisições estiverem chegando em algum serviço específico, podemos criar cópias desses serviços. Assim, não precisamos nos preocupar em aumentar a máquina onde está esse serviço. Podemos fazer cópias dele e distribuir entre várias máquinas.

Isso também nos traz outra vantagem muito grande: se alguma máquina desligar ou se desconectar da rede, a aplicação tende a não ficar fora do ar. Por quê? Porque podemos subir esses serviços que estavam na máquina que caiu, em outras máquinas e redirecionar todo o tráfego. Isso torna nossas aplicações muito mais resilientes à falha.

Mas, vamos voltar um pouco para a nossa aplicação.

Estrutura da aplicação

A aplicação é desenvolvida em Java e consiste em quatro partes principais: uma central de pagamentos para processar pagamentos e verificar o status das transações; uma central de pedidos para realizar novos pedidos, solicitar cotações e verificar o status desses pedidos; um gateway de acesso que serve como ponto de entrada na aplicação e direciona as solicitações para os microservices correspondentes;.

E, por último, o Eureka, um serviço de descoberta que ajuda a localizar os microsserviços e facilita a comunicação entre eles.

Essas quatro partes da aplicação (quatro microsserviços), que precisam se comunicar, e precisamos garantir essa comunicação.

Além disso, as informações que chegam nesses microsserviços são armazenadas em um banco de dados do MySQL. Sendo assim, o serviço de pagamentos e o de pedidos precisam se comunicar com esse banco de dados.

Próximos Passos

Qual o plano para este curso? Vamos empacotar os quatro microsserviços em containers, subir o banco de dados e, em seguida, subir a aplicação para testar e verificar se está funcionando.

Vamos lá?

Preparando a aplicação - Preparando os containers

Neste momento, já temos um plano de ação e sabemos o que precisa ser feito. A primeira parte do nosso plano é colocar nossas aplicações dentro de containers. Portanto, é importante termos certeza de como elas funcionam.

Inserindo a aplicação em um container

Primeiramente, nossa aplicação é uma aplicação criada em Maven (Ferramenta de automação de compilação), ou seja, ela usa o Java. No entanto, ela não usa qualquer versão do Java, ela usa o Java 17. Para podermos criar nossa imagem, precisamos pegar uma imagem base do Maven no Java 17. Isso nos permitirá compilar nosso código e depois executá-lo.

Vamos ao editor de código com o projeto.

Criando e construindo o arquivo Dockerfile

Do lado esquerdo, selecionamos com o botão direito aplicação do gateway e clicamos na opção "New File" ("Novo arquivo"). Digitamos "Dockerfile" para o nomear o arquivo. Ao teclarmos "Enter", somos redirecionados para o arquivo vazio.

O que precisaremos inserir? Precisamos do from e especificar uma imagem inicial. Vamos buscar essa imagem inicial.

Para isso, abrimos o navegador e digitamos "Docker Hub". Entramos no primeiro link do Docker Hub e buscamos uma imagem do "Maven". Podemos clicar no campo de busca na parte central para digitar ou usar o atalho "Ctrl + K".

A primeira imagem é do Maven Docker Official Image, imagem oficial do Docker. Vamos entrar e analisar.

Temos a seção "Supported tags and respective Dockerfile links" ("Tags suportadas e links dos Dockerfiles respectivos"). Ou seja, quais são as versões suportadas atualmente pelo Maven? 3.9.6-eclipse-temurin.

Mas temos do Java 11, do Java 17 e Java 21. No nosso caso, desejamos o Java 17. E entre o Java 17, qual pegamos? O eclipse-temurin-17, o eclipse-temurin-17-alpine ou o eclipse-temurin-17-focal?

Temos a liberdade de escolher qualquer uma delas, mas minha preferência é pela Focal, pois ela é baseada no Ubuntu. Estamos mais familiarizados com Ubuntu do que com Alpine, por exemplo. Portanto, iremos selecionar a versão 3.9.6-eclipse-temurin-17-focal, copiá-la e voltar para o nosso Dockerfile.

No comando FROM, inserimos o nome da imagem, que é Maven, seguido pela nossa tag.

Dockerfile

FROM maven:3.9.6-eclipse-temurin-17-focal

Com isso, temos a nossa versão.

O que precisaremos? Primeira coisa, sempre boa prática, um diretório de trabalho. Digitamos "WORKDIR". Qual será o nosso diretório de trabalho? Inserimos em /app. Assim, tudo que fizermos a partir de agora, vai cair em /app.

FROM maven:3.9.6-eclipse-temurin-17-focal
WORKDIR /app

Precisamos copiar o arquivo pom.xml para o nosso container; ele contém as configurações do Maven necessárias para compilar nossa aplicação. Para isso, digitamos COPY pom.xml. Onde devemos colocá-lo? No diretório atual e para indicar isso inserimos um ponto.

FROM maven:3.9.6-eclipse-temurin-17-focal
WORKDIR /app
COPY pom.xml .

Além disso, precisamos trazer o código fonte da aplicação. Sem ele, o Maven não terá nada para compilar. Onde está esse código? Ele está na pasta src. Vamos trazê-lo para o diretório atual, e queremos uma pasta chamada src.

FROM maven:3.9.6-eclipse-temurin-17-focal
WORKDIR /app
COPY pom.xml .
COPY src ./src

Agora, o que falta é apenas executar a compilação com o comando mvn clean package -DskipTests. Para isso, basta digitarmos "Run" e em seguida o comando mencionado.

FROM maven:3.9.6-eclipse-temurin-17-focal
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN mvn clean package -DskipTests

Com isso, conseguimos compilar nossa aplicação, mas espera um momento. Estamos falando de microsserviços. Nesse caso, precisamos de uma aplicação pequena e compacta, e aqui estamos trazendo muitas coisas que não vamos utilizar.

Uma vez que essa aplicação esteja compilada, não precisamos mais do Maven. Só precisamos do Java. Não precisamos mais do pom.xml. Não precisamos mais do código fonte. Está tudo compilado.

Então, vamos otimizar um pouco mais essa imagem.

Otimizando a imagem

O que faremos? Passamos que todas as mudanças que fizermos na imagem do Maven serão identificadas como AS build. Inclusive, ao colocarmos o cursor no final da primeira linha, é indicado AS stage. Então, tudo que fizermos aqui será identificado como AS Build.

FROM maven:3.9.6-eclipse-temurin-17-focal AS Build
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN mvn clean package -DskipTests

Agora, vamos criar a imagem e executá-la. Como faremos isso? Primeiro, precisamos definir a imagem base usando FROM após o RUN. Qual será a nossa imagem base? Vamos analisar no Docker Hub, mas já adianto que usaremos a imagem do Eclipse Temurin.

No campo de busca, digitamos "eclipse temurim". Dentro do eclipse-temurin, clicamos na aba "Tags" para verificar as tags disponíveis. Dentro de tags, pesquisamos por "Focal" no campo de busca, sendo o que desejamos rodar.

Vamos compilar e rodar em Focal, com base no Ubuntu.

Há algumas tags que não precisamos nos preocupar: 8u412-b08-jre-focal. Nem sequer sabemos a versão do Java dessa tag, então vamos seguir em frente.

Descendo um pouco, temos o 8-jre-focal, Java 8. Nosso foco é no Java 17, então isso não é relevante. Descendo mais um pouco a página, temos: 8-jdk-focal, depois 8-focal.

Encontramos um Java 17: 17.0.11_9-jre-focal. Esta é relevante, pois se refere ao Java 17, especificamente a versão 17.0.11 no JRE (Java Runtime Environment).

Uma vez que nosso arquivo já está compilado, não precisamos do JDK (Java Development Kit). Podemos usar apenas o Runtime Environment (JRE), que é mais leve e traz vantagens. Portanto, vamos pegar a versão completa do JRE abaixo. Copiamos apenas as informações após o docker pull:

eclipse-temurin:17.0.11_9-jre-focal

Voltamos para o Visual Studio Code e adicionamos nossa nova imagem, que usaremos como base. Para tal, colamos a tag que acabamos de copiar após o FROM.

FROM maven:3.9.6-eclipse-temurin-17-focal AS Build
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN mvn clean package -DskipTests

FROM eclipse-temurin:17.0.11_9-jre-focal

Em seguida, vamos definir nosso diretório de trabalho usando o mesmo comando WORKDIR /app. Não há necessidade de mudar isso.

Depois, faremos um COPY. De onde virá nossa informação desta vez? Não será das nossas pastas. A informação virá do nosso estágio. Ao digitarmos o "--", aparecerá from=stage. E qual é o estágio que temos? Temos o estágio de build.

FROM maven:3.9.6-eclipse-temurin-17-focal AS Build
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN mvn clean package -DskipTests

FROM eclipse-temurin:17.0.11_9-jre-focal
WORKDIR /app
COPY --from=build

O estágio de build será responsável por montar essa parte do código acima. Agora, vamos trabalhar com o resultado desse build da linha 10. Onde fica o arquivo compilado? Ele está localizado em /app/target/ o nome da aplicação.

Onde encontramos o nome da aplicação? No arquivo pom.xml. Abrimos o arquivo o pom.xml do lado esquerdo. Ele contém várias informações, a maioria das quais não usaremos diretamente, mas o Maven usará. No entanto, utilizaremos o artifactId na linha 12 e a versão na linha 13.

Iremos copiar o nome contido no artifactId e no version para inserir no Dockerfile.

Trecho indicado do arquivo pom.xml:

<artifactId>gateway</artifactId>
<version>0.0.1-SNAPSHOT</version>

Ao colarmos no arquivo Dockerfile, temos:

FROM maven:3.9.6-eclipse-temurin-17-focal AS Build
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN mvn clean package -DskipTests

FROM eclipse-temurin:17.0.11_9-jre-focal
WORKDIR /app
COPY --from=build /app/target/gateway-0.0.1-SNAPSHOT

Esse é o nome do nosso arquivo? Quase. O arquivo também tem uma extensão: .jar, que indica que é um arquivo Java. Uma vez compilado, ele estará no .jar. Vamos copiá-lo para onde? Para a pasta de trabalho atual, que no nosso caso é /app que iremos identificar com um ponto.

FROM maven:3.9.6-eclipse-temurin-17-focal AS Build
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN mvn clean package -DskipTests

FROM eclipse-temurin:17.0.11_9-jre-focal
WORKDIR /app
COPY --from=build /app/target/gateway-0.0.1-SNAPSHOT.jar .

Agora, só falta pedir para rodar a aplicação.

Como podemos fazer isso? Usando o comando CMD. Vamos executar o Java com os seguintes parâmetros. Primeiro, precisamos especificar o tipo de arquivo que o Java vai rodar: um jar. Então, usamos -jar e, em seguida, o nome do arquivo, que já temos acima (gateway-0.0.1-SNAPSHOT.jar). Vamos copiar o nome do arquivo e colar no comando CMD.

FROM maven:3.9.6-eclipse-temurin-17-focal AS Build
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN mvn clean package -DskipTests

FROM eclipse-temurin:17.0.11_9-jre-focal
WORKDIR /app
COPY --from=build /app/target/gateway-0.0.1-SNAPSHOT.jar .
CMD [ "java", "-jar", "gateway-0.0.1-SNAPSHOT.jar" ]

Com isso o nosso Dockerfile está pronto.

O que faremos agora? Vamos montar essa imagem.

Montando a imagem

No terminal integrado na parte inferior, digitamos o seguinte comando:

docker build -t 

Agora é só escolher um nome para a imagem. O ponto crucial é que esta imagem precisa estar em um repositório. Imagens locais não são bem aceitas pelo Docker. Portanto, vamos precisar colocá-la no repositório.

Vamos adicionar ao Docker Hub usando nosso nome de usuário, no meu caso, é leonardosartorello.

Lembre-se de incluir o seu nome de usuário, seguido por uma barra.

Na sequência, colocamos o nome e a imagem como java-gateway. Estamos lidando com o Gateway. Após o gateway, inserimos -k8s:v1, sendo v1 a versão.

Por enquanto, temos:

docker build -t  SeuNomeDeUsuario/java-gateway-k8s:v1

Onde vamos encontrar o Dockerfile? O Dockerfile pode ser encontrado dentro da pasta gateway/., exatamente nessa localização.

docker build -t  SeuNomeDeUsuario/java-gateway-k8s:v1 gateway/.

Teclamos "Enter" para rodar.

Assim, vamos obter build da nossa imagem. Vamos ampliar um pouco para facilitar a visualização do processo de construção no terminal. Pode levar um pouco de tempo; no meu caso, foi rápido, mas pode demorar um pouco.

Assim que concluirmos esse processo, poderemos realizar o docker push para enviar a imagem para um repositório. Então, vamos ajustar o comando docker build para docker push, e lembre-se sempre de remover o diretório final e o "-t".

docker push  SeuNomeDeUsuario/java-gateway-k8s:v1 gateway/.

Teclamos "Enter".

Agora, nossa imagem está pronta para uso.

Tarefa do vídeo

No entanto, temos outras três partes da aplicação que também precisam de imagens. São três serviços adicionais que necessitam de imagens. Vou deixar para você criar essas imagens, pois é crucial tê-las para avançarmos.

Tudo o que você precisa fazer é criar um arquivo Dockerfile e modificar o nome e a versão da aplicação. Combinado?

Próximo Passo

Com isso pronto. Podemos seguir para o banco de dados.

Vamos lá?

Sobre o curso Kubernetes com microsserviços: subindo e gerenciando uma aplicação

O curso Kubernetes com microsserviços: subindo e gerenciando uma aplicação possui 114 minutos de vídeos, em um total de 43 atividades. Gostou? Conheça nossos outros cursos de Containers em DevOps, ou leia nossos artigos de DevOps.

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

• Preparando a aplicação
• Banco de dados
• Aplicação
• Acesso aos serviços
• Conectando os serviços