Як налаштувати Django для простої розробки та розгортання?

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

Як ви керуєте всіма цими змінами, щоб зробити розгортання простим, автоматизованим процесом?

Оновлення: було випущено конфігурації django, що, мабуть, кращий варіант для більшості людей, ніж це робити вручну.

Якщо ви хочете робити речі вручну, моя попередня відповідь все ще застосовується:

У мене є кілька файлів налаштувань.

• 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 у зовнішньому каталозі. Таким чином, він не перевіряється в контролі джерела або перезаписується розгортанням. Я поміщую це у файл 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 вгорі BASE_DIRі BASE_URLвстановлювати шлях коду та URL-адресу до основи сайту, всі інші налаштування змінюються приєднатися до них.

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

Тому під час переміщення проекту мені залишається лише редагувати ці налаштування, а не шукати весь файл.

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

Ну, я використовую цю конфігурацію:

В кінці 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

Стільки складних відповідей!

Кожен файл settings.py має:

BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

Я використовую цей каталог для встановлення такої змінної DEBUG (замініть дирекцію, де знаходиться ваш код розробника):

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

Потім, кожного разу, коли файл settings.py переміщуватиметься, DEBUG буде помилковим, і це ваше виробниче середовище.

Кожен раз, коли вам потрібні інші налаштування, ніж ті, що у вашому середовищі розробників, просто використовуйте:

if(DEBUG):
    #Debug setting
else:
    #Release setting

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

Я використовую середовище:

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

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

Це старіший пост, але я думаю, якщо я додаю цю корисну, libraryце спростить речі.

Використовуйте конфігурацію джанго

Швидкий старт

pip install django-configurations

Потім підклас кластера включеної конфігурації.Конфігураційний клас у налаштуваннях.py вашого проекту або будь-який інший модуль, який ви використовуєте для зберігання констант налаштувань, наприклад:

# mysite/settings.py

from configurations import Configuration

class Dev(Configuration):
    DEBUG = True

Встановіть DJANGO_CONFIGURATIONзмінну оточення на ім'я щойно створеного класу, наприклад у ~/.bashrc:

export DJANGO_CONFIGURATION=Dev

і DJANGO_SETTINGS_MODULEзмінна середовище на шлях імпорту модуля, як зазвичай, наприклад у bash:

export DJANGO_SETTINGS_MODULE=mysite.settings

Альтернативно надайте --configurationпараметр при використанні команд управління Django уздовж рядків --settingsпараметра командного рядка за замовчуванням , наприклад:

python manage.py runserver --settings=mysite.settings --configuration=Dev

Щоб увімкнути Django для використання вашої конфігурації, вам тепер потрібно змінити ваш script.py або wsgi.py скрипт, щоб використовувати версії django-configurations відповідних функцій запуску, наприклад, типовий manage.py з використанням django-конфігурацій виглядатиме так:

#!/usr/bin/env python

import os
import sys

if __name__ == "__main__":
    os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings')
    os.environ.setdefault('DJANGO_CONFIGURATION', 'Dev')

    from configurations.management import execute_from_command_line

    execute_from_command_line(sys.argv)

Зауважте, у рядку 10 ми не використовуємо загальний інструмент, django.core.management.execute_from_command_lineа натомість configurations.management.execute_from_command_line.

Це стосується і вашого файлу wsgi.py , наприклад:

import os

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings')
os.environ.setdefault('DJANGO_CONFIGURATION', 'Dev')

from configurations.wsgi import get_wsgi_application

application = get_wsgi_application()

Тут ми не використовуємо функцію за замовчуванням, django.core.wsgi.get_wsgi_applicationа натомість configurations.wsgi.get_wsgi_application.

Це воно! Тепер ви можете використовувати свій проект за допомогою файлу Manag.py та улюбленого сервера з підтримкою WSGI.

Насправді вам, мабуть, слід подумати про наявність однакових (або майже однакових) конфігурацій для вашого середовища розробки та виробництва. В іншому випадку періодично трапляються ситуації на кшталт "Ей, це працює на моїй машині".

Тож для автоматизації розгортання та усунення цих проблем WOMM просто використовуйте Docker .