blocks|key|1757575|text|我有两份文件。包含通用/默认设置的settings_base.py，并签入到源代码管理中。每个部署都有一个单独的settings.py，它在开始时执行from+settings_base+import+*，然后根据需要进行覆盖。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1757576|entityMap^0|H|G|1K|B|23|R|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|O|8|@]|D|@]|E|$]]]|G|$]]

I have two files. <code>settings_base.py</code> which contains common/default settings, and which is checked into source control. Each deployment has a separate <code>settings.py</code>, which executes <code>from settings_base import *</code> at the beginning and then overrides as needed.

blocks|key|1757623|text|除了吉姆提到的多个设置文件外，我还倾向于在顶部的BASE_DIR和BASE_URL文件中放置两个设置，分别设置为代码的路径和站点基础的URL，所有其他设置都会被修改以附加到这些设置中。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1757624|BASE_DIR+=+"/home/sean/myapp/"，例如MEDIA_ROOT+=+"%25smedia/"+%25+BASEDIR|1757625|因此，当移动项目时，我只需要编辑这些设置，而不是搜索整个文件。|1757626|我还推荐使用fabric和Capistrano+(Ruby+tool，但它可以用来部署Django应用程序)，它们可以促进远程部署的自动化。|1757627|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Capistrano^0|O|8|X|8|0|0|U|X|X|0|0|D|A|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@$9|U|A|V|B|C]|$9|W|A|X|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Y|8|@$9|Z|A|10|B|C]|$9|11|A|12|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|13|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|14|8|@]|D|@$9|15|A|16|1|17]]|E|$]]|$1|L|3|-4|5|6|7|18|8|@]|D|@]|E|$]]]|M|$N|$5|O|P|Q|E|$R|S]]]]

In addition to the multiple settings files mentioned by Jim, I also tend to place two settings into my settings.py file at the top <code>BASE_DIR</code> and <code>BASE_URL</code> set to the path of the code and the URL to the base of the site, all other settings are modified to append themselves to these.

<code>BASE_DIR = "/home/sean/myapp/"</code>
e.g. <code>MEDIA_ROOT = "%smedia/" % BASEDIR</code>

So when moving the project I only have to edit these settings and not search the whole file.

I would also recommend looking at fabric and <a href="http://en.wikipedia.org/wiki/Capistrano" rel="nofollow noreferrer">Capistrano</a> (Ruby tool, but it can be used to deploy Django applications) which facilitate automation of remote deployment.

blocks|key|1542765|text|就我个人而言，我为这个项目使用了一个settings.py，我只是让它查找它所在的主机名(我的开发机器的主机名以"gabriel“开头，所以我只有：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1542766|import+socket
if+socket.gethostname().startswith('gabriel'):
++++LIVEHOST+=+False
else:+
++++LIVEHOST+=+True|code-block|syntax|javascript|1542767|然后在其他部分，我有类似这样的东西：|1542768|if+LIVEHOST:
++++DEBUG+=+False
++++PREPEND_WWW+=+True
++++MEDIA_URL+=+'http://static1.grsites.com/'
else:
++++DEBUG+=+True
++++PREPEND_WWW+=+False
++++MEDIA_URL+=+'http://localhost:8000/static/'|1542769|诸若此类。可读性稍差一些，但它工作得很好，并且省去了必须处理多个设置文件的麻烦。|1542770|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Personally, I use a single settings.py for the project, I just have it look up the hostname it's on (my development machines have hostnames that start with "gabriel" so I just have this:

<pre><code>import socket
if socket.gethostname().startswith('gabriel'):
 LIVEHOST = False
else: 
 LIVEHOST = True
</code></pre>

then in other parts I have things like:

<pre><code>if LIVEHOST:
 DEBUG = False
 PREPEND_WWW = True
 MEDIA_URL = 'http://static1.grsites.com/'
else:
 DEBUG = True
 PREPEND_WWW = False
 MEDIA_URL = 'http://localhost:8000/static/'
</code></pre>

and so on. A little bit less readable, but it works fine and saves having to juggle multiple settings files.

blocks|key|1757706|text|在settings.py的末尾，我有以下内容：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1757707|try:
++++from+settings_local+import+*
except+ImportError:
++++pass|code-block|syntax|javascript|1757708|这样，如果我想覆盖默认设置，我只需要将settings_local.py放在settings.py旁边。|1757709|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

At the end of settings.py I have the following:

<pre><code>try:
 from settings_local import *
except ImportError:
 pass
</code></pre>

This way if I want to override default settings I need to just put settings_local.py right next to settings.py.

blocks|key|1542858|text|我认为这取决于网站的规模，至于你是否需要停止使用SQLite，我已经在几个较小的实时网站上成功地使用了SQLite，它运行得很好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1542859|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I think it depends on the size of the site as to whether you need to step up from using SQLite, I've successfully used SQLite on several smaller live sites and it runs great.

blocks|key|1757812|text|在某种程度上，对于使用多个数据库部署Django本身的问题，您可能想看看Djangostack。您可以下载一个完全免费的安装程序，它允许您安装Apache、Python、Django等。作为安装过程的一部分，我们允许您选择要使用的数据库(MySQL、SQLite、PostgreSQL)。在内部自动化部署时，我们广泛使用安装程序(它们可以在无人参与模式下运行)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1757813|entityMap|0|LINK|mutability|MUTABLE|url|http://bitnami.org/stack/djangostack^0|10|B|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Somewhat related, for the issue of deploying Django itself with multiple databases, you may want to take a look at <a href="http://bitnami.org/stack/djangostack" rel="nofollow">Djangostack</a>. You can download a completely free installer that allows you to install Apache, Python, Django, etc. As part of the installation process we allow you to select which database you want to use (MySQL, SQLite, PostgreSQL). We use the installers extensively when automating deployments internally (they can be run in unattended mode).

blocks|key|1542942|text|好的，我使用这个配置：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1542943|在settings.py的末尾：|1542944|#settings.py
try:
++++from+locale_settings+import+*
except+ImportError:
++++pass|code-block|syntax|javascript|1542945|在locale_settings.py中：|1542946|#locale_settings.py
class+Settings(object):

++++def+__init__(self):
++++++++import+settings
++++++++self.settings+=+settings

++++def+__getattr__(self,+name):
++++++++return+getattr(self.settings,+name)

settings+=+Settings()

INSTALLED_APPS+=+settings.INSTALLED_APPS+%2B+(
++++'gunicorn',)

#+Delete+duplicate+settings+maybe+not+needed,+but+I+prefer+to+do+it.
del+settings
del+Settings|1542947|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Well, I use this configuration:

At the end of settings.py:

<pre><code>#settings.py
try:
 from locale_settings import *
except ImportError:
 pass
</code></pre>

And in locale_settings.py:

<pre><code>#locale_settings.py
class Settings(object):

 def __init__(self):
 import settings
 self.settings = settings

 def __getattr__(self, name):
 return getattr(self.settings, name)

settings = Settings()

INSTALLED_APPS = settings.INSTALLED_APPS + (
 'gunicorn',)

# Delete duplicate settings maybe not needed, but I prefer to do it.
del settings
del Settings
</code></pre>

blocks|key|1543020|text|我使用环境：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1543021|if+os.environ.get('WEB_MODE',+None)+==+'production'+:
+++from+settings_production+import+*
else+:
+++from+settings_dev+import+*|code-block|syntax|javascript|1543022|我相信这是一种更好的方法，因为最终您需要为您的测试环境设置特殊的设置，并且您可以很容易地将其添加到此条件中。|1543023|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

I use environment:

<pre><code>if os.environ.get('WEB_MODE', None) == 'production' :
 from settings_production import *
else :
 from settings_dev import *
</code></pre>

I believe this is a much better approach, because eventually you need special settings for your test environment, and you can easily add it to this condition.

blocks|key|1543077|text|实际上，您可能应该考虑为您的开发和生产环境配置相同(或几乎相同)的配置。否则，像“嘿，它在我的机器上工作”这样的情况就会时不时地发生。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1543078|因此，为了自动化部署并消除这些WOMM问题，只需使用Docker即可。|offset|length|1543079|entityMap|0|LINK|mutability|MUTABLE|url|https://www.docker.com/^0|0|Q|6|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

In fact you should probably consider having the same (or almost the same) configs for your development and production environment. Otherwise, situations like "Hey, it works on my machine" will happen from time to time.

So in order to automate your deployment and eliminate those WOMM issues, just use <a href="https://www.docker.com/" rel="nofollow noreferrer">Docker</a>.

blocks|key|1758124|text|这么多复杂的答案！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1758125|每个settings.py文件都附带：|1758126|BASE_DIR+=+os.path.dirname(os.path.dirname(os.path.abspath(__file__)))|code-block|syntax|javascript|1758127|我使用该目录来设置调试变量，如下所示(替换为您的dev代码所在的目录)：|1758128|DEBUG=False
if(BASE_DIR=="/path/to/my/dev/dir"):
++++DEBUG+=+True|1758129|然后，每次移动settings.py文件时，DEBUG将为False，这就是您的生产环境。|1758130|每次您需要与开发环境中的设置不同的设置时，只需使用：|1758131|if(DEBUG):
++++#Debug+setting
else:
++++#Release+setting|1758132|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|Y|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|R|5|F|7|11|8|@]|9|@]|A|$G|H]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

So many complicated answers!

Every settings.py file comes with :

<pre><code>BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
</code></pre>

I use that directory to set the DEBUG variable like this (reaplace with the directoy where your dev code is):

<pre><code>DEBUG=False
if(BASE_DIR=="/path/to/my/dev/dir"):
 DEBUG = True
</code></pre>

Then, every time the settings.py file is moved, DEBUG will be False and it's your production environment.

Every time you need different settings than the ones in your dev environment just use:

<pre><code>if(DEBUG):
 #Debug setting
else:
 #Release setting
</code></pre>

I tend to use <a href="http://en.wikipedia.org/wiki/SQLite" rel="noreferrer">SQLite</a> when doing <a href="http://en.wikipedia.org/wiki/Django_(web_framework)" rel="noreferrer">Django</a>
development, but on a live server something more robust is
often needed (<a href="http://en.wikipedia.org/wiki/MySQL" rel="noreferrer">MySQL</a>/<a href="http://en.wikipedia.org/wiki/PostgreSQL" rel="noreferrer">PostgreSQL</a>, for example).
Invariably, there are other changes to make to the Django
settings as well: different logging locations / intensities,
media paths, etc.

How do you manage all these changes to make deployment a
simple, automated process?

How do you configure Django for simple development and deployment?

PostgreSQL

数据库

服务器

Django

SQLite

Python

MySQL

在进行开发时，我倾向于使用，但在实时服务器上，通常需要更健壮的工具(例如/)。通常，还需要对Django设置进行其他更改:不同的日志记录位置/强度、媒体路径等。您如何管理所有这些更改，使部署成为一个简单、自动化的过程？

问如何配置Django进行简单的开发和部署？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何配置Django进行简单的开发和部署？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何配置Django进行简单的开发和部署？
EN