Da faculdade ao primeiro sistema em produção: O guia de sobrevivência com Docker

TL;DR: Se o seu projeto só funciona na sua máquina, ele não é um sistema, é um hobby. Aprenda como o Docker Compose tira o peso das suas costas e te dá confiança para o deploy real.

O mito do "na minha máquina funciona"

Todo mundo que passou por ADS tem aquele projeto guardado no peito. O meu era uma API em Java com Spring Boot e PostgreSQL. No meu computador, era lindo.

A realidade bateu na porta quando:

• O banco não subiu no notebook do professor durante a banca.
• O cliente tentou rodar e a porta 5432 já estava ocupada.
• Levei 40 minutos para "ajudar" um colega a configurar o ambiente.

Verdade do mercado em 2026: Ninguém tem tempo para configurar ambiente. Se o seu projeto não sobe com um comando, ele é um custo, não uma solução. Foi aqui que o Docker deixou de ser "hype" e virou minha ferramenta de sobrevivência.

O Dockerfile: Sua aplicação em uma caixa

O objetivo é simples: empacotar o ambiente. Não importa se o servidor tem Java 17, 21 ou se é Linux ou Windows.

# Otimizado para imagens leves
FROM eclipse-temurin:17-jdk-alpine
WORKDIR /app
# Dica: O jar deve ser gerado pelo CI/CD ou via script de build
COPY target/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

O que aprendi na marra: O primeiro Dockerfile a gente nunca esquece, mas o segredo não está na imagem da aplicação, e sim em como ela conversa com o resto.

Docker Compose: Onde o jogo vira

API sozinha não faz nada. Você precisa de banco, talvez um Redis ou um frontend em Vue.js. O compose.yml é o seu manual de instruções automatizado.

O Setup "Pronto para Guerra":

services:
  app:
    build: .
    ports:
      - "8080:8080"
    environment:
      - SPRING_PROFILES_ACTIVE=prod
      - DATABASE_URL=jdbc:postgresql://db:5432/vincens_db
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: vincens_db
      POSTGRES_USER: ${DB_USER}
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

Dica de Ouro: O healthcheck é a diferença entre um sistema que sobe e um que dá erro de conexão porque a API tentou falar com o banco antes dele estar "vivo".

A Realidade Crua: O que a faculdade não te conta

Depois de colocar sistemas reais no ar (e passar algumas noites em claro), aqui estão os "Logs de Execução" que você precisa anotar:

Segurança não é opcional: Jamais, em hipótese alguma, suba o arquivo .env para o Git. Crie um .env.example com as chaves vazias. Em 2026, robôs varrem o GitHub em segundos atrás de credenciais de banco.

Logs são seus olhos: System.out.println é amadorismo. Use Logback ou SLF4J. Em produção, você não tem interface, você tem texto. Se o log for ruim, você está cego às 2h da manhã.

Persistência vs. Backup: Rodar banco em Docker é prático para dev. Em produção? Prefira serviços gerenciados (como Cloud SQL no GCP) ou tenha um script de backup automático fora do container. Volume não é backup.

VPS ou Cloud? Onde fazer o deploy

Para quem está começando agora e quer ver o sistema rodando:

PaaS (Railway/Render): Aperta um botão, conecta o GitHub e pronto. Muito bom para ter a sensação "UAU, FIZ UM DEPLOY!"

VPS (Hetzner/DigitalOcean): Controle total. Você instala o Docker e o Compose, faz o git pull e sobe tudo manualmente. É mais barato, mas a responsabilidade do firewall e segurança é sua.

Conclusão: Feito é melhor que perfeito

Meu primeiro trabalho real não tinha Docker. Não tinha Compose. Não tinha nada disso.

Era uma landing page para um negócio local — HTML, CSS, JavaScript puro. Sem framework, sem biblioteca, sem abstração. O "backend" era um Google Apps Script que capturava o formulário de contato e mandava um e-mail para o dono do negócio. Tinha Google Maps embedado para o cliente aparecer nas buscas locais. SEO configurado na mão, tag por tag.

Parecia simples demais para chamar de sistema. Mas estava no ar. O dono do negócio recebia os contatos dos clientes no e-mail. Era real.

Aprendi mais naquele projeto do que em meses de aula — porque o erro era meu, o cliente era real, e o prazo não esperava.

Docker Compose veio depois, quando os projetos cresceram e "funciona na minha máquina" virou um custo que eu não podia mais pagar. Ele foi o que me deu a segurança para entregar ambientes consistentes sem depender da sorte.

Se você está começando, não espere ter a stack perfeita. Entregue o que você sabe fazer hoje — com Google Apps Script, com VPS barata, com o que tiver. O perfeccionismo é o deploy que nunca sai.

Se você está no início, relaxa... depois só piora.