Executando verificação de segurança...
10
LucasEd
2 min de leitura ·

[ 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 !!

Carregando publicação patrocinada...
2
1
gustavocavalcanti

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.

1
1
dedraks

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.

1
freitasanderson

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.

1
dedraks

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.

1
freitasanderson

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.

1
anthonyleier

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.

1
gustavocavalcanti

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.

1
freitasanderson

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.

0
1
devintheshell

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.

1
LucasEd
Autor
Autor

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 !!

1
theviolatorx

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.

1
dedraks

É 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.

1
1