SalvaAí | Artigos

Desmistificando Docker e Kubernetes

Sat, 20 Mar 2021 00:00:00 GMT

Docker e Kubernetes: do “funciona na minha máquina” até aplicações em produção

Um guia para entender containers, orquestração e como aplicações modernas chegam ao mundo real, sem precisar invocar um DevOps para cada dúvida.

1. O famoso “na minha máquina funciona”

Imagine a seguinte situação: você passou três dias desenvolvendo uma API incrível. Tudo funciona perfeitamente no seu computador. Os testes passam, o banco de dados responde, a aplicação inicia sem erros e você já está quase comemorando.

Então chega o momento de colocar tudo em produção.

Você envia o projeto para o servidor, executa a aplicação e… nada.

Falta uma versão específica do Java. O servidor usa outra versão do Python. Uma biblioteca está desatualizada. Uma variável de ambiente não foi configurada. O banco de dados está em outra porta.

E, como se não bastasse, alguém da equipe pergunta:

“Mas você testou antes de enviar?”

Você responde, com a serenidade de quem está prestes a abandonar a tecnologia:

“Na minha máquina funcionava.”

Essa situação é tão comum que praticamente virou um meme entre desenvolvedores. O problema é que ela representa uma dificuldade real: uma aplicação depende de muito mais do que apenas seu código-fonte para funcionar.

Ela depende de uma linguagem, de bibliotecas, de configurações, de serviços externos e, em muitos casos, de versões específicas de cada componente.

Foi para lidar melhor com esse tipo de problema que tecnologias como Docker ganharam tanta popularidade. E, quando precisamos gerenciar muitas aplicações e containers ao mesmo tempo, o Kubernetes entra em cena.

Mas vamos por partes. Ninguém precisa aprender a pilotar um avião antes de entender como funciona um carro.

2. Primeiro, vamos entender o que é o Docker

Imagine que você precisa transportar uma geladeira, um sofá, uma televisão e algumas caixas para outra cidade.

Você poderia colocar tudo em um caminhão de qualquer jeito, torcer para que nada caia e torcer ainda mais para que tudo chegue inteiro.

Ou poderia organizar tudo em caixas padronizadas, identificadas e preparadas para serem transportadas de maneira previsível.

No mundo do transporte de cargas, os containers físicos resolveram muitos problemas de padronização. Um container pode ser transportado por diferentes navios, caminhões e trens sem que seja necessário reorganizar toda a carga a cada troca de veículo.

O Docker aplica uma ideia parecida ao desenvolvimento de software.

Em vez de depender exclusivamente do ambiente em que a aplicação será executada, podemos empacotar o código com suas dependências e configurações necessárias em uma unidade chamada container.

Assim, a aplicação passa a ter um ambiente de execução muito mais previsível.

É importante fazer uma distinção: o Docker não coloca absolutamente tudo dentro de uma caixa mágica. O kernel do sistema operacional, os serviços externos, os segredos e algumas configurações continuam dependendo do ambiente. O objetivo é reduzir as diferenças que costumam causar problemas.

2.1. O que é um container?

Um container é um ambiente isolado no qual um processo ou conjunto de processos executa, utilizando recursos do sistema operacional hospedeiro.

Pense em um prédio comercial.

Cada empresa possui seu próprio escritório, com seus funcionários, documentos e organização. Uma empresa não precisa conhecer todos os detalhes internos das outras para trabalhar.

Os escritórios compartilham a estrutura do prédio, mas mantêm certo isolamento.

Os containers funcionam de maneira semelhante. Eles podem executar aplicações separadamente, com seus próprios sistemas de arquivos, configurações e dependências, enquanto compartilham o kernel do sistema operacional.

Isso traz uma vantagem importante: containers geralmente são mais leves do que máquinas virtuais tradicionais, porque não precisam inicializar um sistema operacional completo para cada instância.

Uma observação técnica: o isolamento dos containers Linux utiliza recursos do kernel, como namespaces e cgroups. No Windows e no macOS, o Docker Desktop normalmente utiliza uma máquina virtual Linux para executar containers Linux.

Ou seja, existe bastante engenharia por trás daquela caixinha que parece tão simples.

2.2. Container não é a mesma coisa que máquina virtual

Essa é uma das primeiras diferenças que vale a pena entender.

Uma máquina virtual normalmente executa seu próprio sistema operacional convidado sobre um hipervisor. Já um container compartilha o kernel do sistema operacional hospedeiro, embora tenha um ambiente isolado para executar sua aplicação.

Imagine duas formas de hospedar empresas:

Máquina virtual: cada empresa aluga uma casa completa, com sua própria infraestrutura.
Container: cada empresa ocupa um escritório independente dentro de um prédio que compartilha parte da infraestrutura.

A casa completa oferece mais independência, mas demanda mais recursos. O escritório compartilhado tende a ser mais leve, embora dependa de uma infraestrutura comum.

Isso não significa que containers sejam sempre melhores ou substituam máquinas virtuais em qualquer cenário. As tecnologias resolvem problemas diferentes e frequentemente são utilizadas juntas.

3. Antes do Docker, precisamos conhecer três conceitos

Para entender como o Docker funciona, precisamos separar três coisas: imagem, container e Dockerfile.

3.1. Imagem: a receita da aplicação

Uma imagem Docker é um pacote imutável que contém os arquivos, as dependências e as instruções necessárias para criar containers.

Imagine uma receita de bolo.

A receita descreve os ingredientes e o modo de preparo. Você pode utilizá-la para preparar vários bolos sem precisar inventar tudo novamente.

A imagem é a receita; o container é uma instância criada a partir dela.

Por exemplo, podemos ter uma imagem de uma API Java e executar três containers a partir dessa mesma imagem. Cada container será uma instância separada da aplicação.

3.2. Container: a receita em execução

Se a imagem é a receita, o container é o bolo que você efetivamente preparou.

Tecnicamente, um container é uma instância executável de uma imagem, com seu próprio estado de execução e suas configurações.

Você pode iniciar, parar, remover e recriar containers. Em aplicações bem projetadas, os dados importantes não devem depender exclusivamente do sistema de arquivos temporário do container. Para isso, podemos utilizar volumes, bancos de dados e serviços externos.

3.3. Dockerfile: as instruções para construir a imagem

O Dockerfile é o arquivo no qual descrevemos como a imagem será construída.

Vamos imaginar uma API Java com Spring Boot. Um Dockerfile simples poderia ser assim:

FROM eclipse-temurin:17-jre

WORKDIR /app

COPY target/app.jar app.jar

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "app.jar"]

Vamos entender cada instrução:

FROM: define a imagem-base utilizada na construção.
WORKDIR: define o diretório de trabalho dentro da imagem.
COPY: copia o arquivo JAR para esse diretório.
EXPOSE: documenta a porta em que a aplicação espera receber conexões.
ENTRYPOINT: define o processo principal executado quando o container inicia.

Esse exemplo pressupõe que você já compilou a aplicação e gerou o arquivo target/app.jar. Também pressupõe que a aplicação realmente utiliza a porta 8080.

Perceba que EXPOSE não publica a porta automaticamente para o seu computador. Para isso, precisamos configurar o mapeamento de portas ao executar o container.

E pronto: já temos a estrutura básica de uma imagem Docker.

4. Colocando a mão na massa

Vamos construir nossa primeira imagem.

Considerando que o Docker esteja instalado e que o Dockerfile esteja na pasta do projeto, execute:

docker build -t minha-api:1.0 .

O que aconteceu aqui?

docker build: solicita a construção de uma imagem.
-t minha-api:1.0: define o nome e a versão da imagem.
.: informa que o diretório atual será utilizado como contexto de construção.

Agora, podemos iniciar um container:

docker run -d \
  --name minha-api \
  -p 8080:8080 \
  minha-api:1.0

A opção -d executa o container em segundo plano. A opção --name define seu nome, e -p 8080:8080 mapeia a porta 8080 do computador para a porta 8080 do container.

Se a aplicação estiver funcionando e aceitar requisições HTTP nessa porta, você poderá acessá-la em http://localhost:8080.

Alguns comandos úteis para o dia a dia:

# Listar containers em execução
docker ps

# Listar imagens disponíveis
docker images

# Consultar os logs da aplicação
docker logs minha-api

# Parar o container
docker stop minha-api

# Iniciar novamente
docker start minha-api

# Remover um container parado
docker rm minha-api

Experimente executar esses comandos. Aprender Docker não é muito diferente de aprender Git: a teoria ajuda, mas é quando você começa a executar comandos e cometer pequenos erros que as coisas passam a fazer sentido.

Só não execute docker rm em produção sem entender o impacto, combinado?

5. E se minha aplicação precisar de um banco de dados?

Aqui começa a ficar interessante.

Imagine que você tem uma API Spring Boot que utiliza PostgreSQL. A aplicação funciona, mas precisa que o banco esteja disponível, com as credenciais corretas e com a configuração de rede adequada.

Você poderia instalar tudo manualmente no computador de cada desenvolvedor. Poderia também configurar cada ambiente de testes individualmente.

Ou poderia utilizar containers para executar os serviços necessários.

Por exemplo, para iniciar um PostgreSQL local de testes:

docker run -d \
  --name postgres-dev \
  -e POSTGRES_DB=appdb \
  -e POSTGRES_USER=appuser \
  -e POSTGRES_PASSWORD=devpassword \
  -p 5432:5432 \
  postgres:16

Esse comando cria um container PostgreSQL com um banco chamado appdb e um usuário chamado appuser.

A senha utilizada é apenas ilustrativa para um ambiente local. Não coloque credenciais reais em comandos compartilhados, arquivos versionados ou ambientes de produção.

Existe outro detalhe importante: sem um volume persistente, os dados podem ser perdidos quando o container e sua camada gravável forem removidos. Em um ambiente real, precisamos planejar a persistência dos dados.

5.1. Docker Compose: quando um container não é suficiente

Uma aplicação real raramente vive sozinha.

Podemos ter uma API, um banco PostgreSQL, um Redis para cache e um serviço de mensageria. Gerenciar tudo separadamente começa a parecer uma mudança de apartamento em que cada pessoa transporta seus próprios móveis, mas ninguém sabe onde fica a chave da porta.

O Docker Compose permite descrever vários serviços em um único arquivo e gerenciá-los em conjunto.

Veja um exemplo simplificado:

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: appdb
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: devpassword
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data

  api:
    build: .
    ports:
      - "8080:8080"
    environment:
      DB_HOST: db
      DB_PORT: 5432
      DB_NAME: appdb
      DB_USER: appuser
      DB_PASSWORD: devpassword
    depends_on:
      - db

volumes:
  postgres_data:

Com esse arquivo salvo como compose.yaml, podemos executar:

docker compose up --build

E encerrar os serviços com:

docker compose down

O volume postgres_data mantém os dados do banco separados do ciclo de vida do container. Assim, o docker compose down padrão não remove esse volume nomeado.

Note também que a API se conecta ao banco utilizando o nome do serviço db. O Compose cria uma rede para os serviços, permitindo que eles se comuniquem por seus nomes.

Esse é um exemplo didático. Em um projeto real, a aplicação precisa estar preparada para receber essas variáveis, as credenciais devem ser tratadas corretamente e a inicialização precisa considerar que o banco pode demorar para ficar pronto.

O depends_on básico organiza a ordem de inicialização, mas, sozinho, não garante que o banco já esteja aceitando conexões.

Mesmo com essas ressalvas, o Compose já resolve uma grande parte dos problemas de desenvolvimento local.

6. Até aqui, o Docker resolveu muita coisa. Mas e quando o sistema cresce?

Imagine que sua API começou como um pequeno projeto. Você tem poucos usuários, uma única instância e um servidor suficiente para executar tudo.

Então o produto cresce.

De repente, são milhares de usuários. Em alguns horários, o número de requisições aumenta bastante. Uma instância da aplicação deixa de ser suficiente, e você decide executar três.

Até aqui, tudo bem.

Mas então uma instância para de responder. Outra consome memória demais. Uma nova versão precisa ser implantada sem interromper os usuários. O servidor precisa ser substituído. O tráfego deve ser distribuído entre as instâncias.

Agora imagine administrar tudo isso manualmente.

Você precisaria acompanhar quais instâncias estão funcionando, iniciar novas quando necessário, substituir as que falharem e organizar a comunicação entre os serviços.

É nesse momento que surge a pergunta:

Quem vai administrar todos esses containers?

O Docker permite executar e gerenciar containers, e existem ferramentas para automatizar boa parte desse trabalho. Uma das mais conhecidas é o Kubernetes.

7. Kubernetes: o gerente dos containers

Pense no Kubernetes como o gerente de uma grande operação logística.

O Docker ajuda a empacotar e executar aplicações em containers. O Kubernetes coordena a execução dessas aplicações em um conjunto de máquinas, buscando manter o sistema no estado desejado.

Você não precisa dizer manualmente, a cada instante, qual container deve ser iniciado ou em qual máquina ele deve ficar. Em vez disso, descreve o que deseja que esteja funcionando, e o Kubernetes trabalha para alcançar e manter esse estado.

Por exemplo, você pode declarar:

Quero três réplicas da minha API.
Quero que elas sejam distribuídas entre os recursos disponíveis.
Quero que novas réplicas sejam criadas se algumas falharem.
Quero atualizar a aplicação gradualmente.
Quero disponibilizar um endereço estável para acessar o serviço.

O Kubernetes utiliza controladores e outros componentes para reconciliar continuamente o estado observado com o estado desejado.

Em outras palavras, ele não fica apenas esperando você perceber um problema. Ele tenta corrigir determinadas falhas automaticamente, de acordo com a configuração e os recursos disponíveis.

Naturalmente, não é mágica. Se o banco de dados estiver indisponível, se não houver memória suficiente ou se a nova versão estiver quebrada, o Kubernetes não poderá simplesmente inventar recursos ou corrigir qualquer erro de código.

Ele é um poderoso orquestrador, não um desenvolvedor sênior preso dentro do servidor.

8. Entendendo os principais conceitos do Kubernetes

Antes de escrevermos nosso primeiro arquivo de configuração, vale conhecer alguns componentes.

8.1. Cluster

Um cluster é o conjunto de máquinas e componentes que trabalham para executar as aplicações gerenciadas pelo Kubernetes.

Ele possui, de maneira geral, dois grandes grupos de responsabilidades:

Control plane: mantém o estado desejado do cluster, recebe as solicitações e coordena as decisões de gerenciamento.
Worker nodes: são as máquinas nas quais as cargas de trabalho são executadas.

O control plane inclui componentes como o API Server, o Scheduler e o Controller Manager. Em uma instalação típica, o etcd armazena o estado do cluster.

Os worker nodes executam componentes como o kubelet, responsáveis por manter os workloads funcionando conforme as especificações recebidas.

Em ambientes gerenciados, parte dessa infraestrutura pode ficar sob responsabilidade do provedor de nuvem.

8.2. Pod

O Pod é a menor unidade implantável do Kubernetes.

É comum ouvir que o Kubernetes executa containers, mas, tecnicamente, ele agenda Pods. Um Pod pode conter um ou mais containers que compartilham determinados recursos, como rede e volumes.

Na maioria das aplicações web simples, um Pod contém um container principal.

Imagine que o cluster é um condomínio e cada Pod é um apartamento reservado para uma unidade de trabalho. Os containers daquele Pod compartilham certos recursos, assim como moradores do mesmo apartamento compartilham a infraestrutura interna.

Pods são recursos relativamente efêmeros. Se um Pod for substituído, o novo Pod poderá ter uma identidade diferente. Por isso, não devemos depender do endereço IP individual de um Pod como se fosse permanente.

8.3. Deployment

O Deployment descreve como uma aplicação deve ser executada e atualizada.

Se você deseja manter três réplicas da sua API, pode declarar isso em um Deployment. Ele gerencia ReplicaSets, que, por sua vez, ajudam a manter a quantidade desejada de Pods.

Veja um exemplo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: minha-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: minha-api
  template:
    metadata:
      labels:
        app: minha-api
    spec:
      containers:
        - name: api
          image: nginx:1.28
          ports:
            - containerPort: 80

Esse exemplo utiliza o Nginx apenas para demonstrar a estrutura de um Deployment. Ele não é a nossa API Java e não implementa nenhuma lógica de negócio.

O ponto principal está em replicas: 3.

Estamos declarando que desejamos três réplicas. O Kubernetes tentará manter essa quantidade de Pods em execução.

Se um Pod desaparecer, o controlador poderá criar outro para substituí-lo, desde que existam recursos disponíveis e que as condições necessárias sejam atendidas.

Isso é diferente de simplesmente executar três containers manualmente. Estamos declarando um estado desejado que o Kubernetes procura manter.

8.4. Service

Se um Deployment cria e mantém Pods, como os outros componentes da aplicação encontram esses Pods?

Lembre-se de que os Pods podem ser substituídos e seus endereços IP podem mudar.

É aí que entra o Service.

Um Service oferece um ponto de acesso estável para um conjunto de Pods selecionados por labels.

Por exemplo:

apiVersion: v1
kind: Service
metadata:
  name: minha-api
spec:
  selector:
    app: minha-api
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP

Esse Service seleciona os Pods que possuem a label app: minha-api e disponibiliza uma porta estável para acesso dentro do cluster.

O tipo ClusterIP é o padrão e permite acesso interno. Para disponibilizar uma aplicação externamente, podemos utilizar outras configurações, como LoadBalancer, ou mecanismos de entrada HTTP/HTTPS.

8.5. ConfigMaps e Secrets

Aplicações precisam de configurações, como URLs de serviços, nomes de bancos e parâmetros de execução.

O Kubernetes oferece dois recursos úteis:

ConfigMap: armazena configurações que não são confidenciais.
Secret: representa dados sensíveis, como senhas e tokens.

Mas atenção: o nome Secret não significa que qualquer instalação estará automaticamente protegida contra acessos indevidos. É necessário configurar permissões, proteger o armazenamento do cluster e adotar práticas adequadas de gerenciamento de segredos.

Não adianta usar Kubernetes para gerenciar sua infraestrutura e deixar a senha do banco escrita em um repositório público. Aí não é DevOps; é pedir para a internet fazer uma auditoria gratuita.

9. Colocando o Kubernetes em prática

Vamos aproveitar o Deployment que acabamos de criar.

Em um cluster acessível pela ferramenta kubectl, salve o exemplo anterior como deployment.yaml e execute:

kubectl apply -f deployment.yaml

Para verificar os Pods:

kubectl get pods

Para consultar o Deployment:

kubectl get deployments

Para inspecionar os detalhes de um Pod:

kubectl describe pod NOME_DO_POD

Substitua NOME_DO_POD pelo nome retornado pelo comando anterior.

Agora, suponha que você queira aumentar a quantidade de réplicas para cinco:

kubectl scale deployment minha-api --replicas=5

O Kubernetes tentará ajustar a quantidade de Pods ao novo estado desejado.

Para observar o resultado:

kubectl get pods

Você verá o processo de criação das novas réplicas. O tempo necessário depende do ambiente, da disponibilidade dos recursos e das imagens utilizadas.

Uma observação importante: o Deployment de exemplo usa Nginx e a porta 80. Ele não precisa de uma imagem Java para funcionar como demonstração, mas uma aplicação real exigiria uma imagem própria e uma configuração adequada.

Também não criamos o Service automaticamente nesse processo. Para aplicar o Service mostrado anteriormente, salve-o em outro arquivo, como service.yaml, e execute:

kubectl apply -f service.yaml

Se quiser testar o acesso ao Nginx localmente em um cluster de desenvolvimento, pode utilizar:

kubectl port-forward service/minha-api 8080:80

Depois, acesse http://localhost:8080.

Esse encaminhamento é útil para testes e depuração, mas não substitui uma estratégia de exposição de serviços em produção.

10. Como o Kubernetes lida com falhas?

Imagine que uma das três réplicas da sua API pare de funcionar.

Em um cenário bem configurado, o Kubernetes pode detectar que o Pod deixou de existir e criar outro para manter a quantidade desejada.

Mas existem diferentes tipos de falha, e cada um exige mecanismos apropriados.

Liveness probe: a aplicação continua viva?

A liveness probe ajuda a identificar quando um container precisa ser reiniciado.

Se uma aplicação ficar travada e não conseguir se recuperar sozinha, uma probe configurada corretamente pode permitir que o Kubernetes reinicie o container.

Readiness probe: a aplicação está pronta para receber tráfego?

Uma aplicação pode estar em execução, mas ainda não estar pronta para atender requisições.

Ela pode estar inicializando, carregando configurações ou aguardando uma dependência essencial.

A readiness probe ajuda a determinar se o container está pronto para receber tráfego. Quando não está, o Kubernetes pode deixar de encaminhar requisições para aquele Pod por meio dos mecanismos de serviço.

Startup probe: a aplicação terminou de iniciar?

Algumas aplicações demoram mais para inicializar. Uma startup probe permite acomodar esse período sem que verificações de liveness prematuras provoquem reinicializações desnecessárias.

Essas três verificações têm objetivos diferentes. Configurá-las corretamente é mais importante do que simplesmente adicioná-las ao YAML para deixar o arquivo com aparência profissional.

E vale lembrar: reiniciar uma aplicação não resolve um bug permanente. Se o processo falhar sempre que recebe determinada requisição, o Kubernetes poderá reiniciá-lo repetidamente sem corrigir a causa.

11. Escalabilidade: mais usuários, mais capacidade

Uma das vantagens do Kubernetes é facilitar a ampliação da quantidade de réplicas de uma aplicação.

Mas precisamos distinguir duas coisas:

Escalabilidade horizontal: adicionar ou remover instâncias da aplicação.

Escalabilidade vertical: aumentar ou reduzir os recursos destinados a uma instância, como CPU e memória.

O Kubernetes pode ajudar nas duas estratégias, dependendo da configuração.

No caso horizontal, o Horizontal Pod Autoscaler (HPA) pode ajustar o número de réplicas de um Deployment ou de outro recurso compatível, utilizando métricas como utilização de CPU e memória ou métricas personalizadas.

Por exemplo, você pode definir um intervalo de duas a dez réplicas para uma API.

Isso não significa que o HPA aumentará automaticamente a quantidade de instâncias sempre que houver muitos usuários. O comportamento depende das métricas disponíveis, das metas configuradas e da capacidade do cluster.

Além disso, se todos os nós estiverem sem recursos, solicitar mais Pods não fará surgir memória do nada. Será necessário ter capacidade disponível ou utilizar mecanismos de escalabilidade da infraestrutura, como um autoscaler de nós, quando disponível.

Escalar não é apenas multiplicar containers. É garantir que a aplicação, o banco de dados, a rede e os demais componentes consigam acompanhar o crescimento.

12. Docker e Kubernetes são concorrentes?

Não exatamente. Essa é uma confusão comum entre quem está começando.

O Docker é uma plataforma e um conjunto de ferramentas para construir imagens, executar containers e gerenciar o ciclo de vida deles.

O Kubernetes é uma plataforma de orquestração que coordena aplicações em containers em um cluster.

Eles atuam em níveis diferentes e podem fazer parte da mesma arquitetura.

Existe, porém, um detalhe técnico importante: o Kubernetes moderno não depende do Docker Engine para executar containers nos nós do cluster.

Ele utiliza uma interface chamada Container Runtime Interface (CRI), que permite integrar runtimes compatíveis, como o containerd e o CRI-O.

O Docker Engine não implementa diretamente essa interface da forma exigida pelo Kubernetes moderno. Por isso, o antigo dockershim foi removido do Kubernetes a partir da versão 1.24.

Isso não significa que você deva abandonar o Docker.

Você continua podendo utilizar Docker para construir imagens, testar aplicações localmente e publicar imagens em um registry. Essas imagens podem ser executadas no Kubernetes por meio de runtimes compatíveis.

Em resumo: você pode construir sua aplicação com Docker e executá-la no Kubernetes sem precisar utilizar o Docker Engine como runtime dos nós.

13. E onde entra o CI/CD?

Até agora, construímos imagens e aplicamos configurações manualmente. Em um projeto real, queremos que o processo de entrega seja repetível, seguro e, sempre que possível, automatizado.

É aqui que entram CI e CD.

CI (Continuous Integration): automatiza atividades como compilação, testes e validações durante a integração das mudanças.
CD (Continuous Delivery ou Continuous Deployment): automatiza etapas de preparação e entrega de software. Dependendo da estratégia, a publicação pode exigir aprovação ou ocorrer automaticamente.

Imagine que você enviou uma alteração para o repositório da sua API Java.

Um pipeline poderia executar as seguintes etapas:

Baixar o código do repositório.
Compilar a aplicação com Maven.
Executar os testes automatizados.
Construir a imagem Docker.
Publicar a imagem em um registry.
Atualizar o Deployment no Kubernetes.
Acompanhar a implantação e verificar se a nova versão ficou saudável.

Ferramentas como GitHub Actions, GitLab CI e Jenkins podem automatizar partes desse processo.

O Kubernetes, por sua vez, oferece mecanismos de atualização gradual. Em um Deployment, uma nova versão pode substituir a anterior progressivamente, de acordo com a estratégia configurada.

Isso ajuda a reduzir interrupções, mas não garante que toda implantação será segura. É preciso considerar compatibilidade entre versões, alterações no banco de dados, monitoramento e estratégias de reversão.

Afinal, automatizar um erro não faz dele uma boa prática. Apenas faz com que ele aconteça mais rápido.

14. Os problemas que aparecem quando você chega à produção

Aprender os comandos básicos é apenas o começo. Em ambientes reais, a complexidade está nos detalhes.

Segurança das imagens

Utilize imagens confiáveis, mantenha-as atualizadas, evite executar processos como root quando não for necessário e verifique vulnerabilidades nas dependências.

Uma imagem pequena e atualizada pode reduzir a superfície de ataque, mas não elimina todos os riscos.

Limites de CPU e memória

É importante configurar requests e limits de recursos de acordo com as necessidades da aplicação.

Requests ajudam o Kubernetes a decidir onde agendar os Pods. Limits estabelecem restrições de utilização de determinados recursos, conforme o tipo de recurso e a configuração.

Valores mal definidos podem prejudicar o desempenho, causar falta de recursos ou provocar reinicializações por falta de memória.

Persistência dos dados

Containers e Pods podem ser substituídos. Por isso, bancos de dados e outros serviços com estado exigem planejamento específico para armazenamento, backup, recuperação e disponibilidade.

Executar um PostgreSQL em um container é perfeitamente possível. Administrar um PostgreSQL crítico em produção, entretanto, envolve muito mais do que iniciar esse container.

Observabilidade

Quando uma aplicação falha, você precisa descobrir por quê.

Logs ajudam a entender os eventos. Métricas ajudam a acompanhar consumo de recursos, latência e taxas de erro. Traces distribuídos ajudam a seguir requisições que passam por vários serviços.

Sem observabilidade, seu cluster pode até estar funcionando, mas você estará administrando tudo no escuro.

Alta disponibilidade

Executar três réplicas não garante, por si só, alta disponibilidade.

Se todas estiverem no mesmo nó e esse nó falhar, as três podem ficar indisponíveis ao mesmo tempo.

Distribuição entre nós, redundância, capacidade disponível, armazenamento, rede e dependências externas precisam ser considerados no desenho da arquitetura.

Alta disponibilidade é uma propriedade do sistema como um todo, não uma opção mágica no arquivo YAML.

15. Você realmente precisa de Kubernetes?

Depois de tudo isso, talvez você esteja pensando:

“Legal, mas preciso aprender Kubernetes para publicar minha API?”

A resposta honesta é: depende.

Para uma aplicação pequena, um Dockerfile e um Docker Compose podem ser suficientes. Uma API com pouco tráfego talvez funcione muito bem em um serviço de hospedagem que cuide da infraestrutura para você.

O Kubernetes começa a fazer mais sentido quando há necessidades concretas de orquestração, escalabilidade, padronização de deploys, gerenciamento de vários serviços ou operação de aplicações distribuídas.

Por outro lado, ele também traz custos: complexidade operacional, configuração, monitoramento, segurança e manutenção.

Não é raro ver equipes pequenas adotando Kubernetes antes de realmente precisarem dele e gastando mais tempo administrando a infraestrutura do que desenvolvendo o produto.

É como comprar um caminhão de mudança para transportar uma mochila. É possível, mas talvez você esteja complicando um problema simples.

A melhor arquitetura não é a que utiliza mais tecnologias. É a que resolve o problema com um nível de complexidade compatível com as necessidades do projeto.

16. Um roteiro para continuar aprendendo

Se você está começando, recomendo seguir uma sequência gradual:

Etapa 1: Fundamentos de containers

Instale o Docker.
Aprenda imagens, containers, volumes e redes.
Construa uma imagem para uma aplicação simples.
Pratique os comandos build, run, ps, logs, stop e rm.

Etapa 2: Aplicações com vários serviços

Crie uma API REST.
Conecte-a a um PostgreSQL.
Utilize Docker Compose.
Configure variáveis de ambiente e volumes.
Aprenda a investigar falhas de conexão.

Etapa 3: Primeiros passos com Kubernetes

Utilize um ambiente local, como Kind, Minikube ou outro cluster de desenvolvimento.
Aprenda Pods, Deployments e Services.
Pratique com kubectl.
Entenda ConfigMaps, Secrets e probes.

Etapa 4: Preparação para produção

Configure requests e limits.
Estude HPA, estratégias de atualização e recuperação.
Aprenda conceitos de segurança, observabilidade e armazenamento persistente.
Automatize testes e deploys com CI/CD.

Etapa 5: Arquitetura e operação

Estude redes, DNS, ingress e balanceamento de carga.
Entenda a distribuição de workloads entre nós.
Explore Helm, GitOps e políticas de segurança.
Aprenda a diagnosticar problemas em sistemas distribuídos.

Você não precisa dominar todas essas ferramentas de uma vez. O objetivo é compreender o problema que cada uma resolve e aprender a utilizá-las quando fizerem sentido.

Conclusão: menos improviso, mais previsibilidade

Docker e Kubernetes representam duas partes importantes da evolução na maneira como desenvolvemos e operamos software.

O Docker ajuda a empacotar aplicações em ambientes reproduzíveis, reduzindo diferenças entre desenvolvimento, testes e produção.

O Kubernetes permite coordenar aplicações em containers, administrar réplicas, responder a determinadas falhas e automatizar tarefas de operação em clusters.

Mas a lição mais importante não é decorar comandos ou aprender a escrever arquivos YAML de cabeça.

É entender que software não termina quando o código funciona no computador do desenvolvedor. Ele precisa ser construído, distribuído, executado, monitorado, atualizado e recuperado quando algo dá errado.

Docker ajuda a tornar a execução mais previsível. Kubernetes ajuda a administrar a complexidade quando a operação cresce.

E, se depois de tudo isso alguém disser que a aplicação funciona apenas na máquina dele, você já terá algumas perguntas melhores para fazer.

A primeira talvez seja:

“Beleza. E qual imagem você utilizou?”

Porque, convenhamos, “na minha máquina funciona” pode até ser uma boa desculpa. Mas, em produção, não deveria ser uma estratégia de arquitetura.

Maven, o nosso orquestrador

Sun, 21 Feb 2021 00:00:00 GMT

Maven: o que é e por que todo desenvolvedor Java deveria conhecê-lo

Provavelmente já encontrou um arquivo chamado pom.xml em algum projeto.

Talvez também tenha visto comandos como:

mvn clean install

ou:

mvn spring-boot:run

Mas afinal, o que é o Maven?

De forma simples, o Apache Maven é uma ferramenta de automação de build e gerenciamento de projetos Java. Ele ajuda a baixar bibliotecas, compilar o código, executar testes, empacotar a aplicação e até publicar artefatos.

Mas essa definição ainda não explica por que ele é tão presente no ecossistema Java.

Para entender isso, precisamos voltar um pouco.

O problema que o Maven resolve

Imagine que você está criando uma API Java.

Seu projeto precisa de:

Spring Boot - Facilita a criação de aplicações independentes;
PostgreSQL - Gerenciamento de banco de dados relacional;
JUnit - Framework padrão para testes unitários em Java;
Mockito - Biblioteca de simulação para Java;
Jackson - Biblioteca Java para processamento de dados JSON;
Hibernate - Framework de mapeamento (ORM) para Java.

Todas essas bibliotecas são arquivos .jar.

Sem uma ferramenta de gerenciamento de dependências, você teria que:

procurar cada biblioteca;
baixar os arquivos .jar;
colocá-los no projeto;
descobrir quais outras bibliotecas elas precisam;
resolver conflitos entre versões;
configurar o classpath;
repetir tudo isso quando alguma biblioteca fosse atualizada.

E aqui aparece um problema ainda maior.

Imagine que o Spring Boot dependa de uma biblioteca A, que depende da biblioteca B, que depende da biblioteca C.

Você realmente quer descobrir e baixar todas essas dependências manualmente?

É justamente nesse tipo de situação que o Maven começa a fazer sentido.

Plus: O que é uma biblioteca (Lib)?

Uma biblioteca, no sentido geral, é uma coleção de classes que fornecem ferramentas para que você, como desenvolvedor, não precise escrever essas ferramentas.

O que é o Maven?

O Apache Maven é uma ferramenta de build para projetos Java.

Segundo a própria documentação do projeto, ele utiliza um Project Object Model (POM) para gerenciar aspectos como compilação, testes e documentação do projeto.

Na prática, o Maven ajuda a padronizar tarefas que aparecem constantemente no desenvolvimento Java:

Código-fonte
    ↓
Compilação
    ↓
Testes
    ↓
Empacotamento
    ↓
Artefato

Por exemplo, uma aplicação pode terminar como:

meu-projeto.jar

O Maven consegue cuidar de grande parte desse processo.

Mas talvez a funcionalidade mais conhecida seja outra:

Gerenciar as dependências do projeto.

O `pom.xml`

Quando você cria um projeto Maven, um dos arquivos mais importantes é:

pom.xml

POM significa:

Project Object Model

Ele é o arquivo central de configuração do Maven.

É nele que podemos definir informações como:

nome do projeto;
versão;
Java utilizado;
dependências;
plugins;
tipo de empacotamento;
configurações de build;
informações do projeto.

Um exemplo simples:

<project>
    <modelVersion>4.0.0</modelVersion>

    <groupId>br.com.exemplo</groupId>
    <artifactId>minha-api</artifactId>
    <version>1.0.0</version>

</project>

Esse arquivo funciona como uma espécie de contrato do projeto com o Maven.

O Maven lê o pom.xml e, a partir dessas informações, sabe como trabalhar com o projeto.

Entendendo `groupId`, `artifactId` e `version`

Você provavelmente verá esses três elementos em praticamente todo projeto Maven.

<groupId>br.com.exemplo</groupId>
<artifactId>minha-api</artifactId>
<version>1.0.0</version>

Eles identificam o projeto.

`groupId`

Normalmente representa a organização ou grupo responsável pelo projeto.

Por exemplo:

<groupId>com.google.guava</groupId>

ou:

<groupId>br.com.salvaai</groupId>

`artifactId`

É o nome do artefato/projeto.

Por exemplo:

<artifactId>minha-api</artifactId>

`version`

Representa a versão:

<version>1.0.0</version>

Juntos, esses valores formam as chamadas coordenadas Maven de um artefato.

E as dependências?

Agora chegamos a uma das partes mais importantes.

Suponha que nossa aplicação precise do Spring Web.

Em vez de baixar manualmente um .jar, podemos declarar a dependência no pom.xml:

<dependencies>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <version>3.5.6</version>
    </dependency>

</dependencies>

A partir disso, o Maven consegue resolver e baixar a dependência necessária.

E existe uma característica extremamente importante:

Dependências transitivas

Imagine:

Minha aplicação
       ↓
Biblioteca A
       ↓
Biblioteca B
       ↓
Biblioteca C

Se a Biblioteca A precisa da Biblioteca B, que por sua vez precisa da Biblioteca C, o Maven consegue resolver essas dependências transitivamente.

Ou seja, você não precisa declarar manualmente cada biblioteca necessária por suas dependências.

É uma das razões pelas quais gerenciar projetos Java grandes seria muito mais trabalhoso sem uma ferramenta como o Maven.

De onde o Maven baixa as bibliotecas?

Você pode imaginar que existe uma enorme biblioteca online contendo milhares de artefatos Java.

Esse papel é desempenhado principalmente pelo Maven Central Repository, um dos principais repositórios públicos de dependências do ecossistema Java.

Quando você adiciona uma dependência ao pom.xml, o Maven procura o artefato nos repositórios configurados e pode armazená-lo no seu repositório local.

Por isso, depois de baixar uma dependência uma vez, ela normalmente não precisa ser baixada novamente para cada projeto.

O fluxo pode ser entendido assim:

pom.xml
   ↓
Maven
   ↓
Repositório remoto
   ↓
Dependência
   ↓
Repositório local
   ↓
Projeto

O repositório local

O Maven mantém um repositório local na máquina do desenvolvedor.

No Linux e macOS, normalmente ele fica em:

~/.m2/repository

No Windows:

C:\Users\SEU_USUARIO\.m2\repository

Imagine que você utilize:

<artifactId>junit-jupiter</artifactId>

Depois que o Maven baixa essa dependência, ela fica disponível no repositório local.

Isso também ajuda a evitar downloads desnecessários.

O ciclo de vida do Maven

Outra ideia fundamental do Maven é o Build Lifecycle.

Em vez de cada projeto inventar seus próprios comandos e etapas de build, o Maven possui ciclos de vida padronizados.

O ciclo default, por exemplo, possui várias fases.

Algumas das mais conhecidas são:

validate
   ↓
compile
   ↓
test
   ↓
package
   ↓
verify
   ↓
install
   ↓
deploy

Cada fase representa uma etapa do processo de construção do projeto.

Vamos entender algumas delas.

`compile`

Compila o código-fonte.

mvn compile

`test`

Executa os testes.

mvn test

`package`

Empacota a aplicação.

Por exemplo:

target/
└── minha-api-1.0.0.jar

Com:

mvn package

`install`

Além de construir o artefato, instala o resultado no repositório local.

mvn install

`deploy`

Pode publicar o artefato em um repositório remoto configurado.

mvn deploy

Essas fases são executadas em sequência.

Por exemplo, quando você executa:

mvn package

o Maven não executa apenas package.

Ele passa pelas fases anteriores necessárias:

validate
   ↓
compile
   ↓
test
   ↓
package

Isso torna o processo de build previsível e padronizado.

E o famoso `mvn clean install`?

Você provavelmente encontrará esse comando em praticamente qualquer projeto Java baseado em Maven:

mvn clean install

Mas o que ele faz?

Primeiro:

mvn clean

Remove os arquivos gerados pelo build anterior.

Normalmente isso significa remover a pasta:

target/

Depois:

mvn install

Executa o ciclo necessário até instalar o artefato no repositório local.

Simplificando:

clean
  ↓
remove build anterior
  ↓
compile
  ↓
test
  ↓
package
  ↓
install

É uma maneira bastante comum de garantir que o projeto seja reconstruído do zero.

O que é a pasta `target`?

Se você executar:

mvn package

provavelmente verá uma pasta:

target/

Ela contém arquivos gerados pelo Maven durante o processo de build.

Por exemplo:

target/
├── classes/
├── test-classes/
├── surefire-reports/
└── minha-api-1.0.0.jar

Essa pasta normalmente não deve ser versionada no Git.

Por isso, projetos Java geralmente possuem no .gitignore:

target/

Maven e plugins

O Maven não faz tudo sozinho.

Grande parte de sua funcionalidade é fornecida através de plugins.

Por exemplo, existem plugins responsáveis por tarefas como:

compilação;
testes;
empacotamento;
documentação;
análise de dependências;
execução de aplicações.

Isso torna o Maven extensível.

Por exemplo, o processo de compilação pode utilizar o Maven Compiler Plugin.

Já os testes unitários podem ser executados pelo Maven Surefire Plugin.

Na documentação oficial, as fases do lifecycle possuem bindings que associam determinadas fases a goals de plugins.

Maven não é apenas um gerenciador de dependências

É comum alguém dizer:

“Maven é o gerenciador de dependências do Java.”

Não está totalmente errado, mas é uma definição incompleta.

O Maven também é responsável por automatizar o processo de build.

Podemos pensar nele como:

                Maven
                  │
       ┌──────────┼──────────┐
       ↓          ↓          ↓
Dependências    Build      Testes
       │          │          │
       ↓          ↓          ↓
   Bibliotecas  JAR/WAR   JUnit etc.

Ele também possui mecanismos para documentação, publicação de artefatos, projetos multimódulo e gerenciamento de informações do projeto.

Maven x compilador Java

Uma dúvida comum é:

“Mas o Java já não possui um compilador?”

Sim.

O Java possui o javac, responsável por compilar código Java.

Por exemplo:

javac Main.java

O problema é que um projeto real normalmente envolve muito mais coisas.

Você precisa:

organizar o projeto;
encontrar dependências;
configurar o classpath;
compilar dezenas ou centenas de arquivos;
executar testes;
empacotar o resultado;
controlar versões;
eventualmente publicar o artefato.

O Maven automatiza esse conjunto de tarefas.

Em outras palavras:

javac
↓
compila Java

Enquanto:

Maven
↓
organiza e automatiza o processo de build

O Maven inclusive utiliza plugins para realizar determinadas etapas, como a compilação.

A estrutura padrão de um projeto Maven

Outra vantagem do Maven é a padronização.

Um projeto costuma seguir uma estrutura parecida com:

meu-projeto/
│
├── pom.xml
│
└── src/
    ├── main/
    │   ├── java/
    │   └── resources/
    │
    └── test/
        ├── java/
        └── resources/

Código da aplicação:

src/main/java

Recursos:

src/main/resources

Testes:

src/test/java

Testes e recursos possuem uma estrutura paralela à aplicação.

Isso significa que, ao abrir um projeto Maven novo, você não precisa descobrir do zero onde cada coisa está.

O próprio Maven estabelece convenções para essa estrutura.

Maven e Spring Boot

Se você está estudando Java para desenvolvimento backend, provavelmente encontrará Maven principalmente através do Spring Boot.

Ao criar uma aplicação Spring Boot, é comum receber um pom.xml semelhante a:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.5.6</version>
</parent>

<dependencies>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>

</dependencies>

Perceba algo interessante.

Em muitos casos, você nem precisa informar a versão individualmente de cada dependência.

Isso acontece porque o projeto pode utilizar um parent POM ou mecanismos como dependencyManagement para centralizar versões e configurações.

Alguns comandos que você deve conhecer

Se você está começando com Maven, estes comandos já cobrem uma boa parte do seu dia a dia:

Compilar

mvn compile

Executar testes

mvn test

Gerar o artefato

mvn package

Limpar o projeto

mvn clean

Limpar e gerar novamente

mvn clean package

Limpar, testar, empacotar e instalar localmente

mvn clean install

Visualizar a árvore de dependências

mvn dependency:tree

Esse último é especialmente útil quando você começa a enfrentar conflitos de versões entre bibliotecas.

O próprio Maven disponibiliza o dependency:tree para visualizar a árvore de dependências resolvida.

Então, preciso decorar todos esses comandos?

Não.

Mais importante do que decorar comandos é entender o modelo mental do Maven.

Quando você vê:

mvn clean package

deve conseguir interpretar:

“Quero limpar os arquivos gerados anteriormente e executar o processo de build até gerar o pacote.”

Quando vê:

mvn dependency:tree

deve pensar:

“Quero descobrir quais dependências meu projeto está utilizando e de onde elas vieram.”

E quando abre:

pom.xml

deve pensar:

“Aqui está a definição e boa parte da configuração do meu projeto Maven.”

Maven em uma analogia

Imagine que você abriu um restaurante.

Você poderia:

comprar todos os ingredientes manualmente;
procurar fornecedores;
controlar estoque;
calcular o que precisa ser comprado;
preparar os ingredientes;
organizar a cozinha;
preparar os pratos;
limpar tudo no final.

Ou poderia utilizar um sistema que organiza boa parte desse processo.

O Maven é parecido com esse sistema para um projeto Java.

Você declara:

“Meu projeto precisa dessas ferramentas e bibliotecas.”

E o Maven cuida de grande parte da infraestrutura necessária para transformar:

Código-fonte

em:

Aplicação pronta para ser executada/distribuída

Maven é obrigatório para Java?

Não.

Java não depende do Maven para funcionar.

Existem outras alternativas, como o Gradle, além de ferramentas e abordagens diferentes.

O Maven, porém, tornou-se uma ferramenta extremamente difundida no ecossistema Java e aparece em uma enorme quantidade de projetos.

Por isso, para quem está entrando no desenvolvimento Java profissional, entender Maven é muito mais importante do que simplesmente saber executar mvn clean install.

O objetivo é entender o que está acontecendo por trás do comando.

O que você realmente precisa aprender?

Se você está começando agora, não precisa estudar toda a documentação do Maven.

Comece entendendo estes conceitos:

1. O que é o Maven
       ↓
2. O que é o pom.xml
       ↓
3. Dependências
       ↓
4. Dependências transitivas
       ↓
5. Repositório local
       ↓
6. Maven Central
       ↓
7. Build Lifecycle
       ↓
8. Plugins
       ↓
9. Packaging
       ↓
10. dependencyManagement

Depois disso, ferramentas como Spring Boot, Docker e pipelines de CI/CD começam a fazer muito mais sentido, porque você entende onde o Maven se encaixa dentro do processo de desenvolvimento.

Conclusão

O Maven nasceu de uma necessidade bastante prática: padronizar e simplificar o processo de construção de projetos Java. Desde então, tornou-se uma das ferramentas fundamentais do ecossistema.

Ele não serve apenas para baixar bibliotecas.

Ele ajuda a:

gerenciar dependências;
compilar código;
executar testes;
empacotar aplicações;
padronizar a estrutura dos projetos;
gerenciar plugins;
trabalhar com projetos multimódulo;
publicar artefatos.

E talvez a melhor forma de resumir o Maven seja:

Você descreve como seu projeto é organizado e quais são suas necessidades; o Maven automatiza boa parte do trabalho necessário para construir esse projeto.

Se você está seguindo uma trilha de estudos de Java, entender Maven é um daqueles assuntos que parecem simples no começo, mas que vão economizar bastante tempo conforme seus projetos ficam maiores.

Referências

Desmistificando o JVM, JRE e JDK

Mon, 15 Feb 2021 00:00:00 GMT

JVM, JRE e JDK: afinal, qual é a diferença?

Se você está começando a estudar Java, provavelmente já encontrou três siglas que aparecem o tempo todo:

JVM, JRE e JDK.

À primeira vista, elas parecem representar praticamente a mesma coisa. E, para piorar, muitos materiais explicam esses conceitos usando definições bastante técnicas antes mesmo de explicar como eles se relacionam.

Uma forma simples de entender isso é imaginar que estamos falando de uma cozinha.

🍳 Imagine que Java é uma cozinha

Vamos começar pelo conceito mais importante.

Quando escrevemos um programa Java, o código que criamos não é executado diretamente pelo sistema operacional.

Por exemplo, podemos escrever:

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

Esse código é transformado pelo compilador em bytecode, normalmente armazenado em um arquivo .class.

É aí que entram JVM, JRE e JDK.

JVM — o cozinheiro

A JVM (Java Virtual Machine) pode ser comparada ao cozinheiro da nossa cozinha.

É ela quem pega o bytecode Java e efetivamente executa o programa.

Quando você executa:

java Main

a JVM entra em ação.

Ela interpreta ou compila o bytecode para instruções que o computador consegue executar, utilizando técnicas como JIT (Just-In-Time compilation) durante a execução.

E aqui está uma das grandes ideias por trás do Java:

O mesmo bytecode pode ser executado em diferentes sistemas operacionais, desde que exista uma JVM adequada para aquele sistema.

Por isso, podemos ter:

             Main.class
                 │
        ┌────────┼────────┐
        ↓        ↓        ↓
      JVM      JVM      JVM
    Windows    Linux    macOS
        │        │        │
        ↓        ↓        ↓
      CPU      CPU      CPU

O bytecode continua sendo o mesmo.

O que muda é a implementação da JVM responsável por conversar com o sistema operacional e o hardware.

É daí que vem a famosa ideia:

“Write once, run anywhere.”

Escreva uma vez, execute em qualquer lugar.

JRE — a cozinha

Agora imagine que o cozinheiro sozinho não consegue fazer muita coisa.

Ele precisa de uma cozinha, utensílios, ingredientes e toda a estrutura necessária para preparar o prato.

Essa é uma boa forma de imaginar o JRE (Java Runtime Environment).

Conceitualmente, o JRE representa o ambiente necessário para executar aplicações Java.

Podemos simplificar assim:

JRE
├── JVM
└── Bibliotecas necessárias para execução

Ou, usando nossa analogia:

JRE = Cozinha + Cozinheiro + Recursos necessários

Se você simplesmente quer executar uma aplicação Java, você não precisa necessariamente de todas as ferramentas utilizadas pelo desenvolvedor para construir aquela aplicação.

É a diferença entre:

“Quero preparar esta receita.”

“Quero criar novas receitas.”

No primeiro caso, precisamos da estrutura necessária para cozinhar.

No segundo, precisamos de ferramentas adicionais.

JDK — a cozinha completa para o desenvolvedor

É aí que entra o JDK (Java Development Kit).

Se o JRE representa o ambiente necessário para executar aplicações Java, o JDK representa o conjunto de ferramentas necessário para desenvolver essas aplicações.

Podemos imaginar:

JDK
├── JRE
│   └── JVM
└── Ferramentas de desenvolvimento

Entre essas ferramentas está o famoso:

javac

O javac é o compilador Java.

Quando fazemos:

javac Main.java

o compilador transforma nosso código-fonte:

Main.java

em bytecode:

Main.class

Depois, podemos executar esse bytecode utilizando a JVM:

java Main

Portanto, o fluxo simplificado seria:

        Desenvolvedor
             │
             ↓
         Main.java
             │
             │ javac
             ↓
         Main.class
             │
             │ JVM
             ↓
        Programa rodando

Então qual é a diferença?

Podemos resumir tudo em uma frase:

JDK desenvolve, JRE fornece o ambiente de execução e JVM executa o bytecode.

Ou, usando nossa analogia:

Conceito	Analogia	Responsabilidade
JVM	👨‍🍳 Cozinheiro	Executa o bytecode
JRE	🍳 Cozinha	Fornece o ambiente necessário para executar Java
JDK	🧰 Cozinha completa	Fornece ferramentas para desenvolver aplicações Java

A relação pode ser visualizada desta maneira:

┌─────────────────────────────────┐
│              JDK                │
│                                 │
│   ┌─────────────────────────┐   │
│   │          JRE            │   │
│   │                         │   │
│   │      ┌───────────┐      │   │
│   │      │    JVM    │      │   │
│   │      └───────────┘      │   │
│   │                         │   │
│   └─────────────────────────┘   │
│                                 │
│  + ferramentas de desenvolvimento│
└─────────────────────────────────┘

Mas existe um detalhe importante

Essa representação é muito útil para entender os conceitos, mas existe uma ressalva importante.

Atualmente, especialmente a partir do Java 11, a ideia de instalar um “JRE separado” não funciona mais da mesma forma que funcionava em versões antigas do Java.

Distribuições modernas do OpenJDK normalmente são distribuídas como JDKs, e ferramentas como jlink podem ser utilizadas para criar runtimes personalizados.

Por isso, hoje é comum um desenvolvedor simplesmente instalar um JDK, como:

OpenJDK
Temurin
Oracle JDK
Amazon Corretto

e utilizar esse ambiente tanto para desenvolver quanto para executar suas aplicações.

Isso não torna o conceito de JRE inútil.

Pelo contrário.

A distinção continua sendo bastante útil para entender o que uma aplicação Java precisa para ser executada e quais componentes fazem parte do ecossistema Java.

E onde entra o Java?

Aqui existe outra confusão bastante comum.

Quando falamos “Java”, podemos estar falando de coisas diferentes:

Java
├── Linguagem Java
├── Plataforma Java
├── JVM
├── Bibliotecas
└── Ferramentas do JDK

A linguagem é aquilo que escrevemos:

System.out.println("Hello World");

O compilador transforma esse código em bytecode.

A JVM executa esse bytecode.

E o JDK fornece as ferramentas necessárias para construir todo esse processo.

Uma analogia completa

Voltando para nossa cozinha, podemos pensar em todo o processo assim:

Você é o desenvolvedor.

Você escreve uma receita:

Main.java

O JDK fornece as ferramentas necessárias para transformar essa receita em algo que possa ser executado.

O JRE representa a estrutura necessária para executar aquilo.

E a JVM é quem efetivamente prepara a receita.

No final:

Você
 │
 │ escreve
 ↓
Java (.java)
 │
 │ JDK / javac
 ↓
Bytecode (.class)
 │
 │ JVM
 ↓
Aplicação executando

Essa separação é uma das características que tornam o ecossistema Java tão interessante.

O programa não precisa ser compilado diretamente para cada sistema operacional.

Ele é compilado para bytecode, e a JVM de cada plataforma fica responsável por executar esse bytecode.

Para guardar

Se você está começando no Java, não precisa decorar dezenas de definições.

Lembre apenas:

JDK → ferramentas para desenvolver

JRE → ambiente para executar

JVM → máquina virtual que executa o bytecode

Ou, na nossa cozinha:

👨‍💻 JDK é o kit do desenvolvedor.

🍳 JRE é o ambiente de execução.

👨‍🍳 JVM é quem executa o programa.

Entendendo essa relação, fica muito mais fácil compreender o restante do ecossistema Java.

Bem-vindo ao SalvaAí

Fri, 25 Sep 2020 00:00:00 GMT

O SalvaAí é o meu portal para artigos, manuais e comentários sobre tecnologia e o que mais valer a pena salvar.

O que você vai encontrar

Artigos: textos sobre Java e tecnologia, comentários sobre notícias e opiniões.
Manuais: guias sobre temas específicos, organizados para consultar sempre que precisar.

Quem sou eu?

Sou João Pedro Ramos Campêlo, de Recife. Sou formado em Análise e Desenvolvimento de Sistemas e gosto do ponto em que tecnologia e finanças se encontram.

Passei quatro anos na TOTVS, onde trabalhei com clientes de diversos setores. Foi ali que aprendi a traduzir regra de negócio em solução técnica e a conversar com quem não é da área de tecnologia, e foi ali também que comecei a desenvolver, por iniciativa própria, em ADVPL.

Meu foco de estudo e de construção é backend em Java, com Spring Boot, APIs REST e banco de dados relacional. Fora do trabalho, desenvolvo dois projetos próprios. O Whallet (whallet.com.br) é uma plataforma de gestão financeira para MEIs e pequenas empresas, que já está no ar com usuários acessando. O WhalletRoute é uma plataforma de roteirização e gestão de cargas, ainda em construção.

Também faço pós-graduação em Arquitetura de Sistemas na FIAP, e boa parte dos temas daqui vem dessa rotina.

O SalvaAí nasceu disso. Escrevo para fixar o que estudo e deixo registrado o que pode ajudar quem está no mesmo caminho.

Use a busca (tecla /) ou navegue pelos temas para encontrar o que procura.

SalvaAí | Artigos

Desmistificando Docker e Kubernetes

Docker e Kubernetes: do “funciona na minha máquina” até aplicações em produção

1. O famoso “na minha máquina funciona”

2. Primeiro, vamos entender o que é o Docker

2.1. O que é um container?

2.2. Container não é a mesma coisa que máquina virtual

3. Antes do Docker, precisamos conhecer três conceitos

3.1. Imagem: a receita da aplicação

3.2. Container: a receita em execução

3.3. Dockerfile: as instruções para construir a imagem

4. Colocando a mão na massa

5. E se minha aplicação precisar de um banco de dados?

5.1. Docker Compose: quando um container não é suficiente

6. Até aqui, o Docker resolveu muita coisa. Mas e quando o sistema cresce?

7. Kubernetes: o gerente dos containers

8. Entendendo os principais conceitos do Kubernetes

8.1. Cluster

8.2. Pod

8.3. Deployment

8.4. Service

8.5. ConfigMaps e Secrets

9. Colocando o Kubernetes em prática

10. Como o Kubernetes lida com falhas?

Liveness probe: a aplicação continua viva?

Readiness probe: a aplicação está pronta para receber tráfego?

Startup probe: a aplicação terminou de iniciar?

11. Escalabilidade: mais usuários, mais capacidade

12. Docker e Kubernetes são concorrentes?

13. E onde entra o CI/CD?

14. Os problemas que aparecem quando você chega à produção

Segurança das imagens

Limites de CPU e memória

Persistência dos dados

Observabilidade

Alta disponibilidade

15. Você realmente precisa de Kubernetes?

16. Um roteiro para continuar aprendendo

Conclusão: menos improviso, mais previsibilidade

Maven, o nosso orquestrador

Maven: o que é e por que todo desenvolvedor Java deveria conhecê-lo

O problema que o Maven resolve

Plus: O que é uma biblioteca (Lib)?

O que é o Maven?

O pom.xml

Entendendo groupId, artifactId e version

groupId

artifactId

version

E as dependências?

Dependências transitivas

De onde o Maven baixa as bibliotecas?

O repositório local

O ciclo de vida do Maven

compile

test

package

install

deploy

E o famoso mvn clean install?

O que é a pasta target?

Maven e plugins

Maven não é apenas um gerenciador de dependências

Maven x compilador Java

A estrutura padrão de um projeto Maven

Maven e Spring Boot

Alguns comandos que você deve conhecer

Compilar

Executar testes

Gerar o artefato

Limpar o projeto

Limpar e gerar novamente

Limpar, testar, empacotar e instalar localmente

Visualizar a árvore de dependências

Então, preciso decorar todos esses comandos?

Maven em uma analogia

Maven é obrigatório para Java?

O que você realmente precisa aprender?

Conclusão

Referências

O `pom.xml`

Entendendo `groupId`, `artifactId` e `version`

`groupId`

`artifactId`

`version`

`compile`

`test`

`package`

`install`

`deploy`

E o famoso `mvn clean install`?

O que é a pasta `target`?