Django 開発を行うときに SQLite を使用する傾向がありますが、ライブサーバーではより堅牢なものが必要になることがよくあります( MySQL / PostgreSQL 、たとえば)。常に、Django設定にも同様の変更を加える必要があります。異なるロギングの場所/強度、メディアパスなど。
展開を簡単な自動化プロセスにするために、これらすべての変更をどのように管理しますか?
Update:Django-configurations がリリースされました。これはおそらくほとんどの人にとって、手動で行うよりも良いオプションです。
手動で物事を行うことを好む場合、私の以前の答えはまだ適用されます
複数の設定ファイルがあります。
settings_local.py
_-データベース名、ファイルパスなどのホスト固有の構成.settings_development.py
_-開発に使用される構成。 _DEBUG = True
_。settings_production.py
_-実稼働に使用される構成。 _SERVER_EMAIL
_。最初に_settings.py
_をインポートし、次に他の2つのうちの1つをインポートする_settings_local.py
_ファイルでこれらすべてを結び付けます。 _settings_local.py
_-_DEVELOPMENT_HOSTS
_および_PRODUCTION_HOSTS
_内の2つの設定により、どちらをロードするかを決定します。 _settings.py
_はplatform.node()
を呼び出して、実行中のマシンのホスト名を検索し、リストでそのホスト名を検索し、ホスト名が見つかったリストに応じて2番目の設定ファイルを読み込みます。
そうすれば、本当に心配する必要があるのは、_settings_local.py
_ファイルをホスト固有の構成で最新の状態に保つことだけで、それ以外はすべて自動的に処理されます。
例を確認してください here 。
個人的には、プロジェクトに単一の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_local.pyをsettings.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 をご覧ください。完全に無料のインストーラーをダウンロードできます。インストールプロセスの一部として、使用するデータベース(MySQL、SQLite、PostgreSQL)を選択できます。内部で展開を自動化する場合、インストーラーを広範囲に使用します(これらは、無人モード)。
Settings.pyファイルは外部ディレクトリにあります。そうすれば、ソース管理にチェックインされたり、デプロイによって上書きされたりすることはありません。これをmy 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の最後:
#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
Jimが言及した複数の設定ファイルに加えて、上部のsettings.pyファイルに2つの設定を配置する傾向がありますBASE_DIR
およびBASE_URL
コードのパスとサイトのベースへのURLを設定します。他のすべての設定は、これらに追加するように変更されます。
BASE_DIR = "/home/sean/myapp/"
例: MEDIA_ROOT = "%smedia/" % BASEDIR
そのため、プロジェクトを移動するときは、これらの設定を編集するだけで、ファイル全体を検索する必要はありません。
また、ファブリックと Capistrano (Rubyツールですが、リモート展開の自動化を促進するDjangoアプリケーション)の展開に使用できます。
これは古い記事ですが、この便利なlibrary
を追加すると、物事が簡単になると思います。
Django-configuration を使用します
pip install Django-configurations
次に、プロジェクトのsettings.pyまたは設定定数を保存するために使用している他のモジュールに含まれているconfiguration.Configurationクラスをサブクラス化します。
# mysite/settings.py
from configurations import Configuration
class Dev(Configuration):
DEBUG = True
Django_CONFIGURATION
環境変数を、作成したばかりのクラスの名前に設定します。 ~/.bashrc
:
export Django_CONFIGURATION=Dev
およびDjango_SETTINGS_MODULE
環境変数を通常どおりモジュールインポートパスに追加します。バッシュ:
export Django_SETTINGS_MODULE=mysite.settings
代わりにDjango Djangoのデフォルトの--configuration
コマンドラインオプションの行に沿って管理コマンドを使用する場合、--settings
オプションを提供します。例えば:
python manage.py runserver --settings=mysite.settings --configuration=Dev
Djangoを使用して設定を使用するには、manage.pyまたはwsgi.pyスクリプト。適切なスターター関数のDjango-configurationsバージョンを使用します。たとえば、典型的なmanage.pyDjango構成を使用すると、次のようになります。
#!/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)
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対応サーバーで使用できるようになりました。
SQLiteを使用することからステップアップする必要があるかどうかはサイトのサイズに依存すると思います。いくつかの小規模なライブサイトでSQLiteを使用することに成功しました。
私は環境を使用します:
if os.environ.get('WEB_MODE', None) == 'production' :
from settings_production import *
else :
from settings_dev import *
最終的にはテスト環境に特別な設定が必要になり、この条件に簡単に追加できるため、これははるかに優れたアプローチだと思います。
たくさんの複雑な答え!
すべての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