配置文件

这里所谓的配置文件主要指settings文件和requirements文件。

Django 1.5有超过130项可以通过 settings 文件进行配置的选项。由于是在服务器启动的时候加载配置,所以大多数针对settings的修改需要在服务器重启后才能生效。一些相关的最佳实践是:

  • 所有的配置文件都应该版本控制 :特别是在production环境下使用的配置文件更是如此。
  • DRYDon't repeat yourself ,也就是尽量把公共的配置项放到一个基础的配置文件里面,而不要在不同环境的配置文件里面拷来拷去。

避免使用不在代码库里面的本地配置

本地的开发环境不可避免的有些跟生产环境不同的配置,比如数据库连接,SECRET_KEY等等。

Warning:保护好你的秘密

在Django里面,`SECRET_KEY` 被用来进行加密签名,因此最好是不要放在代码库里面。使用一个对别人来说已知的 `SECRET_KEY` ,会使得很多Django提供的安全机制失效,造成严重的安全隐患。更多的详情,可以参考:官方文档


基于同样的理由,诸如数据库密码、AWS key、OAuth的token等信息,最好都不要放在代码仓库里面。

保存本地配置过去通行的做法就是创建一个 local_settings.py 文件。这个文件是针对具体机器创建的(可以是开发机也可以是产品机),并且故意没有放到代码库里面。这样做可能带来的问题有:

  • 每个机器都有一些没有被版本控制的代码
  • 因为有没有加入版本控制的代码,就意味着部署有手工流程,经常会发生配置文件拷错的情况
  • 同时,没有版本控制意味着每个开发人员都要手动同步这堆配置文件

更先进的做法是,为不同的环境编写不同的配置文件,同时仍然能保障具体环境的秘密仍然是秘密。

使用多个配置文件

ProTips™ 灵感来源于"The One True Way"

这种配置方式由Jacob Kaplan-Moss提出,并在OSCON 2011上以'The Best and Worst of Django'为题目的演讲中被提到。

和Django标准教程中使用单个settings.py不同,这种配置方式是创建一个settings/文件夹,然后在这个文件夹下面放置下面的这些配置文件:

settings/
    __init__.py
    base.py
    local.py
    staging.py
    test.py
    production.py
Warning:Requirements + Settings

每个settings文件对应一个环境,所以一般也有对应的requirements文件。

Settings 文件 用途

base.py

通用的配置

local.py

本地开发使用的配置。一般来说这种配置下 `DEBUG` 模式是打开的,又更多的日志,`django-debug-toolbar` 这类辅助app也是启用的

staging.py

Staging环境用来在部署生产环境之前给QA或者PO甚至是用户进行体验。同时有些团队也把Staging用来进行产品环境上出现的bug的调试

test.py

所有和测试有关的配置,比如test runner,内存数据库定义,log配置等

production.py

顾名思义用来放置生产环境的配置文件,有些时候被命名成prod.py