[ Tutorial ] Como preparar a aplicação Django para por em produção

O propósito deste, é compartilhar como configurar o ambiente de desenvolvimento para Produção.

Antes de enviar sua aplicação para produção, você precisa configurar o ambiente de desenvolvimento.

Configure as variávéis no core da aplicação em settings.py.

Altere:

// De
DEBUG = True

// Para
DEBUG = False

// De
ALLOWED_HOSTS = [ ]

// Para
ALLOWED_HOSTS = ["*"]
// Ou
ALLOWED_HOSTS = ["seudominio.com"]
  • Configure para servir os arquivos Staticos com WhiteNoise

Primeiro, com seu virtualenv ativado, precisamos instalar o WhiteNoise utilizando o pip.

pip install whitenoise

Rode o comando para gerar novamente o arquivo requirements.txt da aplicação:

pip freeze > requirements.txt

Logo após, devemos adicionar a seguinte linha no arquivo de settings.py:

MIDDLEWARE = [
  'django.middleware.security.SecurityMiddleware',
  'whitenoise.middleware.WhiteNoiseMiddleware',
  # Certifique-se que o WhiteNoise seja adicionado acima de todos os middlewares do Django, exceto o de security. 
  # ...
]

Por fim, para ativar arquivos de cache e com campactação, adicionamos a seguinte linha (eu gosto de adicionar abaixo de STATIC_URL e STATIC_ROOT para manter um padrão):

STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'

Por fim, rode o coolestatic novamente:

python manage.py collectstatic

Configurando o domínio de acesso

Em settings.py, coloque o domínio que podem dar acesso a aplicação por meio do crfs token:

                       //Coloque aqui seu domínio
CSRF_TRUSTED_ORIGINS = ['https://seu-domínio']

Sua aplicação está pronta para por em produção, epois de configurar o ambiente de desenvolvimento, você pode enviar sua aplicação para produção. Isso inclui criar um servidor da web e configurar o aplicativo para ser executado nele, leve em conta também de configurar as variáveis de ambiente no ambiente de produção a qual ficará hospedada a aplicação.

È só isso, obrigado !!

Também seria bom adicionar a configuração 'SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")' para lidar com terminação https no proxy.

Só algumas melhorias:

De ALLOWED_HOSTS = ["*"]

Para ALLOWED_HOSTS = ["seudominio.com"]

Por segurança também é bom ter um valor de SECRET_KEY diferente para os ambientes de desenvolvimento e produção, por isso eu mantenho 2 arquivos settings.py diferentes, um para cada ambiente.

Bem lembrado sobre o ALLOWED_HOSTS, e valeu pela dica do SECRET_KEY !!
Eu mantenho todas as variações de configurações em um arquivo .env. Já máquina de desenvolvimento tenho um .env de teste e no servidor um .env de produção. Dessa forma não preciso ficar gerenciando dois arquivos de configuração.
Tu poderia ter dois arquivos de configuração so pra salvar a secret key e as configurações do banco. E ao inves de ser um arquivo.env, tu pode separar o settings em outros arquivos.
Tenho dois arquivos .env separados, um pra desenvolvimento e outro pra produção. Mantenho assim porque sao muitas configurações que mudam de um ambiente pra outro, não apenas banco e chave secreta. Meu app principal faz autenticação no AD, então muda caminho de OU, usuário do ad, grupos de permissões, entre outros.
ah sim, entendi. De 12 projetos que tenho em produção, em 9 deles a gente tem dois arquivos .env também, neste contendo além das configurações do banco, também tem as configurações para enviar email. gosto de adotar o modelo modularizando o settings.py somente quando vou utilizar o Cron. Creio que o abrir arquivo pode dar uma bugada no cron mas nunca vi nada falando sobre isso em lugar nenhum.

Show de bola mano! Gostaria de complementar que é uma boa prática colocar as variáveis de ambiente em um arquivo .ENV e utilizar o python-dotenv para carregar essas variáveis no arquivo settings.py. Assim pode-se ter diferentes configurações para diferentes ambientes, e essas variáveis que são sensíveis, também não apareceriam no Github.

Uma opção é salvar variáveis sensíveis encriptadas em um arquivo .ini. Ler, depois desencriptar em execução com uma chave diferente para cada ambiente (não salvar a chave no código fonte, é claro). Outra opção mais robusta é usar Secret Management Tools ou ferramentas de gerenciamento de segredos, como exemplos HashiCorp Vault (mais famosa), Confidant, Knox, Sops e outras ferramentas open source que existem.
Django tem um pacote chamado django-environ que serve para a mesma coisa também. Porém recomendo nao utilizar isso se for tentar trabalhar com o cron, pois utilizando isso o cron nunca funcionou comido.
verdade mesmo, boa !

Muito boa iniciativa, sua publicação poderia se tornar um lugar para partilhar padrões e boas práticas usadas para preparar uma aplicação Django para produção. Seria interessante adicionar, com o tempo, como configurar a aplicação com Nginx, Docker, Docker Compose, Gunicorn, Postgresql, Redis, etc.

Então @devintheshell, ja fiz algumas outras publicações sobre o django, sobre diretivas, não vou pegar o link de todas, mas tem no meu blog, lá vc consegue ver todas, puxei as minhas publicações do tabnews lá: https://blog-tab-news.vercel.app/blog. Valeu pelas dicas, alguns do que vc citou aí eu já até fiz, e os que não fiz irei fazer, valeu !!

Sou apaixonado por Python e estou me dedicando ao Django e Pygame. Tenho uma vps pela hostinger e nao consigo subir meus testes em Django pq nao estou conseguindo configurar o Ngnix no ubuntu ou outra distribuição linux. Se alguem tiver algo ansugerir, fico agradecido.

Pela publicação excelente e dicas msravilhosas de todos.

É bem tranquilo. Também tenho um vps no webdock e uso justamente o nginx como proxy reverso da aplicação. Pra ser mais exato deixo a aplicação em um container docker e o nginx em outro container.
Da uma olhada nos meus posts sobre Django, acho que você vai curtir, eu tenho um app em django que subi na hostinger e eu ensino como faz la.

Legal. Nas minhas aplicações eu uso o nginx pra servir os arquivos estáticos. E deixo a aplicação atrás de um proxy reverso.