単純な開発とデプロイのためにDjangoをどのように構成しますか？

私はDjango 開発を行うときにSQLiteを使用する傾向がありますが、ライブサーバーでは、より堅牢なものがしばしば必要になります（たとえば、MySQL / PostgreSQL）。常に、Djangoの設定にも他の変更があります。異なるログの場所/強度、メディアパスなどです。

これらのすべての変更をどのように管理して、展開を単純な自動化されたプロセスにするのですか？

更新： django-configurationsがリリースされました。これは、手動で行うよりも、おそらくほとんどの人にとってより良いオプションです。

手動で操作したい場合でも、私の以前の回答が適用されます。

複数の設定ファイルがあります。

• settings_local.py -データベース名、ファイルパスなどのホスト固有の設定
• settings_development.py-開発に使用される構成DEBUG = True。
• settings_production.py-生産に使用される構成SERVER_EMAIL。

これらすべてsettings.pyを最初にインポートするファイルで結び、settings_local.py次に他の2つのうちの1つをインポートします。これは、内部の2つの設定でロードすることを決定settings_local.py- DEVELOPMENT_HOSTSとPRODUCTION_HOSTS。 が実行されているマシンのホスト名を見つけるためにsettings.py呼び出しplatform.node()、次にリストからそのホスト名を探し、ホスト名が見つかったリストに応じて2番目の設定ファイルをロードします。

そうすれば、本当に心配する必要があるのはsettings_local.py、ホスト固有の構成でファイルを最新の状態に保つことだけで、それ以外はすべて自動的に処理されます。

こちらの例をご覧ください。

個人的には、プロジェクトに単一のsettings.pyを使用します。プロジェクトのホスト名を検索するだけです（開発マシンには「gabriel」で始まるホスト名があるので、次のようにします：

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

それから他の部分では私は次のようなものを持っています：

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/'

等々。少し読みにくくなりますが、うまく機能し、複数の設定ファイルを調整する必要がなくなります。

settings.pyの最後には、次のようになっています。

try:
    from settings_local import *
except ImportError:
    pass

この方法で、デフォルト設定を上書きしたい場合は、settings.pyのすぐ隣にsettings_local.pyを置く必要があります。

2つのファイルがあります。settings_base.pyこれには、共通/デフォルト設定が含まれ、ソース管理にチェックインされます。各デプロイメントには個別のsettings.pyがありfrom settings_base import *、最初に実行され、必要に応じてオーバーライドされます。

私が見つけた最も単純な方法は：

1）ローカル開発にデフォルトのsettings.pyを使用し、2）以下で始まるproduction-settings.pyを作成します：

import os
from settings import *

次に、本番環境で異なる設定をオーバーライドします。

DEBUG = False
TEMPLATE_DEBUG = DEBUG


DATABASES = {
    'default': {
           ....
    }
}

多少関連しますが、Django自体を複数のデータベースにデプロイする問題については、Djangostackを参照することをお勧めします。Apache、Python、Djangoなどをインストールできる完全無料のインストーラーをダウンロードできます。インストールプロセスの一環として、使用するデータベース（MySQL、SQLite、PostgreSQL）を選択できます。内部で展開を自動化する場合、インストーラーを広範囲に使用します（無人モードで実行できます）。

外部ディレクトリにsettings.pyファイルがあります。これにより、ソース管理にチェックインされたり、デプロイによって上書きされたりしません。これをDjangoプロジェクトのsettings.pyファイルに、デフォルトの設定と一緒に入れます。

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")

注：local_settings.pyを信頼できない場合、これは非常に危険です。

複数の設定ファイルは、ジムで言及したことに加えて、私はまた、上部にある私のsettings.pyファイルに場所に2つの設定を傾向があるBASE_DIRし、BASE_URL他のすべての設定が変更され、サイトのベースにコードやURLのパスに設定これらに自分自身を追加します。

BASE_DIR = "/home/sean/myapp/" 例えば MEDIA_ROOT = "%smedia/" % BASEDIR

したがって、プロジェクトを移動するときは、これらの設定を編集するだけで、ファイル全体を検索する必要はありません。

また、リモート展開の自動化を促進するファブリックとCapistrano（Rubyツールですが、Djangoアプリケーションの展開に使用できます）も検討することをお勧めします。

まあ、私はこの構成を使用します：

settings.pyの最後で：

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

そして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

非常に多くの複雑な答え！

すべてのsettings.pyファイルが付属しています：

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

私はそのディレクトリを使用して、次のようにDEBUG変数を設定します（開発コードがあるディレクトリに置き換えます）。

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

そうすると、settings.pyファイルが移動されるたびに、DEBUGがFalseになり、それが本番環境になります。

開発環境の設定とは異なる設定が必要になるたびに、以下を使用します。

if(DEBUG):
    #Debug setting
else:
    #Release setting

SQLiteを使用することからステップアップする必要があるかどうかは、サイトのサイズに依存すると思います。私はいくつかの小さなライブサイトでSQLiteを正常に使用しており、非常に優れています。

私が使用する環境：

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

最終的にはテスト環境に特別な設定が必要になり、この条件に簡単に追加できるため、これははるかに優れたアプローチであると思います。

これは古い投稿ですが、これを追加すると、library物事が簡単になると思います。

django-configurationを使用する

クイックスタート

pip install django-configurations

次に、プロジェクトのsettings.pyまたは設定定数を保存するために使用している他のモジュールに含まれているconfigurations.Configurationクラスをサブクラス化します。例：

# mysite/settings.py

from configurations import Configuration

class Dev(Configuration):
    DEBUG = True

DJANGO_CONFIGURATION環境変数を、先ほど作成したクラスの名前に設定します。例~/.bashrc：

export DJANGO_CONFIGURATION=Dev

そして、DJANGO_SETTINGS_MODULE通常のように、環境変数をモジュールのインポートパスに、たとえばbashで：

export DJANGO_SETTINGS_MODULE=mysite.settings

または--configuration、Djangoのデフォルトの--settingsコマンドラインオプションの行に沿ってDjango管理コマンドを使用するときに、オプションを指定します。例：

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

Djangoが設定を使用できるようにするには、適切なスターター関数のdjango-configurationsバージョンを使用するようにmanage.pyまたはwsgi.pyスクリプトを変更する必要があります。たとえば、django-configurationsを使用する一般的なmanage.pyは次のようになります。

#!/usr/bin/env python

import os
import sys

if __name__ == "__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)

10行目では、共通ツールを使用せずdjango.core.management.execute_from_command_line、代わりに使用していることに注意してくださいconfigurations.management.execute_from_command_line。

同じことがあなたのwsgi.pyファイルにも適用されます。例えば：

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()

ここでは、デフォルトのdjango.core.wsgi.get_wsgi_application関数を使用しませんが、代わりに使用しますconfigurations.wsgi.get_wsgi_application。

それでおしまい！これで、manage.pyとお気に入りのWSGI対応サーバーでプロジェクトを使用できます。

実際、おそらく開発環境と本番環境で同じ（またはほぼ同じ）構成にすることを検討する必要があります。そうしないと、「ちょっと、私のマシンで動作します」のような状況がときどき発生します。

したがって、デプロイメントを自動化してWOMMの問題を排除するには、Dockerを使用するだけです。