Question

有些人仅将一个设置文件用于他们的项目。一个不错的选择是编写模块，将一个设置文件替换为具有针对每个特定需求的配置的目录：

...    
|    
settings    
|    
|-base.py    
|-local.py    
|-local_alex.py    
|-production.py    
|-staging.py    
|-test.py

我想只有一个设置文件用于生产是正常的。

但是，如果我有更多暂存实例/版本会怎样？假设我为每个登台实例/环境都有一个postgresql数据库。可以有更多的登台文件吗？还是应该以另一种方式来处理登台版本之间的差异？

所以我可以有两个设置文件，每个登台版本一个，或者使用相同的设置文件，但是以另一种方式指定这些差异。

推荐的方法是什么？

DjangoTwoScoops建议拥有更多的local.py设置文件，但没有人提及多个登台文件。

例如，我有生产，本地和测试文件。但是有两个登台版本，每个都有一个URL和不同的数据库。

DATABASES = {  
    'default': {    
        ...   
        'NAME': 'dbname1',    
        'USER': 'username1',   
       ...    
    }   
}    

and the second one:

DATABASES = {    
    'default': {    
        ...   
        'NAME': 'dbname2',   
        'USER': 'username2',   
       ...     
    }     
}

Answer 1

使用基本设置文件定义可以被环境变量覆盖的通用设置是一个好主意。因此您的数据库设置可能看起来像;

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'HOST': os.environ.get('DATABASE_HOST', 'localhost'),
        'PORT': os.environ.get('DATABASE_PORT', '3306'),
        'USER': os.environ.get('DATABASE_USER', 'root'),
        'PASSWORD': os.environ.get('DATABASE_PASSWORD', ''),
        'NAME': os.environ.get('DATABASE_NAME'),
    },
}

您提供的示例是一个很好的实践，但是我会避免为一个人使用特定的文件，或者如果可能的话，避免使用特定的本地设置。取而代之的是让环境变量来说明原本可以获取其自身设置文件的内容。这样，维护和在每个服务器/环境上轻松配置的代码就更少了。您的项目在其中运行的每个环境都会在环境变量中定义DJANGO_SETTINGS_MODULE，以告诉django使用哪些设置。

如果您订阅了Sentry之类的服务，则可以使用特定于环境的设置文件来继承基础，然后包括诸如日志记录和错误通知之类的内容，而您不想将其集成到生产之外。因此，production.py可能包含在该环境中运行时想要的其他安全设置；

DEBUG = False

CSRF_COOKIE_SECURE = True
SESSION_COOKIE_SECURE = True

SECURE_BROWSER_XSS_FILTER = True
SECURE_CONTENT_TYPE_NOSNIFF = True
SECURE_HSTS_SECONDS = 31536000
SECURE_HSTS_INCLUDE_SUBDOMAINS = False

如果您发现本地设置方法对您有用，则将它们从git中排除，以便不检查特定人员的设置，并且如果他们具有本地数据库服务器，则无需担心版本控制等中永远没有密码。

Answer 2

如果您想通过git跟踪这些文件，您实际上没有选择-您将所有通用设置都放在一个跟踪文件（settings.py）中，将每个环境的连接设置都放在一个不同的文件中（{ {1}}），然后访问一个未跟踪的密钥（settings_prod.py）。

但是说实话，在所有环境中使连接以相同的方式工作并不困难，因此您可以将这些设置放在通用文件中，然后仅将未跟踪的文件与用于oauth等的密钥交换。

在Django项目中为每个登台实例/版本设置一个设置文件是否正常？

2 个答案: