Как настроить Django для простой разработки и развертывания?

107

Я стараюсь использовать SQLite при выполнении Django но на живом сервере что-то более надежное (MySQL/PostgreSQL, для пример). Неизменно, есть и другие изменения в Django настройки: различные местоположения/интенсивности регистрации, медиа-пути и т.д.

Как вы управляете всеми этими изменениями, чтобы сделать развертывание простой, автоматический процесс?

  • 0
    Я не делаю ничего такого фантастического, как кто-либо еще, по-видимому :). Я просто использую ORM, который поставляет django.
  • 1
    Вопрос был о том, как автоматизировать изменение настроек для переключения между средами :-)
Показать ещё 2 комментария
Теги:

12 ответов

86

Обновление 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 с конфигурацией, специфичной для хоста, и все остальное обрабатывается автоматически.

Посмотрите пример здесь.

  • 2
    Что делать, если подготовка (разработка) и производство находятся на одной машине? platform.node () возвращает то же самое тогда.
  • 2
    Пример ссылки не работает.
Показать ещё 2 комментария
26

Лично я использую один параметр 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/'

и т.д. Немного менее читаемый, но он отлично работает и экономит на том, чтобы жонглировать несколькими файлами настроек.

  • 0
    Мне нравится эта идея, но она не позволит мне различать разные экземпляры Django, работающие на одном хосте. Это может произойти, например, если у вас на разных хостах работают разные экземпляры для разных поддоменов.
21

В конце settings.py у меня есть следующее:

try:
    from settings_local import *
except ImportError:
    pass

Таким образом, если я хочу переопределить настройки по умолчанию, мне нужно просто поместить settings_local.py рядом с settings.py.

  • 4
    Это немного опасно, потому что, если опечатка в settings_local приведет к ImportError , это except заставит ее молча поглотить.
  • 0
    Вы можете проверить сообщение No module named... vs cannot import name... , но оно хрупкое. Или поместите ваш импорт в settings_local.py в блоки try и MisconfiguredSettings более конкретное исключение: MisconfiguredSettings или что-то в этом роде.
11

У меня есть два файла. settings_base.py, который содержит общие/стандартные настройки и который проверяется в исходном элементе управления. Каждое развертывание имеет отдельный settings.py, который выполняет from settings_base import * в начале и затем переопределяет по мере необходимости.

  • 1
    Я тоже этим пользуюсь. Он превосходит инверсию (dmishe "from settings_local import *" в конце settings.py), потому что он позволяет локальным настройкам получать доступ и изменять глобальные настройки, если это необходимо.
  • 3
    Если settings_local.py делает это from settings import * , он может переопределить значения в settings.py . (файл settings_local.py должен быть импортирован в конце файла settings.py ).
Показать ещё 1 комментарий
7

Самый простой способ я нашел:

1) используйте локальную разработку по умолчанию settings.py и 2) создайте production-settings.py, начиная с:

import os
from settings import *

И затем просто переопределите настройки, которые различаются по производительности:

DEBUG = False
TEMPLATE_DEBUG = DEBUG


DATABASES = {
    'default': {
           ....
    }
}
2

В некоторой степени связанный с проблемой развертывания самого Django с несколькими базами данных, вы можете взглянуть на Djangostack. Вы можете загрузить абсолютно бесплатный установщик, который позволяет устанавливать Apache, Python, Django и т.д. В рамках процесса установки мы можем выбрать, какую базу данных вы хотите использовать (MySQL, SQLite, PostgreSQL). Мы интенсивно используем инсталляторы при автоматическом развертывании внутренних объектов (их можно запускать в автоматическом режиме).

  • 1
    В качестве альтернативы я хотел бы порекомендовать Django Turnkey Linux на основе стека Ubuntu * NIX с предустановленным django.
1

Ну, я использую эту конфигурацию:

В конце 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
1

У меня есть файл 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.

1

В дополнение к файлам с несколькими параметрами, упомянутыми Джим, я также стараюсь разместить два параметра в моем файле settings.py в верхней части BASE_DIR и BASE_URL, установленном на путь кода и URL-адрес базы сайта, все остальные настройки изменены, чтобы добавить к ним.

BASE_DIR = "/home/sean/myapp/" например MEDIA_ROOT = "%smedia/" % BASEDIR

Поэтому при перемещении проекта мне нужно только отредактировать эти настройки, а не искать весь файл.

Я бы также рекомендовал посмотреть на ткань и Capistrano (инструмент Ruby, но его можно использовать для развертывания приложений Django), которые облегчают автоматизация удаленного развертывания.

  • 0
    Ansible - это python и предлагает гораздо более надежные средства обеспечения, чем Fabric. Они хорошо сочетаются друг с другом.
0

Я использую среду:

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

Я считаю, что это гораздо лучший подход, потому что в конце концов вам нужны специальные настройки для тестовой среды, и вы можете легко добавить его в это условие.

0

Я думаю, что это зависит от размера сайта относительно того, нужно ли вам переходить от использования SQLite, я успешно использовал SQLite на нескольких небольших сайтах Live, и он отлично работает.

-1

На самом деле вам, вероятно, следует подумать о том, чтобы иметь одинаковые (или почти одинаковые) конфигурации для вашей среды разработки и производства. В противном случае иногда случаются ситуации типа "Эй, это работает на моей машине".

Итак, чтобы автоматизировать развертывание и устранить эти проблемы WOMM, просто используйте Docker.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню