为本地开发和生产服务器处理设置的推荐方法是什么?其中一些(如常量等)可以在两者中更改/访问,但其中一些(如静态文件的路径)需要保持不同,因此不应该在每次部署新代码时都重写。
目前,我正在将所有常量添加到settings.py中。但是每次我在本地更改一些常量时,我都必须将其复制到生产服务器并编辑文件以进行特定于生产的更改……:(
编辑:看起来这个问题没有标准答案,我已经接受了最流行的方法。
为本地开发和生产服务器处理设置的推荐方法是什么?其中一些(如常量等)可以在两者中更改/访问,但其中一些(如静态文件的路径)需要保持不同,因此不应该在每次部署新代码时都重写。
目前,我正在将所有常量添加到settings.py中。但是每次我在本地更改一些常量时,我都必须将其复制到生产服务器并编辑文件以进行特定于生产的更改……:(
编辑:看起来这个问题没有标准答案,我已经接受了最流行的方法。
当前回答
不要使用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,其中存储所有环境的通用设置 每当我需要使用具有特定要求的新环境时,我都会创建新的设置文件(例如。Settings_local.py),它继承settings_base.py的内容,并覆盖/添加适当的设置变量(从settings_base import *)
(要使用自定义设置文件运行manage.py,只需使用——settings命令option: manage.py <命令>——settings=settings_you_wish_to_use.py)
不要使用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。没有重新导入黑客。
我使用Harper Shelby发布的“if DEBUG”风格设置的稍微修改版本。显然,根据环境(win/linux/等等),代码可能需要稍作调整。
我在过去使用“if DEBUG”,但我发现偶尔我需要用DEUBG设置为False进行测试。我真正想要区分的是环境是生产环境还是开发环境,这给了我选择DEBUG级别的自由。
PRODUCTION_SERVERS = ['WEBSERVER1','WEBSERVER2',]
if os.environ['COMPUTERNAME'] in PRODUCTION_SERVERS:
PRODUCTION = True
else:
PRODUCTION = False
DEBUG = not PRODUCTION
TEMPLATE_DEBUG = DEBUG
# ...
if PRODUCTION:
DATABASE_HOST = '192.168.1.1'
else:
DATABASE_HOST = 'localhost'
我仍然认为这种设置方式是一种正在进行中的工作。我还没有看到任何一种方法来处理Django设置,它涵盖了所有的基础,同时设置起来也不是很麻烦(我不喜欢5x设置文件方法)。
我将我的设置拆分如下
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
我对这个问题的解决方案在某种程度上也是这里已经提到的一些解决方案的混合:
我保留了一个名为local_settings.py的文件,其内容为USING_LOCAL = True在dev中,USING_LOCAL = False在prod中 在settings.py中,我对该文件进行导入以获得USING_LOCAL设置
然后我将所有与环境相关的设置都基于此:
DEBUG = USING_LOCAL
if USING_LOCAL:
# dev database settings
else:
# prod database settings
我更喜欢这样,而不是有两个单独的settings.py文件,我需要维护,因为我可以将我的设置结构化地保存在一个文件中,而不是将它们分布在几个文件中。就像这样,当我更新一个设置时,我不会忘记在两个环境中都这样做。
当然每种方法都有它的缺点,这种方法也不例外。这里的问题是,无论何时将更改推到生产环境中,我都不能覆盖local_settings.py文件,这意味着我不能盲目地复制所有文件,但这是我可以接受的。