Como você implanta uma aplicação Django em produção?

Question

IT Interview Practice · Accepted Answer

Implantar Django em produção envolve executá-lo atrás de um **servidor WSGI/ASGI** apropriado e um **servidor web**, servindo arquivos estáticos corretamente, protegendo configurações e gerenciando o banco de dados — bem diferente do servidor de desenvolvimento integrado (que **não** é para produção).

## A pilha de produção

```text
Client → NGINX (web server) → GUNICORN (WSGI app server) → DJANGO
           │                      (runs your Python app, multiple workers)
           └─ serves static/media files directly (efficient)

❌ NEVER use `python manage.py runserver` in production — it's single-threaded,
   insecure, and not built for load. Use Gunicorn (WSGI) or Uvicorn (ASGI for async).
```

O servidor dev é inadequado para produção. A pilha padrão: um **servidor de aplicação** (Gunicorn/uWSGI para WSGI, Uvicorn para ASGI/async) executa Django com múltiplos workers, atrás de um **servidor web** (nginx) que trata conexões de entrada, TLS e arquivos estáticos.

## Configurações de produção (críticas para segurança)

```python
DEBUG = False                            # ❗ MUST be False — DEBUG=True leaks sensitive info
ALLOWED_HOSTS = ["example.com"]          # required when DEBUG=False
SECRET_KEY = os.environ["SECRET_KEY"]    # from the environment, NOT committed
SECURE_SSL_REDIRECT = True               # force HTTPS
SESSION_COOKIE_SECURE = True
SECURE_HSTS_SECONDS = 31536000
```

## Arquivos estáticos

```bash
python manage.py collectstatic           # gather static files into STATIC_ROOT
# then serve them via nginx or a CDN — or use WhiteNoise to serve them from the app
# (Django does NOT serve static files itself in production)
```

## Banco de dados e migrações

```bash
python manage.py migrate                  # apply migrations to the production DB
# use a real database (PostgreSQL), connection pooling, regular backups
```

## Uma lista de verificação de implantação típica

```text
1. Set production environment variables (SECRET_KEY, DB credentials, DEBUG=False)
2. Run migrations (manage.py migrate)
3. Collect static files (collectstatic) → serve via nginx/CDN/WhiteNoise
4. Run the app with Gunicorn/Uvicorn (multiple workers, behind nginx)
5. Enable HTTPS (TLS certificates, e.g. Let's Encrypt)
6. Set up logging, error monitoring (Sentry), health checks
7. Add a process manager (systemd/supervisor) or use containers (Docker) + orchestration
8. Run `manage.py check --deploy` to audit security settings
```

## Abordagens de implantação modernas

```text
✓ Containers (Docker) + orchestration (Kubernetes) or platforms (Heroku, Railway, Render)
✓ Managed databases, separate static/media storage (S3 + CDN)
✓ Background workers (Celery) + a broker (Redis) as separate services
✓ Horizontal scaling: multiple app instances behind a load balancer (keep app STATELESS)
```

## Por que isso importa

Implantar Django em produção corretamente é conhecimento essencial para levar aplicações do desenvolvimento para o uso no mundo real, e envolve considerações importantes que diferem fundamentalmente do desenvolvimento local — fazer incorretamente leva a vulnerabilidades de segurança, fraco desempenho ou aplicações quebradas.

Compreender a **pilha de produção** é fundamental: o servidor de desenvolvimento integrado (`runserver`) é explicitamente não para produção (é single-threaded, inseguro e não consegue lidar com carga), então você deve executar Django atrás de um **servidor de aplicação** apropriado (Gunicorn/uWSGI para WSGI, ou Uvicorn para ASGI/async) com múltiplos workers, fronteado por um **servidor web** (nginx) tratando conexões, TLS e serviço de arquivos estáticos.

Vários aspectos são críticos para segurança e correção: **configurações de produção** (especialmente `DEBUG=False`, que é obrigatório já que `DEBUG=True` vaza tracebacks sensíveis e configuração para atacantes, além de `ALLOWED_HOSTS`, uma `SECRET_KEY` secreta do ambiente e aplicação de HTTPS), **tratamento de arquivos estáticos** (executar `collectstatic` e servir arquivos via nginx/CDN/WhiteNoise, já que Django não os serve em produção — uma falha comum de implantação), e **gerenciamento de banco de dados** (um banco de dados real como PostgreSQL, aplicar migrações, backups).

Conhecer a lista de verificação de implantação, abordagens modernas (Docker/containers, plataformas gerenciadas, armazenamento em nuvem para mídia, workers Celery como serviços separados, scaling horizontal com app stateless) e as preocupações operacionais (logging, monitoramento com Sentry, health checks, gerenciamento de processos) é o que separa uma implantação de produção funcionando de uma frágil ou insegura.

Porque toda aplicação Django real deve eventualmente ser implantada, e porque erros de implantação (deixar `DEBUG=True`, manipular incorretamente arquivos estáticos, expor secrets, usar o servidor dev) causam problemas reais de segurança e confiabilidade, entender como implantar Django adequadamente — a pilha, as configurações críticas para segurança, tratamento de arquivos estáticos/mídia e práticas de implantação moderna — é conhecimento importante e de alto risco que reflete a capacidade de entregar aplicações prontas para produção, um tópico frequentemente relevante e profissionalmente essencial para qualquer desenvolvedor Django responsável por sistemas em produção.

A pilha de produção

Configurações de produção (críticas para segurança)

Arquivos estáticos

Banco de dados e migrações

Uma lista de verificação de implantação típica

Abordagens de implantação modernas

Por que isso importa

Perguntas relacionadas