Cloud, Docker & DevOps — implementações rápidas e fiáveis
Colocamos todas as aplicações em contentores com Docker, orquestramo-las com Docker Compose (ou Kubernetes em projetos empresariais), configuramos o Caddy como proxy inverso com SSL automático e automatizamos todo o ciclo de implementação através do GitHub Actions — do commit à produção numa única pipeline automatizada.
Contentorização com Docker e Docker Compose
Cada serviço tem o seu próprio Dockerfile multi-stage: uma etapa de compilação que instala as dependências e compila, e uma etapa final mínima (distroless ou alpine) que contém apenas os artefactos necessários. Uma imagem Next.js típica fica abaixo dos 150 MB; uma de FastAPI, abaixo dos 80 MB. As imagens são reconstruídas a cada merge no main e etiquetadas de forma semântica (`v1.2.3` + `latest`).
O Docker Compose define toda a stack: frontend, API, base de dados, Redis e worker. As variáveis sensíveis (palavra-passe da base de dados, chaves de API, segredo do Stripe) ficam num `.env` excluído do git — nunca fixadas dentro da imagem. Os health checks do Compose garantem que as dependências estão prontas antes do arranque (base de dados pronta → arranca a API → arranca o frontend).
- Cache de compilação com `--mount=type=cache` — as dependências não são descarregadas de novo em cada build
- Ordem de camadas otimizada: primeiro as dependências estáveis, depois o código-fonte
- Gestão de segredos com Docker secrets ou HashiCorp Vault em projetos empresariais
- `restart: unless-stopped` + `docker compose up --no-deps` para uma implementação atómica
Caddy — proxy inverso moderno com SSL automático
O Caddy 2.8 gere o SSL/TLS automaticamente através de ACME (Let's Encrypt ou ZeroSSL) — os certificados são pedidos e renovados sem configuração manual. HTTP/2 e HTTP/3 (QUIC) ativados por predefinição. Os cabeçalhos de segurança (HSTS, X-Frame-Options, CSP) são definidos globalmente através de fragmentos reutilizáveis. A configuração declarativa do Caddyfile pode ser comparada com diff e fica versionada no git.
A limitação de pedidos, a compressão gzip/brotli e o registo estruturado em JSON são ativados por diretivas nativas do Caddy — sem módulos de nginx nem configurações complexas de Apache. O acesso a rotas sensíveis (`/admin`, `.env`, `.git`) devolve 444 (sem resposta), configurado como fragmento global de segurança.
- Configuração TLS moderna desde o primeiro dia — apenas TLS 1.3 com cifras modernas
- TLS a pedido para SaaS multi-inquilino com subdomínios dinâmicos
- Recarregamento: o `caddy reload` não corta as ligações ativas
- Registos do Caddy → Loki → Grafana — análise de tráfego e alertas em caso de anomalia
CI/CD com GitHub Actions e monitorização
O pipeline de CI corre em cada PR: lint, verificação de tipos, testes unitários, construção da imagem Docker e análise de vulnerabilidades (Trivy). Se tudo passar, a imagem é enviada para o registry e a implementação em staging é feita automaticamente. Merge no main = implementação automática em produção com health check posterior. Reversão automática se o health check falhar em 60 segundos.
Monitorização com Grafana + Prometheus para as métricas da aplicação (latência, taxa de erros, tamanho da fila) e Loki para a agregação de registos. Alertas configurados no Slack/e-mail: taxa de erros superior a 1%, latência P95 acima de 500 ms, disco acima de 85%. A monitorização externa de disponibilidade fica a cargo do Better Uptime — painel público de SLA disponível a pedido.
- Análise de vulnerabilidades com Trivy nas imagens — bloqueio em caso de CVE crítico
- Dependabot + merge automático para atualizações de patch (exige CI verde)
- Backup automático da base de dados para armazenamento compatível com S3 (noturno, retenção de 30 dias)
Vantagens e limitações
Vantagens
- Implementação com reversão automática se o health check falhar.
- SSL/TLS automático através do Caddy — os certificados são renovados sem passo manual.
- Ambiente reproduzível: a mesma imagem Docker em desenvolvimento, staging e produção.
- Monitorização e alertas (Grafana, Loki) — os problemas são vistos antes dos utilizadores.
Limitações
- O Docker Compose não escala como o Kubernetes em ambientes empresariais com vários nós.
- A configuração inicial de CI/CD exige tempo e experiência em DevOps.
- As imagens e os registos consomem espaço em disco — é preciso limpá-los periodicamente.
- Uma monitorização completa (Prometheus + Grafana) acrescenta serviços para manter.
Veredicto breve
Docker + Caddy + GitHub Actions é a combinação ideal para implementar de forma fiável num VPS ou em alguns nós. Para dezenas de nós com escalamento automático agressivo, passa para Kubernetes.
Tabela de especificações
| Capacidade | Limite / limiar | Utilização típica | |
|---|---|---|---|
| Orquestração | Docker Compose, stack completa | Um só nó; vários nós exigem Swarm/K8s | VPS, projetos pequenos e médios |
| Proxy inverso | Caddy 2.8, HTTP/3, SSL automático | Regras muito complexas exigem configuração extensa | Multidomínio, multi-inquilino |
| CI/CD | GitHub Actions, implementação automatizada | Os minutos de CI são faturados acima do plano gratuito | Do commit à produção de forma automática |
| Custo típico | VPS a partir de ~5 €/mês | A monitorização e os backups acrescentam custo | De um único site a várias marcas |
Docker Compose vs Kubernetes
| Critério | Docker Compose | Kubernetes |
|---|---|---|
| Complexidade da configuração | Baixa | Alta |
| Escalamento multinó / escalamento automático | Limitado (um nó) | Excelente |
| Adequado para | VPS, projetos pequenos e médios | Grandes frotas, ambientes empresariais |
Perguntas frequentes
Porquê o Caddy e não o Nginx?
O Caddy gere o SSL/TLS automaticamente através de ACME, ativa HTTP/2 e HTTP/3 por predefinição e tem uma configuração declarativa curta. O Nginx exige certbot e bastante mais configuração manual para o mesmo resultado.
Preciso de Kubernetes?
Para a maioria dos sites, não. O Docker Compose num VPS gere com fiabilidade um site ou alguns serviços. O Kubernetes só se torna útil a partir de dezenas de nós com escalamento automático agressivo.
Como funciona a implementação?
O GitHub Actions constrói uma imagem nova, arranca-a a par da antiga, executa um health check e depois comuta o tráfego. Se o health check falhar em 60 segundos, é feita a reversão automática para a versão anterior.
Que monitorização recomendam?
Grafana + Prometheus para as métricas (latência, taxa de erros) e Loki para os registos agregados, com alertas no Slack/e-mail. Para a disponibilidade externa acrescentamos um serviço independente como o Better Uptime.