为本地开发和生产服务器处理设置的推荐方法是什么?其中一些(如常量等)可以在两者中更改/访问,但其中一些(如静态文件的路径)需要保持不同,因此不应该在每次部署新代码时都重写。
目前,我正在将所有常量添加到settings.py中。但是每次我在本地更改一些常量时,我都必须将其复制到生产服务器并编辑文件以进行特定于生产的更改……:(
编辑:看起来这个问题没有标准答案,我已经接受了最流行的方法。
为本地开发和生产服务器处理设置的推荐方法是什么?其中一些(如常量等)可以在两者中更改/访问,但其中一些(如静态文件的路径)需要保持不同,因此不应该在每次部署新代码时都重写。
目前,我正在将所有常量添加到settings.py中。但是每次我在本地更改一些常量时,我都必须将其复制到生产服务器并编辑文件以进行特定于生产的更改……:(
编辑:看起来这个问题没有标准答案,我已经接受了最流行的方法。
当前回答
我在django split-settings的帮助下管理我的配置。
它是默认设置的临时替换。它很简单,但可配置。并且不需要重构现有设置。
下面是一个小例子(文件示例/settings/__init__.py):
from split_settings.tools import optional, include
import os
if os.environ['DJANGO_SETTINGS_MODULE'] == 'example.settings':
include(
'components/default.py',
'components/database.py',
# This file may be missing:
optional('local_settings.py'),
scope=globals()
)
就是这样。
更新
我写了一篇关于用django-split-sttings管理django设置的博文。看看吧!
其他回答
不要使用settings.py,而是使用下面的布局:
.
└── settings/
├── __init__.py <= not versioned
├── common.py
├── dev.py
└── prod.py
py是您的大部分配置所在的位置。
py从common中导入所有内容,并覆盖它需要覆盖的内容:
from __future__ import absolute_import # optional, but I like it
from .common import *
# Production overrides
DEBUG = False
#...
类似地,dev.py从common.py导入所有内容,并覆盖它需要覆盖的内容。
最后,__init__.py是你决定加载哪些设置的地方,也是你存储秘密的地方(因此这个文件不应该被版本化):
from __future__ import absolute_import
from .prod import * # or .dev if you want dev
##### DJANGO SECRETS
SECRET_KEY = '(3gd6shenud@&57...'
DATABASES['default']['PASSWORD'] = 'f9kGH...'
##### OTHER SECRETS
AWS_SECRET_ACCESS_KEY = "h50fH..."
我喜欢这个解决方案的原因是:
所有东西都在您的版本控制系统中,除了机密信息 大多数配置都在一个地方:common.py。 特定于产品的东西放在prod。py中,特定于开发的东西放在dev。py中。这很简单。 你可以在prod.py或dev.py中覆盖common.py中的内容,也可以覆盖__init__.py中的任何内容。 这是简单的python。没有重新导入黑客。
我将我的设置拆分如下
settings/
|
|- base.py
|- dev.py
|- prod.py
我们有三种环境
dev 暂存 生产
现在,显然登台和生产应该有尽可能相似的环境。所以我们同时保留了prod.py。
但是在这种情况下,我必须确定正在运行的服务器是生产服务器。@T。斯通的回答帮助我写了如下支票。
from socket import gethostname, gethostbyname
PROD_HOSTS = ["webserver1", "webserver2"]
DEBUG = False
ALLOWED_HOSTS = [gethostname(), gethostbyname(gethostname()),]
if any(host in PROD_HOSTS for host in ALLOWED_HOSTS):
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
如果你愿意,可以选择维护不同的文件: 如果您正在使用git或任何其他VCS将代码从本地推送到服务器,您可以将设置文件添加到.gitignore。
这将允许您在两个地方有不同的内容而没有任何问题。所以在服务器上,你可以配置一个独立版本的settings.py,任何在本地所做的更改都不会反映在服务器上,反之亦然。
此外,它将删除settings.py文件从github也,大错误,这我已经看到许多新手做。
我认为最好的解决方案是@T提出的。但是我不知道为什么在Django中不使用DEBUG标志。我写下面的代码为我的网站:
if DEBUG:
from .local_settings import *
简单的解决方案总是比复杂的解决方案好。
我使用了上面提到的jpartogi的一个变体,我觉得它更简短:
import platform
from django.core.management import execute_manager
computername = platform.node()
try:
settings = __import__(computername + '_settings')
except ImportError:
import sys
sys.stderr.write("Error: Can't find the file '%r_settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n(If the file local_settings.py does indeed exist, it's causing an ImportError somehow.)\n" % (computername, __file__))
sys.exit(1)
if __name__ == "__main__":
execute_manager(settings)
基本上,在每台计算机(开发或生产)上,我都有适当的动态加载的hostname_settings.py文件。