Docker na prática para Backend Java

Preparando o Ambiente da API com Spring Boot - Introdução

Apresentando o instrutor e o curso

Olá! Bem-vindos ao curso de Docker para pessoas desenvolvedoras Java. Meu nome é Rodrigo Desordi.

Audiodescrição: Rodrigo tem cabelos e cavanhaque loiros, usa óculos com armação preta e está vestindo uma camiseta preta. Ao fundo, está o estúdio da Alura.

Além de instrutor na Alura, sou desenvolvedor de sistemas de back-end, principalmente na linguagem Java, com mais de 12 anos de experiência, atuando principalmente no segmento do mercado financeiro.

Explicando o público-alvo e os objetivos do curso

Este curso é destinado a pessoas desenvolvedoras iniciantes ou até mesmo de nível avançado que desejam otimizar o processo de desenvolvimento de sistemas no dia a dia.

Neste curso, vamos explorar o que são containers, os comandos básicos do Docker e como podemos utilizá-lo como uma ferramenta para auxiliar nosso dia a dia, facilitando o desenvolvimento. Também abordaremos como orquestrar vários containers simultaneamente e montar uma infraestrutura local que se assemelhe ao ambiente real, permitindo simular esse ambiente e nos ajudar com novas funcionalidades e resolução de problemas.

Descrevendo a estrutura do curso

Forneceremos um projeto de ponto de partida no início do curso, onde a parte de aplicação já estará completa. Além dos vídeos, teremos várias atividades de apoio, assim como o fórum e a comunidade para esclarecer dúvidas.

Vamos estudar?

Preparando o Ambiente da API com Spring Boot - Entendendo a arquitetura do projeto

Apresentando o projeto da API de produtos

Nós temos aqui o desenho de arquitetura do projeto da API de produtos, que precisamos baixar e clonar do GitHub. Vamos trazer isso para o IntelliJ e começar a entender o projeto, familiarizando-nos com ele.

Podemos observar que a API de produtos está no centro. Ela utiliza as tecnologias Java 21, Spring Boot 3 e também a stack do Spring Cloud 2024. Essa API é bastante básica, gerenciando produtos fictícios para fins didáticos. Embora seja simples, possui um conceito de arquitetura subjacente que não precisamos compreender completamente. O foco é entender as integrações que ela realiza com a infraestrutura.

Analisando a integração com clientes e infraestrutura

Vamos começar a analisar o cliente, representado em azul. Ele consumirá nossa API, podendo ser um cliente externo ou interno. A API fornecerá esse serviço para qualquer um que necessite. Ao chegar na API, ela executará as operações necessárias na camada de regra de negócio e realizará a integração com nossa infraestrutura.

Temos aqui o banco de dados, que praticamente toda API utilizará, com exceção de uma ou outra. Também há a integração com o RabbitMQ para comunicação assíncrona. Possuímos um bucket para armazenamento de volumes, onde podemos guardar arquivos ou imagens. Além disso, há um sistema de monitoramento, que será abordado durante o curso, e que também faz parte da nossa infraestrutura. Por fim, temos um sistema de cache.

Compreendendo os desafios do ambiente de desenvolvimento

Para alguns fluxos, precisamos implementar cache para não sobrecarregar tanto a nossa infraestrutura. Dado esse entendimento da nossa API, vamos compreender que, no nosso dia a dia, enfrentamos uma problemática na rotina das pessoas desenvolvedoras. Consideremos que somos pessoas desenvolvedoras, seja em nível sênior, pleno ou júnior. Ao iniciar em uma empresa, ou mesmo já atuando nela há algum tempo, recebemos demandas. Essas tarefas podem ser melhorias de uma feature (característica) existente, uma nova feature do sistema, uma feature de negócio, uma feature não funcional, uma feature sistêmica, um comportamento, ou até mesmo um incidente, como um bug relatado em um sistema já existente.

Dado esse cenário, a primeira coisa que precisamos fazer como pessoas desenvolvedoras é construir nosso ambiente de desenvolvimento na máquina local. Essa parte de integrações com infraestrutura precisa ser resolvida de alguma forma. Podemos subir o projeto, fazer o clone na máquina e trazê-lo para o IntelliJ ou qualquer outro tipo de IDE. No entanto, ao iniciar a aplicação, ela solicitará as integrações de infraestrutura. Pode ocorrer que o banco de dados não seja encontrado, ou que precisemos ajustar as credenciais, fornecendo o usuário e a senha do banco, o cache, o RabbitMQ, ou outras filas ou message brokers.

Explorando soluções para integrações de infraestrutura

Nesse cenário, precisamos entender como resolver essas questões, e é isso que vamos explorar nos próximos vídeos.

Preparando o Ambiente da API com Spring Boot - Configurando o ambiente de desenvolvimento local

Configurando o ambiente local no IntelliJ

Agora que analisamos a arquitetura do sistema, vamos configurar um ambiente local. No IntelliJ, já baixamos o projeto do repositório do Git e fizemos o import. Vamos realizar o setup juntos para entender melhor o processo de construção do ambiente local.

No IntelliJ, geralmente já temos o Maven integrado. A versão que estamos utilizando é a mais recente disponível no site, integrada tanto na versão paga quanto na Community. Na direita, encontramos o Maven. Ao clicar, abrimos a janela correspondente e selecionamos o botão "Execute Maven Go". Existem algumas opções disponíveis, mas vamos executar um comando que realiza duas ações simultaneamente: o clean install.

Executando comandos Maven

Primeiro, vamos executar o comando mvn para garantir que o Maven está configurado corretamente:

mvn

O IntelliJ já sugere o comando mvn, e incrementamos com clean install, pressionando "Enter". Vamos adicionar o comando clean para limpar qualquer build anterior:

mvn clean

Agora, vamos executar o comando completo clean install para compilar o projeto:

mvn clean install

Resolvendo erro de configuração da JDK

Ocorreu um erro na execução, indicando que a JDK do projeto não foi especificada. O IntelliJ oferece um atalho para configurar isso. Caso o pop-up tenha sido perdido, podemos acessar o menu hambúrguer no canto superior esquerdo, clicar em "Project Structure" e ajustar a configuração. No SDK, identificamos um alerta em vermelho. O projeto utiliza a JDK 21, mas apenas a 17 está disponível. Realizamos o download da JDK 21, aplicamos as alterações e confirmamos.

Executamos novamente o comando e aguardamos o carregamento. A janela de execução na parte inferior mostra que a JDK foi reconhecida e o projeto está sendo compilado. Como o ambiente está zerado, alguns downloads são necessários, o que pode demorar um pouco.

Preparando a execução do projeto

O build foi um sucesso, e o projeto está pronto para execução. Vamos tentar executá-lo. No cenário apresentado, ao iniciar a tarefa na empresa, a primeira ação é configurar o projeto na máquina. A classe de inicialização está na hierarquia de pastas: "raiz", "API produto", "application", "src", "main", "java", e o package é br.com.alura.produto.application. A classe se chama application, e contém o método main.

Vamos definir a estrutura básica da classe Application:

package br.com.alura.produto.application;

import ...

@SpringBootApplication(scanBasePackages = "br.com.alura")
public class Application {

    public static void main(String[] args) {
        Run(Application.class, args);
    }
}

Executando e depurando a aplicação

No IntelliJ, podemos clicar com o botão direito na área à esquerda, onde estão os números das linhas, e selecionar "debug" ou "run". Optamos por "debug". O IntelliJ configura a execução, e um pop-up na parte inferior direita pode indicar a necessidade de um plugin do Lombok. Outro pop-up pode surgir relacionado a redes de networking, que permitimos. Caso o pop-up seja perdido, ele pode reaparecer em outro momento.

Vamos executar novamente. No menu superior à direita, fica gravado o histórico das últimas ações executadas. Ao abrir esse menu, várias opções estarão disponíveis, caso tenhamos executado várias classes ou testes. Podemos voltar e executar novamente. Vamos verificar se o Lombok aparece novamente. Caso apareça, basta instalar o plugin para garantir uma boa comunicação com o IntelliJ.

Analisando erros de execução e configurando o perfil ativo

Vamos abrir o console onde a aplicação foi executada. Podemos ler desde o início, onde o Spring estava sendo iniciado corretamente, até o final, onde possíveis erros são descritos. Neste caso, ocorreu um erro, indicado em vermelho, informando que a aplicação falhou na inicialização porque o atributo data source URL não foi especificado no data source embarcado. Quando falamos de data source, referimo-nos ao banco de dados, e a URL não foi especificada. Na primeira tarefa, ao construir o ambiente, já encontramos um problema. Vamos entender como resolver.

Para este projeto, precisamos configurar o carregamento das properties do sistema. No histórico de execuções, vamos em application. Temos duas opções: clicar nos três pontos à direita, que são more actions, ou em edit configurations. Em edit configurations, podemos ver o histórico da application à esquerda, onde tudo que executarmos será listado. Aqui, podemos definir algumas configurações no startup. Uma delas é o active profile. O novo IntelliJ já detectou o uso do Spring, fornecendo um campo específico para definir o profile active. Caso o plugin do Spring não esteja disponível, deveríamos ir em environment variables e acrescentar uma property específica, que mostraremos depois. Como já está disponível, vamos definir que estamos no ambiente local e na infraestrutura local. Isso deve funcionar para este projeto. Podemos entrar em mais detalhes posteriormente. Após aplicar, podemos iniciar um debug diretamente daqui, e ele será executado novamente.

Lidando com problemas de conexão ao banco de dados

Vamos definir o perfil ativo para o ambiente local e infraestrutura local:

local,infra_local

O Lombok apareceu, então vamos habilitá-lo no IntelliJ. Ocorreu um erro, então vamos subir até encontrar o erro em vermelho e entender o problema. O erro mudou e não é mais o mesmo de antes. Agora, a mensagem indica que a conexão com o localhost:5432 foi recusada, sugerindo verificar o hostname e a porta. A configuração foi carregada, e a URL localhost:5432 foi descrita, mas não houve resposta do banco de dados. Sabemos que nesta máquina não há um banco de dados instalado, então, logicamente, ele não conseguiria encontrar. Ele tentou carregar.

Até este ponto, entendemos que estamos com uma nova tarefa, tentando configurar o ambiente para corrigir ou implementar essa tarefa, mas enfrentamos problemas com o banco de dados. Não foi encontrado nenhum banco de dados na máquina, mas já fizemos o setup inicial para apontar localmente. Vamos entender como resolver esse problema.

Sobre o curso Docker na prática para Backend Java

O curso Docker na prática para Backend Java possui 142 minutos de vídeos, em um total de 33 atividades. Gostou? Conheça nossos outros cursos de Java 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:

• Preparando o Ambiente da API com Spring Boot
• Docker para Desenvolvimento
• Orquestração com Docker Compose
• Build e Teste com Docker