Como Estruturei uma Arquitetura Web Resiliente com Django 6, Docker e Cloudflare em VPS

# Como Estruturei uma Arquitetura Web Resiliente com Django 6, Docker e Cloudflare em VPS

Publicar uma aplicação web em produção envolve muito mais do que simplesmente executar um comando `manage.py runserver`. Quando o objetivo é entregar alta performance, segurança rigorosa contra ameaças e disponibilidade contínua em uma **VPS de baixo custo**, a arquitetura precisa ser planejada do sistema operacional até a camada de CDN.

Neste artigo, compartilho os detalhes técnicos de como estruturei o ambiente de produção do **`makisjeanty.com`** combinando **Django 6**, **Daphne ASGI**, **Docker Compose**, **MySQL 8.0**, **Redis** e **Cloudflare Full Proxy**.

---

## 🛡️ 1. Segurança & Execução Não-Root em Containers

O primeiro princípio adotado foi o da **menor permissão**. No `Dockerfile`, a aplicação não roda com privilégios de `root`. Um usuário de sistema dedicado (`appuser:appgroup`) foi provisionado para isolar o processo:

```dockerfile
# Criar usuário não privilegiado para execução do container
RUN addgroup --system appgroup && adduser --system --ingroup appgroup appuser

WORKDIR /app
COPY --chown=appuser:appgroup . /app/
USER appuser
```

Isso garante que, mesmo na hipótese remota de uma vulnerabilidade no nível de aplicação, o atacante não terá acesso root ao container ou ao host.

---

## 🔒 2. SSL/TLS com Cloudflare & Proxy Reverso Nginx

Para garantir criptografia ponta a ponta e proteção contra ataques DDoS, o servidor web **Nginx** atua como proxy reverso escutando nas portas `80` (HTTP) e `443` (HTTPS):

1. **Redirecionamento Canônico**: O tráfego para `www.makisjeanty.com` é redirecionado via regra 301 para a raiz `https://makisjeanty.com`.
2. **Strict-Transport-Security (HSTS)**: Forçado para subdomínios com pré-carregamento.
3. **Modo Full Proxy**: A Cloudflare atua como escudo frontal na borda (Edge Network), terminando a conexão SSL pública e trafegando criptografado até o Nginx de origem.

---

## ⚡ 3. Concorrência e WebSockets com Daphne ASGI e Redis

Em vez de utilizar o WSGI tradicional, optamos pelo servidor de aplicação **Daphne (ASGI)**. Isso permite que a mesma infraestrutura sirva requisições HTTP síncronas e conexões **WebSocket bidirecionais** (utilizadas pelo Chat ao Vivo e Fórum da Comunidade).

O **Redis** é utilizado simultaneamente como:
- **Backend de Cache de Sessões**: Reduzindo consultas repetitivas ao banco MySQL.
- **Layer de Canais (Django Channels)**: Roteando mensagens de WebSocket entre clientes com latência inferior a 10ms.

---

## 📊 4. Verificação de Saúde (Health Checks Automatizados)

A aplicação conta com um endpoint seguro de monitoria em `/health/` que valida a conectividade com o banco de dados e o Redis antes de responder `HTTP 200 OK`:

```python
def health_check(request):
db_ok = connection.ensure_connection() is None
cache.set('_health_check', '1', 5)
redis_ok = (cache.get('_health_check') == '1')

status_code = 200 if (db_ok and redis_ok) else 503
return JsonResponse({
'status': 'ok' if status_code == 200 else 'degraded',
'database': 'ok' if db_ok else 'error',
'redis': 'ok' if redis_ok else 'error',
}, status=status_code)
```

---

## 🎯 Conclusão

Construir uma infraestrutura moderna não exige investimentos estratosféricos em nuvens proprietárias. Com **containers bem configurados**, **práticas de menor privilégio** e uma **camada de CDN bem ajustada**, é possível alcançar um nível de maturidade e performance enterprise mantendo custos operacionais extremamente baixos.