Otimização do Processo de Build em Projetos Multi-Módulo

Ao migrar arquiteturas baseadas em Maven com múltiplos submódulos para containers, é crucial evitar a redundância no download de dependências e gerenciar corretamente a ordem de compilação. A abordagem recomendada envolve a utilização de builds em múltiplas etapas (multi-stage builds) para separar o ambiente de construção do ambiente de execução.

Na primeira etapa, utiliza-se uma imagem completa do JDK para compilar o código e resolver as dependências. O cache do repositório local do Maven deve ser persistido via volumes para acelerar builds subsequentes. Na etapa final, apenas o artefato compilado é transferido para uma imagem de runtime leve, contendo apenas a JRE.

Exemplo de estrutura Dockerfile otimizada:

FROM eclipse-temurin:17-jdk-alpine AS build
WORKDIR /app
COPY .mvn .mvn
COPY mvnw pom.xml ./
RUN ./mvnw dependency:go-offline -B
COPY src ./src
RUN ./mvnw package -DskipTests

FROM eclipse-temurin:17-jre-alpine
ARG JAR_FILE=target/*.jar
COPY --from=build /app/${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

Esta separação reduz drasticamente o tamanho final da imagem e o tempo de construção, pois a camada de dependências muda com menos frequência que o código fonte.

Gestão de Configurações por Ambiente

A separação entre código e configuração é fundamental para a portabilidade. A estratégia ideal combina arquivos de propriedades base com sobrescrita via variáveis de ambiente. O arquivo application.yml principal deve conter configurações comuns, enquanto variações específicas (dev, staging, prod) são carregadas dinamicamente.

Para controlar o perfil ativo, define-se uma variável de ambiente no container. Isso permite que a mesma imagem seja promovida entre ambientes sem recompilação.

ENV SPRING_PROFILES_ACTIVE=production
ENV DB_PASSWORD_FILE=/run/secrets/db_password

Informações sensíveis, como credenciais de banco de dados, nunca devem ser hardcodadas. Utilize Docker Secrets ou injeção de variáveis de ambiente no momento da orchestration.

Orquestração de Dependências e Persistência

A comunicação entre a aplicação e serviços de infraestrutura, como bancos de dados relacionais e caches, requer uma rede Docker dedicada. Isso garante isolamento e resolução de DNS interna baseada no nome do serviço.

Para garantir a persistência dos dados, volumes nomeados devem ser associados aos containers de estado. O Redis, por exemplo, pode ser configurado para persistência em disco via AOF, enquanto o MySQL requer um volume montado no diretório de dados padrão.

Exemplo de configuração docker-compose.yml:

version: '3.8'
services:
  backend-service:
    build: .
    environment:
      - SPRING_DATASOURCE_URL=jdbc:mysql://db-primary:3306/appdb
    depends_on:
      db-primary:
        condition: service_healthy
      cache-layer:
        condition: service_started
    networks:
      - internal-net

  db-primary:
    image: mysql:8.0
    volumes:
      - sql_storage:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD_FILE=/run/secrets/root_pass
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      retries: 5

  cache-layer:
    image: redis:7-alpine
    command: redis-server --appendonly yes
    volumes:
      - redis_storage:/data
    networks:
      - internal-net

volumes:
  sql_storage:
  redis_storage:

networks:
  internal-net:
    driver: bridge

Ajuste Fino da JVM em Ambientes Containerizados

Executar a JVM dentro de limites de recursos definidos pelo container exige configuração específica para evitar que o processo seja terminado pelo OOM Killer do Linux. Versões modernas do JDK (8u191+, 11+) possuem suporte nativo para detecção de limites de container, mas parâmetros explícitos aumentam a previsibilidade.

Configure a heap máxima como uma porcentagem da memória disponível para o container e habilite logs de diagnóstico para análise pós-falha:

JAVA_OPTS="-XX:+UseContainerSupport \
           -XX:MaxRAMPercentage=70.0 \
           -XX:+HeapDumpOnOutOfMemoryError \
           -XX:HeapDumpPath=/var/log/heapdump.hprof \
           -XX:+ExitOnOutOfMemoryError"

Esses parâmetros garantem que a aplicação respeite o limite de memória do pod ou container e gere artefatos úteis para debugging em caso de estouro.

Diagnóstico de Problemas Comuns

Durante a operação, alguns problemas recorrentes podem surgir devido a diferenças entre o ambiente local e o container:

• Sincronização de Tempo: Containers Linux geralmente usam UTC. Para aplicações que dependem de fuso horário local, defina a variável TZ no Dockerfile ou compose.
• Latência de Inicialização: Verifique se as verificações de saúde (healthchecks) estão configuradsa corretamente para evitar que o orchestrador reinicie o serviço prematuramente enquanto ele ainda está carregando beans.
• Vazamento de Memória: Utilize ferramentas como jmap ou analise os heap dumps gerados para identificar retenção indevida de objetos, especialmente em caches locais.
• Timeout de Rede: Ajuste os intervalos de retry e timeout nas conexões de banco de dados, considerando que a resolução de DNS em redes Docker pode adicionar latência inicial.