0

同一のデータベース インスタンスが多数ある

  • ローカルホスト
  • staging.server.com
  • www.server.com

Django の設定で、最小限の労力でこれらのいずれかを選択できるようにしたいと考えています。複数の設定ファイルを保持したくない。

このように設定できることは知っていますが、デフォルト以外の人に切り替える方法はあります。

DATABASES = {
  'default': {
    'ENGINE': 'django.db.backends.sqlite3',
    'HOST': 'localhost'
  },
  'staging': {
    'ENGINE': 'django.db.backends.sqlite3',
    'HOST': 'staging.server.com'
  },
  'production': {
    'ENGINE': 'django.db.backends.sqlite3',
    'HOST': 'www.server.com'
  }
}
4

3 に答える 3

2

[アップデート]

構成/コードの分離のために、私は自分のものをロールバックする代わりにdjango-decoupleというプロジェクトを使用していますが、元の回答の理論的根拠は引き続き有効です。

[元の回答]

if/elif チェーンや include の代わりに環境変数を使用することをお勧めします。主な理由は次のとおりです。

  • config はデプロイごとに大きく異なりますが、コードはそうではありません。したがって、config をコードから厳密に分離することを目指す必要があります。
  • 環境固有の情報は、環境に関連しています。環境変数は、コードを変更することなく、デプロイ間で簡単に変更できます。
  • パスワードなどの機密情報が誤ってソース管理にチェックインされるのを防ぎます。

例えば：

DATABASES = {
    'default': {
        'ENGINE': os.environ.get('DB_NAME', 'django.db.backends.sqlite3'),
        'NAME': os.environ.get('DB_NAME', 'some_default'),
        'USER': os.environ.get('DB_USER', ''),
        'PASSWORD': os.environ.get('DB_PASS', ''),
        'HOST': os.environ.get('DB_HOST', ''),
        'PORT': '',
    }
}

このプラクティスの背後にある原則についての詳細な説明については「12 要素アプリ」を、 Django 設定への実用的なアプローチについては「設定ファイルの書き込みをやめる」をお読みください。

また、virtualenv の使用をお勧めします。いくつかのヒント：

  • アプリを /opt/django-apps/project_name のようなパスに配置します
  • virtualenvwrapper をインストールし、次のようなパスの下にプロジェクトと同じ名前の virtualenv を作成します。/var/lib/python-virtualenvs
  • workon project_nameプロジェクトで働きたいときにaを発行する

私は次のwsgi.pyように使用します：

import os
import site
import sys

APP_ROOT = os.path.dirname(os.path.abspath(__file__))
ROOT = os.path.dirname(APP_ROOT)
PROJECT_NAME = os.path.basename(APP_ROOT)
INSTANCE_NAME = os.path.basename(ROOT)
VENV = '/var/lib/python-virtualenvs/{}/'.format(INSTANCE_NAME)
# Add the site-packages of the chosen virtualenv to work with
site.addsitedir(VENV + 'lib/python2.7/site-packages')

# Add the app's directory to the PYTHONPATH
sys.path.append(ROOT)

# Activate your virtual env
activate_env=os.path.expanduser(VENV + "bin/activate_this.py")
execfile(activate_env, dict(__file__=activate_env))

os.environ.setdefault("DJANGO_SETTINGS_MODULE", PROJECT_NAME + ".settings")

from django.core.wsgi import get_wsgi_application
_application = get_wsgi_application()

def application(environ, start_response):
    os.environ['DEBUG'] = environ['DEBUG']
    os.environ['DB_NAME'] = environ['DB_NAME']
    os.environ['DB_PASS'] = environ['DB_PASS']
    os.environ['DB_HOST'] = environ['DB_HOST']
    os.environ['DB_USER'] = environ['DB_USER']
    return _application(environ, start_response)
于 2013-09-11T05:00:52.857 に答える
0

それで、私はDjangoのTwo Scoopsという本を読んでいて、第5章全体がこの問題に基づいています。この章、Settings and Requirement Filesは、私のすべての質問に答えます。この章は、 Jacob Kaplan-MossによるOSCON 2011 での Django のベスト (およびワースト) トークに基づいています。スライドの 47 ページ以降を参照してください。

基本的には、複数の設定ファイル (settings/base.py、settings/local.py、settings/production.py など) を使用し、--settings スイッチを使用してサーバーを起動するときに適切なファイルを使用するという考え方です。

于 2013-10-29T05:16:59.197 に答える
0

方法を見つけましたが、これが適切な方法であるかどうかはわかりません。コメントしてください。

メインの settings.py とその中の DATABASES 設定は次のようになります...

DATABASES = {
  'default': {
    'ENGINE': 'django.db.backends.sqlite3',
    'HOST': 'www.server.com'
  }
}

そして、このファイルの最後に、次のコードがあります...

# Load the local overrides if there are any.
try:
    from settings_local import *
except ImportError, e:
    pass

次に、同じ場所に settings_local.py ファイルがありますが、次のようにローカル環境で Git によって無視されます...

DATABASES = {
  'default': {
    'ENGINE': 'django.db.backends.sqlite3',
    'HOST': 'localhost'
  }
}

これにより、アプリケーションは、settings.py と同じディレクトリに settings_local.py ファイルがない場合は運用データベース サーバーに接続でき、このファイルが存在する場合はローカル (またはステージング) データベースに接続できます。

于 2013-09-11T14:50:14.657 に答える