ti-enxame.com

Como você configura o Django para desenvolvimento e implementação simples?

Eu costumo usar SQLite ao fazer Django development, mas em um servidor live algo mais robusto é frequentemente necessário ( MySQL / PostgreSQL , por exemplo). Invariavelmente, existem outras mudanças a serem feitas nas configurações do Django: diferentes locais/intensidades de registro, caminhos de mídia, etc.

Como você gerencia todas essas mudanças para tornar a implantação um processo simples e automatizado?

109
reppimp

Update: Django-configurations foi lançado, o que provavelmente é uma opção melhor para a maioria das pessoas do que fazê-lo manualmente.

Se você preferir fazer as coisas manualmente, minha resposta anterior ainda se aplica:

Eu tenho vários arquivos de configurações.

  • settings_local.py - Configuração específica do host, como nome do banco de dados, caminhos de arquivo, etc.
  • settings_development.py - configuração usada para desenvolvimento, por ex. DEBUG = True.
  • settings_production.py - configuração usada para produção, por ex. SERVER_EMAIL.

Eu amarro tudo isso junto com um arquivo settings.py que primeiro importa settings_local.py e depois um dos outros dois. Decide qual carregar duas configurações dentro de settings_local.py - DEVELOPMENT_HOSTS e PRODUCTION_HOSTS. settings.py chama platform.node() para encontrar o nome do host da máquina em que está sendo executado e, em seguida, procura esse nome de host nas listas e carrega o segundo arquivo de configurações, dependendo de qual lista ele encontra o nome do host.

Dessa forma, a única coisa com a qual você realmente precisa se preocupar é manter o arquivo settings_local.py atualizado com a configuração específica do host, e tudo o mais é tratado automaticamente.

Confira um exemplo aqui .

84
Jim

Pessoalmente, eu uso um único settings.py para o projeto, eu só tenho que procurar o nome do host está em (minhas máquinas de desenvolvimento têm nomes de host que começam com "gabriel" então eu só tenho isso:

import socket
if socket.gethostname().startswith('gabriel'):
    LIVEHOST = False
else: 
    LIVEHOST = True

então em outras partes eu tenho coisas como:

if LIVEHOST:
    DEBUG = False
    PREPEND_WWW = True
    MEDIA_URL = 'http://static1.grsites.com/'
else:
    DEBUG = True
    PREPEND_WWW = False
    MEDIA_URL = 'http://localhost:8000/static/'

e assim por diante. Um pouco menos legível, mas funciona bem e economiza ao ter que manipular vários arquivos de configurações.

25
Gabriel Ross

No final do settings.py eu tenho o seguinte:

try:
    from settings_local import *
except ImportError:
    pass

Desta forma, se eu quiser substituir as configurações padrão, basta colocar settings_local.py ao lado de settings.py.

22
Dmitry Shevchenko

Eu tenho dois arquivos. settings_base.py, que contém configurações comuns/padrão, e que é verificado no controle de origem. Cada implantação tem um settings.py separado, que executa from settings_base import * no início e, em seguida, substitui conforme necessário.

11
John Millikin

A maneira mais simplista que encontrei foi:

1) use o padrão settings.py para desenvolvimento local e 2) Crie um production-settings.py começando com:

import os
from settings import *

Em seguida, basta substituir as configurações que diferem na produção:

DEBUG = False
TEMPLATE_DEBUG = DEBUG


DATABASES = {
    'default': {
           ....
    }
}
7
Andre Bossard

Algo relacionado, para a questão de implementar o próprio Django com múltiplos bancos de dados, você pode querer dar uma olhada em Djangostack . Você pode baixar um instalador completamente gratuito que permite instalar o Apache, Python, Django, etc. Como parte do processo de instalação, nós permitimos que você selecione qual banco de dados você deseja usar (MySQL, SQLite, PostgreSQL). Usamos os instaladores extensivamente ao automatizar as implantações internamente (elas podem ser executadas no modo autônomo).

2
Josue

Eu tenho meu arquivo settings.py em um diretório externo. Dessa forma, ele não é verificado no controle de origem ou sobrescrito por uma implantação. Eu coloquei isso no arquivo settings.py no meu projeto Django, junto com qualquer configuração padrão:

import sys
import os.path

def _load_settings(path):    
    print "Loading configuration from %s" % (path)
    if os.path.exists(path):
    settings = {}
    # execfile can't modify globals directly, so we will load them manually
    execfile(path, globals(), settings)
    for setting in settings:
        globals()[setting] = settings[setting]

_load_settings("/usr/local/conf/local_settings.py")

Nota: Isto é muito perigoso se você não pode confiar em local_settings.py.  

1
Chase Seibert

Bem, eu uso essa configuração:

No final do settings.py:

#settings.py
try:
    from locale_settings import *
except ImportError:
    pass

E em locale_settings.py:

#locale_settings.py
class Settings(object):

    def __init__(self):
        import settings
        self.settings = settings

    def __getattr__(self, name):
        return getattr(self.settings, name)

settings = Settings()

INSTALLED_APPS = settings.INSTALLED_APPS + (
    'gunicorn',)

# Delete duplicate settings maybe not needed, but I prefer to do it.
del settings
del Settings
1
sacabuche

Além dos vários arquivos de configurações mencionados por Jim, também tenho a tendência de colocar duas configurações no meu arquivo settings.py no topo BASE_DIR e BASE_URL definido para o caminho do código e o URL para a base do site, todas as outras configurações são modificados para se anexar a eles.

BASE_DIR = "/home/sean/myapp/" por exemplo MEDIA_ROOT = "%smedia/" % BASEDIR

Então, ao mover o projeto, eu só tenho que editar essas configurações e não pesquisar o arquivo inteiro.

Eu também recomendo olhar para fabric e Capistrano (ferramenta Ruby, mas pode ser usado para implementar aplicações Django) que facilitam a automação da implementação remota.

1
Sean O Donnell

Este é um post mais antigo, mas acho que se eu adicionar este library útil simplificará as coisas.

Use Django-configuration

Começo rápido

pip install Django-configurations

Em seguida, subclasse as configurações incluídas. Classe de configuração no settings.py de seu projeto ou qualquer outro módulo que você esteja usando para armazenar as constantes de configurações, por exemplo:

# mysite/settings.py

from configurations import Configuration

class Dev(Configuration):
    DEBUG = True

Defina a variável de ambiente Django_CONFIGURATION como o nome da classe que você acabou de criar, por exemplo, em ~/.bashrc:

export Django_CONFIGURATION=Dev

e a variável de ambiente Django_SETTINGS_MODULE para o caminho de importação do módulo como de costume, por ex. no bash:

export Django_SETTINGS_MODULE=mysite.settings

Alternativamente forneça a opção --configuration ao usar os comandos de gerenciamento do Django ao longo das linhas da opção de linha de comando --settings padrão do Django, por exemplo:

python manage.py runserver --settings=mysite.settings --configuration=Dev

Para permitir que o Django use sua configuração, você agora tem que modificar o seu script manage.py ou wsgi.py para usar as versões do Django-settings das funções iniciais apropriadas, por exemplo. um típico manage.py usando Django-configurações ficaria assim:

#!/usr/bin/env python

import os
import sys

if __== "__main__":
    os.environ.setdefault('Django_SETTINGS_MODULE', 'mysite.settings')
    os.environ.setdefault('Django_CONFIGURATION', 'Dev')

    from configurations.management import execute_from_command_line

    execute_from_command_line(sys.argv)

Observe na linha 10 que não usamos a ferramenta comum Django.core.management.execute_from_command_line mas sim configurations.management.execute_from_command_line.

O mesmo se aplica ao seu arquivo wsgi.py , por exemplo:

import os

os.environ.setdefault('Django_SETTINGS_MODULE', 'mysite.settings')
os.environ.setdefault('Django_CONFIGURATION', 'Dev')

from configurations.wsgi import get_wsgi_application

application = get_wsgi_application()

Aqui não usamos a função Django.core.wsgi.get_wsgi_application padrão, mas sim configurations.wsgi.get_wsgi_application.

É isso aí! Agora você pode usar seu projeto com manage.py e seu servidor WSGI ativado.

0
Little Phild

Eu acho que depende do tamanho do site se você precisa usar o SQLite, usei o SQLite com sucesso em vários sites ao vivo menores e ele roda muito bem.

0
Ycros

Eu uso o ambiente:

if os.environ.get('WEB_MODE', None) == 'production' :
   from settings_production import *
else :
   from settings_dev import *

Eu acredito que esta é uma abordagem muito melhor, porque eventualmente você precisa de configurações especiais para o seu ambiente de teste, e você pode facilmente adicioná-lo a essa condição.

0
slashmili

Tantas respostas complicadas!

Todo arquivo settings.py vem com:

BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

Eu uso esse diretório para definir a variável DEBUG assim (substitua pelo diretório onde seu código de desenvolvimento é):

DEBUG=False
if(BASE_DIR=="/path/to/my/dev/dir"):
    DEBUG = True

Então, toda vez que o arquivo settings.py for movido, o DEBUG será False e seu ambiente de produção.

Toda vez que você precisar de configurações diferentes daquelas em seu ambiente de desenvolvimento, use:

if(DEBUG):
    #Debug setting
else:
    #Release setting
0
JM Desrosiers