在Django 1.6中的settings.py中可以修改130多项设置, 但大多数都继承自默认值. 设置是在web服务器启动时首次载入的, 服务器重启时重新载入, 因此, 程序员们应尽量避免修改正式服务器上使用的settings.py文件. 以下是一些我们应当遵循的原则:

• 所有的设置文件应当进行版本管理
• 不要重复自己 (don‘t repeat yourself)
• 妥善保存关键信息

之前, 我们采用的方法是, 不将设置文件放入git库中, 每个开发人员本地有一份自己的设置文件. 但我们发现这样做是错误的. 因为:

• 在debug之前, 我们可能已经花费了大量精力去模拟正式服务器上出现的错误, 但最终发现这是由于正式服务器的settings文件设置和本地不同而 出现的问题. 这时你的心情会是怎样?
• 当你在开发django项目时, 发现并修复了一个bug. 当将这一commit push到服务器后, 你突然发现这一bug的出现完全是因为你修改了本地的 settings文件而产生的, 而由于你的push, 又导致了服务器的宕机. 这时你又会是怎样的感受?
• 每个人都会从另一个程序员那里拷贝/黏贴settings文件内容, 这难道不是违反了"不要重复自己"的原则吗?

正式由于这些问题, 所以我们现在采用不一样的设置方式. 我们首先建立一个基本的设置文件, 然后将开发和正式部署的设置文件分离成不同的模块, 但 这些模块都继承自同一个基本设置文件:

1. 使用分离式的设置文件

django项目建立时, 会自动生成settings.py文件. 为了实现分离式的设置文件, 我们首先删除settings.py, 然后建立settings目录:

    settings/        __init__.py        base.py        local.py        test.py        production.py        ...

我们可以使用以下命令使用这些不同的设置文件:

    python manage.py shell --settings=mysite.settings.local    python manage.py runserver --settings=mysite.settings.local

当然如果你熟悉 DJANGO_SETTINGS_MODULE 和 PYTHONPATH 的话, 也可以事先设置好 DJANGO_SETTINGS_MODULE 和 PYTHONPATH 环境变量, 这样做的好处就是你不必使用--settings了.

如果你对virtualenv有深入的了解的话, 也可以在postactivate脚本中设置 DJANGO_SETTINGS_MODULE 和 PYTHONPATH.

local.py的例子

    # settings/local.py    from .base import *    DEBUG = True    TEMPLATE_DEBUG = DEBUG    EMAIL_BACKEND = ‘django.core.email.backends.console.EmailBackend‘    DATABASES = {        "defaults": {            "ENGINE": "django.db.backends.postgresql_psycopg2",            "NAME": "weiguda",            "USER": "",            "PASSWORD": "",            "HOST": "localhost",            "PORT": "",        }    }    INSTALLED_APPS += ("debug_toolbar",)

有时, 一个开发人员的配置文件可能与另一个不同, 这时, 我们可以在settings目录中新建local_name.py:

    # settings/local_name.py    from .local import *    # 设置不同的配置    CACHE_TIMEOUT = 30

2. 将关键信息和设置文件分离

将SECTET_KEY, AWS key文件, API key文件等关键信息放入设置文件中也是违反基本原则的. 因为:

• 配置环境不同时关键信息会改变, 程序却不会.
• 关键信息不是程序.
• 关键信息应当是隐蔽的, 如果储存在了版本管理系统中, 则任何有权访问该版本库的用户都能获知这些关键信息.
• 许多PAAS服务无法为每台服务器编辑设置文件, 即使可以, 这也是不正确的做法.

环境变量

为了避免以上的问题, 我们使用环境变量 (environment variables) 来储存这些关键信息, (需要注意的是, apache不支持环境变量, 我们会在下面讲到). 使用环境变量储存关键信息有以下好处:

• 将关键信息从代码中移除, 这样你就可以安心的将所有文件放入版本管理系统中.
• 每个开发人员都拥有一样的local.py文件.
• 在部署django项目时, 不需要修改程序代码.
• 大多数PAAS都推荐这一方法, 并提供了方便的设置方法, 因此容易实现.

设置环境变量

在使用bash的Mac或Linux中设置环境变量比较容易, 你只需要将以下代码加入.bashrc, .bash_profile, 或.profile其中之一即可. 如果多个项目 使用相同的API, 并且关键信息都不同时, 可以将以下代码加入到virtualenv的bin/activate脚本中:

    $ export SOME_SECRET_KEY=654-3jgwg-4r3-2t4h-76jk    $ export ANOTHER_SECRET_KEY=y5y-5jk8-75i5h-5g4/.-,o.

如果使用的是windows系统, 则设置稍微复杂一点. 如果使用cmd.exe, 你必须使用setx命令一个一个的设置, 一个较好的方式是使用virtualenv的 bin/activate.bat

    > setx OME_SECRET_KEY=654-3jgwg-4r3-2t4h-76jk

PowerShell是Windows Vista及以上自带的shell, 它比cmd.exe强大得多. 因此可以使用PowerShell来设置环境变量:

    # 为用户User设置    [Environment]::SetEnvironmentVariable("SOME_SECRET_KEY", "654-3jgwg-4r3-2t4h-76jk", "User")    # 为全局设置    [Environment]::SetEnvironmentVariable("SOME_SECRET_KEY", "654-3jgwg-4r3-2t4h-76jk", "Machine")

如果你使用virtuanenvwrapper, 那么可以使用virtualenvwrapper的pre-virtualenv设置环境变量, 这样可能会更方便.

如果你使用PAAS, 则请参阅不同的PAAS提供的设置方法.

获取环境变量

在设置好环境变量后, 我们来看如何在django的settings代码中获取这些关键信息:

    # 在settings/production.py顶部    import os    SOME_SECRET_KEY = os.environ["SOME_SECRET_KEY"]

在以上代码中, 如果SOME_SECRET_KEY无法被获取到的话, 就会出现KeyError错误, 导致django项目无法启动. 这很好, 但KeyError没有提供更有 用的信息, 导致debug的困难, 因此, 我们在base.py(希望你还记得这是哪个文件)加入以下function, 为我们提供哪个关键信息无法获取的信息:

    # settings/base.py    import os    # 通常你不应该从django引入任何代码, 但ImproperlyConfigured是个例外    from django.core.exceptions import ImproperlyConfigured    def get_env_variable(var_name):        try:            return os.environ[var_name]        except KeyError:            error_msg = "Set the %s environment variable" % var_name            raise ImproperlyConfigured(‘error_msg‘)

然后修改之前的production.py:

    # 在settings/production.py顶部    import os    SOME_SECRET_KEY = get_env_variable(‘SOME_SECRET_KEY‘)

此时, 当你没有设置SOME_SECRET_KEY环境变量时, 系统会提示错误信息, 告诉你是哪个环境变量没有设置.

无法使用环境变量时

当我们使用apache时, 我们会发现, django无法使用环境变量. 这时, 我们推荐将关键信息储存在JSON格式的文件中, 已达到将关键信息和代码分离的 目的. 首先我们可以创建secrets.json文件:

    {        "FILENAME": "secrets.json",        "SOME_SECRET_KEY": "654-3jgwg-4r3-2t4h-76jk"    }

在settings中使用该文件:

    # settings/base.py    import json    # 通常你不应该从django引入任何代码, 但ImproperlyConfigured是个例外    from django.core.exceptions import ImproperlyConfigured    # 读取json文件    with open("secrets.json") as f:        secrets = json.loads(f.read())    def get_secret(setting, secrets=secrets):        try:            return secrets[setting]        except KeyError:            error_msg = "Set the {0} environment variable".format(setting)            raise ImproperlyConfigured(‘error_msg‘)    SOME_SECRET_KEY = get_secret(‘SOME_SECRET_KEY‘)

3. 使用不同的部署文件(requirements.txt)

部署文件(requirements.txt)中储存的是该django项目的依赖库, 一般使用pip freeze --local生成. 本着"只安装需要的模块"的原则, 不同的设 置文件, 应当对应不同的requirements.txt文件. 就像分离式的settings文件一样, 我们使用分离式的requirements文件. 首先我们删除前文中提到的repository_root中的requirements.txt, 然后建立requirements目录:

    requirements/        base.txt        local.txt        production.txt

在base.txt中, 储存的是所有开发环境中都会用到的依赖库, 例如:

    Django==1.6.5    psycopg2==2.5.3    South==0.8.4

在local.txt中, 储存的是本地开发时用到的依赖库:

    # 导入base.txt中的依赖库    -r  base.txt    coverage==3.7.1    django-debug-toolbar==1.2

当重新配置本地开发环境时, 可以使用以下代码安装依赖库:

    pip install -r requirements/local.txt

4. 设置文件中的文件路径

我们强烈反对将绝对路径写入设置文件中, 因为如果将绝对路径写入设置文件中的话, 遇到不同的环境, 就需要重新修改, 给开发和部署带来了许多麻烦 和不确定性.

我们推荐使用Unipath来设置media, static和templates的 路径. 这样无论部署测试环境如何变化, media和templates文件夹的设置都不会有问题.

    # settings/base.py 顶部    from unipath import Path        BASE_DIR = Path(__file__).ancestor(3)    MEDIA_ROOT = BASE_DIR.child("media")    STAIC_ROOT = BASE_DIR.child("static")    TEMPLATES_DIRS = (        BASE_DIR.child("templates"),    )