Я стараюсь использовать SQLite при выполнении Django но на живом сервере что-то более надежное (MySQL/PostgreSQL, для пример). Неизменно, есть и другие изменения в Django настройки: различные местоположения/интенсивности регистрации, медиа-пути и т.д.
Как вы управляете всеми этими изменениями, чтобы сделать развертывание простой, автоматический процесс?
Обновление django-configurations, что, вероятно, является лучшим вариантом для большинства людей, чем для него вручную.
Если вы предпочитаете делать что-то вручную, мой предыдущий ответ по-прежнему применяется:
У меня есть несколько файлов настроек.
settings_local.py - конфигурация, специфичная для хоста, такая как имя базы данных, пути к файлу и т.д.settings_development.py - конфигурация, используемая для разработки, например. DEBUG = True.settings_production.py - конфигурация, используемая для производства, например. SERVER_EMAIL.Я связываю их все вместе с файлом settings.py, который сначала импортирует settings_local.py, а затем один из двух других. Он решает загрузить две настройки внутри settings_local.py - DEVELOPMENT_HOSTS и PRODUCTION_HOSTS. settings.py вызывает platform.node(), чтобы найти имя хоста на компьютере, на котором он запущен, а затем ищет это имя хоста в списках и загружает второй файл настроек в зависимости от того, в каком списке он находит имя хоста.
Таким образом, единственное, о чем вам действительно нужно беспокоиться, - это поддерживать текущий файл settings_local.py с конфигурацией, специфичной для хоста, и все остальное обрабатывается автоматически.
Посмотрите пример здесь.
Лично я использую один параметр settings.py для проекта, я просто ищу его имя хоста (мои машины разработки имеют имена хостов, которые начинаются с "gabriel", поэтому я просто имею это:
import socket
if socket.gethostname().startswith('gabriel'):
LIVEHOST = False
else:
LIVEHOST = True
то в других частях у меня есть такие вещи, как:
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/'
и т.д. Немного менее читаемый, но он отлично работает и экономит на том, чтобы жонглировать несколькими файлами настроек.
В конце settings.py у меня есть следующее:
try:
from settings_local import *
except ImportError:
pass
Таким образом, если я хочу переопределить настройки по умолчанию, мне нужно просто поместить settings_local.py рядом с settings.py.
У меня есть два файла. settings_base.py, который содержит общие/стандартные настройки и который проверяется в исходном элементе управления. Каждое развертывание имеет отдельный settings.py, который выполняет from settings_base import * в начале и затем переопределяет по мере необходимости.
Самый простой способ я нашел:
1) используйте локальную разработку по умолчанию settings.py и 2) создайте production-settings.py, начиная с:
import os
from settings import *
И затем просто переопределите настройки, которые различаются по производительности:
DEBUG = False
TEMPLATE_DEBUG = DEBUG
DATABASES = {
'default': {
....
}
}
В некоторой степени связанный с проблемой развертывания самого Django с несколькими базами данных, вы можете взглянуть на Djangostack. Вы можете загрузить абсолютно бесплатный установщик, который позволяет устанавливать Apache, Python, Django и т.д. В рамках процесса установки мы можем выбрать, какую базу данных вы хотите использовать (MySQL, SQLite, PostgreSQL). Мы интенсивно используем инсталляторы при автоматическом развертывании внутренних объектов (их можно запускать в автоматическом режиме).
В дополнение к файлам с несколькими параметрами, упомянутыми Джим, я также стараюсь разместить два параметра в моем файле settings.py в верхней части BASE_DIR и BASE_URL, установленном на путь кода и URL-адрес базы сайта, все остальные настройки изменены, чтобы добавить к ним.
BASE_DIR = "/home/sean/myapp/"
например MEDIA_ROOT = "%smedia/" % BASEDIR
Поэтому при перемещении проекта мне нужно только отредактировать эти настройки, а не искать весь файл.
Я бы также рекомендовал посмотреть на ткань и Capistrano (инструмент Ruby, но его можно использовать для развертывания приложений Django), которые облегчают автоматизация удаленного развертывания.
У меня есть файл settings.py во внешнем каталоге. Таким образом, он не проверяется в исходном контроле или не переписывается развертыванием. Я поместил это в файл settings.py в свой проект Django вместе с любыми настройками по умолчанию:
import sys
import os.path
def _load_settings(path):
print "Loading configuration from %s" % (path)
if os.path.exists(path):
settings = {}
# execfile can't modify globals directly, so we will load them manually
execfile(path, globals(), settings)
for setting in settings:
globals()[setting] = settings[setting]
_load_settings("/usr/local/conf/local_settings.py")
Примечание. Это очень опасно, если вы не можете доверять local_settings.py.
Ну, я использую эту конфигурацию:
В конце settings.py:
#settings.py
try:
from locale_settings import *
except ImportError:
pass
И в файле locale_settings.py:
#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
Я думаю, что это зависит от размера сайта относительно того, нужно ли вам переходить от использования SQLite, я успешно использовал SQLite на нескольких небольших сайтах Live, и он отлично работает.
Я использую среду:
if os.environ.get('WEB_MODE', None) == 'production' :
from settings_production import *
else :
from settings_dev import *
Я считаю, что это гораздо лучший подход, потому что в конце концов вам нужны специальные настройки для тестовой среды, и вы можете легко добавить его в это условие.
На самом деле вам, вероятно, следует подумать о том, чтобы иметь одинаковые (или почти одинаковые) конфигурации для вашей среды разработки и производства. В противном случае иногда случаются ситуации типа "Эй, это работает на моей машине".
Итак, чтобы автоматизировать развертывание и устранить эти проблемы WOMM, просто используйте Docker.