Эта ссылка будет представлять интерес для Вас: http://msdn.microsoft.com/en-us/library/ds8bxk2a.aspx
Для http соединений, классы WebRequest и WebResponse используют SSL для общения с веб-хостами та поддержка SSL. Решение использовать SSL принято классом WebRequest, на основе URI, который это дано. Если URI начинается с "https": SSL используется; если URI начинается с "http": незашифрованное соединение используется.
Создайте основной файл settings.py, который должен включать следующее:
# Pull in hostname-based changes.
import socket
HOSTNAME = socket.gethostname().lower().split('.')[0].replace('-','')
try:
exec "from myproject.settings.host_%s import *" % HOSTNAME
except ImportError:
pass
# Pull in the local changes.
try:
from myproject.settings.local import *
except ImportError:
pass
Теперь вы создаете новый файл настроек для каждого имени хоста, которое вам нужно. Но они действительно маленькие. Каждый файл вашего рабочего сервера содержит только:
from myproject.settings.production import *
, а ваши промежуточные серверы имеют:
from myproject.settings.staging import *
Теперь вы можете создать файл production.py с производственными переопределениями для настроек, staging.py и так далее. Вы можете создавать новые файлы для каждой роли, которую играет сервер.
Наконец, вы можете создать файл local.py на любом компьютере (включая машины разработчиков) с локальными переопределениями и пометить этот файл как игнорируемый системой контроля версий, чтобы изменения не регистрируются.
Мы использовали эту структуру годами, она работает очень хорошо.
Я использую базовый файл settings.py, а затем файл настроек для каждой среды (например, dev_settings.py, live_settings.py)
В верхней части каждого файл для конкретной среды, который у меня есть
from settings import *
Затем я могу просто переопределить любые настройки, которые мне нужно изменить для конкретной среды
Чтобы гарантировать, что каждая среда использует правильные настройки, я просто изменяю переменную среды DJANGO_SETTINGS_MODULE. Как вы это делаете, зависит от того, как вы развертываете django (mod_wsgi, mod_python и так далее ...)
+1 for Ned's answer, but want to mention a slight variation.
I see Django settings as falling into 2 areas: project and instance.
Project settings are common to all the instances (dev, testing, production, multiple sites in production) and instance settings are local to just that specific server instance.
Project settings are things like INSTALLED_APPS
(although local settings may also include this to add things like django debug toolbar for developers), MIDDLEWARE_CLASSES
, and TEMPLATE_LOADERS
. Instance settings are things like the database settings, MEDIA_URL
settings, etc.
Project settings go in settings.py
and instance settings in local_settings.py
, which is imported into settings.py
. local_settings.py
is listed in .gitignore
and project settings are stored in git.
I've tried several other variations on this but ended here because it's just so much simpler.
The only time I don't like this setup is for multiple sites (using Django sites framework), which end up proliferating into things like sitename_settings.py
which imports sitename_local_settings.py
etc.
Finally, I do keep a local_settings_template.py
in git, to use as a starting point for new instances and for devs to track changes they might need to their own local settings.