Налаштування Django проекту

Це стаття із серії “Кращі практики розробки з Django”. Гляньте також інші статті із даної серії:

В даній статті серії “Кращі практики розробки з Django” розкажу про власні практики із налаштування Django проекту. Тобто будемо говорити про модуль settings.py, який живе в корені проекту.

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

Саме тому пропоную вашій увазі кілька рекомендацій щодо покращення структури налаштувань Django проекту. А поговоримо в даній статті про:

основні принципи налаштувань;
множинні файли settings.py під різні середовища;
кілька файлів для опису залежностей проекту requirements.txt;
шляхи у модулі налаштувань.

Якщо ви розробляєте веб-сайти на Django фреймворку, тоді, впевнений, дана стаття буде вам корисною. Більшість практик ми в своїй команді запозичили від інших розробників в Django спільності, а також з книги “Two Scoops of Django”.

Почнемо із розбору основних принципів, якими керуватимемось для побудови нашої власної структури налаштувань:

Основні принципи

Для ефективної побудови структури налаштувань варто встановити основні принципи і правила, які допоможуть робити правильні рішення:

репозиторій коду: налаштування, як і логіка проекту, повинні знаходитись в репозиторії коду;
cекретні дані: виключенням до попереднього правила є секретні дані; вони не повинні знаходитись в репозиторії коду і мають налаштовуватись безпосередньо на машині, де запускається проект; до таких даних належать паролі, секретні ключі та API ключі;
Don’t Repeat Yourself: при побудові нової структури і підходу до налаштувань проекту важливо уникати дублікації коду та роботи програміста; це правило допоможе нам ефективніше продумати архітектуру модулів налаштувань;
різні налаштування для різних середовищ: в різних середовищах налаштування можуть і будуть відрізнятись; відповідно, логічно буде користуватись кількома різними файлами налаштувань; проте попереднє правило рекомендує уникати повторень; саме тому, далі в статті ми розглянемо варіанти, як, маючи різні модулі і файли, не дублювати подібних налаштувань в цих різних файлах.

При розробці веб-сайту ми, зазвичай, маємо справу із наступним мінімумом середовищ:

локальна розробницька машина: комп’ютер програміста, на якому відбувається розробка проекту;
демо, preview або staging сервер, де ми показуємо клієнту попереднє демо проекту; налаштування тут є максимально подібні до кінцевого сервера;
CI і/або тестовий сервер: тут ми регулярно проганяємо автоматичні тести проекту; так званий Continuous Integration (CI) підхід;
production або кінцевий сервер: де наш сайт обслуговує реальних користувачів.

Тепер ми готові для розбору основної ідеї впорядкування налаштувань проекту:

Множинні модулі налаштувань Django проекту

Основною ідеєю є створення не одного, а кількох модулів з налаштуваннями. На кожен окремий сервер ми створюємо окремий модуль. При цьому, щоб уникати повторень налаштувань, які співпадають на різних середовищах, ми також створюємо модуль base.py. І з інших модулів налаштувань імпортуємо ці однакові змінні.

В корені проекту ми створюємо папку settings із порожнім модулем __init__.py. В цей під-пакет набиваємо необхідні модулі під різні середовища проекту:

Множинні модулі налаштування Джанго проекту

base.py: тримаємо тут усі однакові змінні;
local.py: містить налаштування для локальної розробницької машини програміста (пізніше ми зробимо так, щоб даний файл був однаковий і підходив більшості членів команди розробки);
staging.py: стейджинг/preview/демо інстанс;
test.py: файл конфігурації для прогонки тестів;
production.py: налаштування продакшин сайту.

Кожен із модулів local.py, staging.py, test.py, production.py імпортує дані з base.py:

from .base import *

# а далі вже змінні, специфічні для середовища local

from .base import *

# а далі вже змінні, специфічні для середовища local

Для запуску shell чи runserver команди скрипта manage.py використовуємо опцію “–settings”, щоб передати потрібний модуль з налаштуваннями:

$ python manage.py runserver --settings=mydjangoproject.settings.local

1	$ python manage.py runserver --settings=mydjangoproject.settings.local

Також, якщо є необхідність різним розробникам працювати із різними локальними налаштуваннями (наприклад один програміст працює на лінуксі, а інший на макінтоші і там відрізняються деякі змінні середовища), тоді можна в репозиторій додавати конфігураційні файли із нікнеймами розробників. Наприклад: dev_vitaliy.py (або local_vitaliy.py). В даному модулі ми вже будемо імпортували усі змінні не з модуля base.py, а з local.py, щоб користуватися спільними налаштуваннями робочого середовища команди і модифікувати лише необхідні речі:

from .local import *

# my custom variable
CACHE_TIMEOUT = 15

from .local import *

# my custom variable

CACHE_TIMEOUT = 15

Чому такі файли окремих розробників також варто тримати в репозиторії? Для того, щоб інший член команди міг легко допомогти із робочим середовищем і при потребі побачити очевидні проблеми в налаштуваннях.

***

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

# often used in urls.py module
if DEBUG:
    do_something()

# often used in urls.py module

if DEBUG:

do_something()

***

Наступним кроком розглянемо ті налаштування, які не варто тримати в репозиторії коду:

Секретні дані

Секретні дані такі як паролі та секретні Django та API ключі, не варто тримати в репозиторії коду. Адже кожен із доступом до репозиторію (особливо якщо мова йде про публічний репозиторій) матиме доступ і до секретних даних. Хорошою практикою може бути встановлення таких даних безпосередньо уже на сервері. Проте далеко не всі платформи для деплойменту веб-аплікації (“Platform-as-a-service” по типу Heroku, PythonAnywhere і т.д.) дозволяють напряму редагувати Python модулі на кінцевому сервері.

Саме тому одним із оптимальних підходів є встановлення секретних змінних в якості змінних середовища і використання цих змінних у вашому Python коді.

На операційних системах Mac та Linux змінні середовища можемо встановлювати через файли в домашній директорії .bashrc, .bash_profile чи .profile. Також, деякі із змінних (наприклад API ключі) можемо встановлювати через bin/activate скрипт вашого віртуального Python середовища. Додавши до кінця скрипта подібні команди:

export SECRET_KEY1=*********
export SECRET_KEY2=*********

1 2	export SECRET_KEY1=******* export SECRET_KEY2=*******

На Windows змінні можна встановити через команду setx. Альтернативно, також можна додати подібну стрічку до скрипта bin/activate.bat вашого Python віртуального середовища:

setx SECRET_KEY1 ************

1	setx SECRET_KEY1 ************

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

Якщо ж ви деплоїте вашу Django аплікацію на “платформа-як-сервіс” ресурси, тоді встановлення змінних середовища в кожному із випадків може відрізнятись. Для прикладу:

на Gondor.io: з допомогою команди: “$ gondor env:set SECRET_KEY1=*********”;
на Heroku: команда “$ heroku config:add SECRET_KEY1=*********”;
на dotCloud: команда “dotcloud env set SECRET_KEY1=*********”;

Після того, як встановили необхідні змінні середовища, їх можна витягнути з Python коду наступним чином:

>>> import os
>>> os.environ[" SECRET_KEY1"]

1 2	>>> import os >>> os.environ[" SECRET_KEY1"]

Таким чином, у всіх ваших модулях налаштувань на місцях із секретними даними, перебиваємо стрічки секретних значень на подібне присвоєння змінної:

FB_API_KEY = os.environ["FB_API_KEY"]

1	FB_API_KEY = os.environ["FB_API_KEY"]

На завершення даної секції ще одне покращення до процедури отримання змінної середовища, у випадку якщо змінна не встановлена і виникає помилка. Рекомендую скопіювати наступну функцію у свій модуль налаштувань base.py і користуватись нею для отримання змінних середовища:

# base.py

import os
from django.core.exceptions import ImproperlyConfigured

msg = "Set the %s environment variable"

def get_env_var(var_name):
    try: 
        return os.environ[var_name]
    except KeyError:
        error_msg = msg % var_name
        raise ImproperlyConfigured(error_msg)


# local.py
FB_API_KEY = get_env_var("FB_API_KEY")

# base.py

import os

from django.core.exceptions import ImproperlyConfigured

msg = "Set the %s environment variable"

def get_env_var(var_name):

try:

return os.environ[var_name]

except KeyError:

error_msg = msg % var_name

raise ImproperlyConfigured(error_msg)

# local.py

FB_API_KEY = get_env_var("FB_API_KEY")

Файли requirements.txt

Розподіливши налаштування проекту в окремі модулі доволі логічно буде зберігати список пакетів, на які залежить наш проект, не в одному файлі requirements.txt, а також у кількох різних файлах. Кожен окремий файл для окремого середовища.

Подібним чином створюємо директорію в корені репозиторію під назвою requirements:

Структура множинних файлів залежностей

У ній складаємо файли для локального розробницького середовища, для демо інстанса та для продакшина. Крім того, також маємо файл base.txt.

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

Наприклад, локальне середовище програміста матиме ряд девелоперських інструментів Django. На демо чи продакшині подібні пакети не лише не потрібні, але й шкідливі. Тому в local.txt можемо внести все те, що потрібно лише програмістові + запозичити усі основні пакети-залежності проекту із файлу base.txt:

# використовуємо пакети з файлу base.txt
-r base.txt

# девелоперські пакети
django-coverage=1.2.4
django-debug-toolbar=1.4
...

# використовуємо пакети з файлу base.txt

-r base.txt

# девелоперські пакети

django-coverage=1.2.4

django-debug-toolbar=1.4

...

Файл production.txt зазвичай використовуватиме залежності близькі до base.txt, то ж міститиме лише один рядок “-r base.txt”.

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

$ pip install -r requirements/local.txt

1	$ pip install -r requirements/local.txt

Фішка: якщо не знаєте, яким файлом напередодні скористались для інсталяції залежних пакетів, тоді скористайтесь командою freeze утиліти pip, щоб отримати список поточно встановлених пакетів і версій:

PowerShell

$ pip freeze --local

1

$ pip freeze --local

Шляхи в модулях налаштувань

На завершення даної статті розглянемо спосіб роботи із шляхами у налаштуваннях проекту.

Основна ідея – це уникати захардкоджених шляхів. Натомість використовувати відносні калькульовані шляхи до папок та файлів у вашому модулі налаштувань. Таким чином, без будь-яких змін, даними налаштуваннями зможуть користуватись усі члени розробницької команди.

Ось швидкий приклад із поясненнями, як ми це робимо у наших проектах на даний час. Стандартні змінні Django проекту:

# base.py модуль
from os import path

# будує шлях відносно поточної папки із налаштуваннями
here = lambda *x: path.join(path.abspath(path.dirname(__file__)), *x)

# корінь проекти знаходиться на два рівні вище
PROJECT_ROOT = here("..", "..")

# будує шлях відносно кореня проекту
root = lambda *x: path.join(path.abspath(PROJECT_ROOT), *x)

# медіа папку кладемо в корені проекту
MEDIA_ROOT = root("media")

# так само як і папку static
STATIC_ROOT = root("collected_static")

# можливі додаткові локації статичних ресурсів
STATICFILES_DIRS = (
    root("assets"),
)

# директорії із шаблонами
TEMPLATE_DIRS = (
    root("templates"),
)

# base.py модуль

from os import path

# будує шлях відносно поточної папки із налаштуваннями

here = lambda *x: path.join(path.abspath(path.dirname(__file__)), *x)

# корінь проекти знаходиться на два рівні вище

PROJECT_ROOT = here("..", "..")

# будує шлях відносно кореня проекту

root = lambda *x: path.join(path.abspath(PROJECT_ROOT), *x)

# медіа папку кладемо в корені проекту

MEDIA_ROOT = root("media")

# так само як і папку static

STATIC_ROOT = root("collected_static")

# можливі додаткові локації статичних ресурсів

STATICFILES_DIRS = (

root("assets"),

)

# директорії із шаблонами

TEMPLATE_DIRS = (

root("templates"),

)

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

# base.py модуль
from unipath import Path

PROJECT_DIR = Path(__file__).ancestor(3)
MEDIA_ROOT = PROJECT_DIR.child("media")
STATIC_ROOT = PROJECT_DIR.child("collected_static")
STATICFILES_DIRS = (
    PROJECT_DIR.child("assets"),
)
TEMPLATE_DIRS = (
    PROJECT_DIR.child("templates"),
)

# base.py модуль

from unipath import Path

PROJECT_DIR = Path(__file__).ancestor(3)

MEDIA_ROOT = PROJECT_DIR.child("media")

STATIC_ROOT = PROJECT_DIR.child("collected_static")

STATICFILES_DIRS = (

PROJECT_DIR.child("assets"),

)

TEMPLATE_DIRS = (

PROJECT_DIR.child("templates"),

)

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

Фішка: Якщо хочете побачити на скільки ваші налаштування проекту відрізняються від дефолтних, користуйтесь командою diffsettings скрипта manage.py.

Підсумуємо

Отже, маємо кілька основних правил, що допоможуть гнучкіше керувати налаштуваннями проекту:

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

На цьому все. У наступній статті даної серії поговоримо про кращі практики при роботі з базою даних та Django моделями.

А які фішки ви використовуєте в налаштуванні Django проектів?

Налаштування Django проекту

Це стаття із серії “Кращі практики розробки з Django”. Гляньте також інші статті із даної серії:

Основні принципи

Множинні модулі налаштувань Django проекту

Секретні дані

Файли requirements.txt

Шляхи в модулях налаштувань

Підсумуємо

Вам також може сподобатися:

Опублікувати коментар Скасувати відповідь

Привіт, Я Віталій Подоба!

Архів

Рубрики

Програміст Початківець - 10 кроків до вашої першої роботи (Безкоштовний Емейл Курс)

Програміст Початківець - 10 кроків до вашої першої роботи (Безкоштовний Емейл Курс)

Налаштування Django проекту

Це стаття із серії “Кращі практики розробки з Django”. Гляньте також інші статті із даної серії:

Основні принципи

Множинні модулі налаштувань Django проекту

Секретні дані

Файли requirements.txt

Шляхи в модулях налаштувань

Підсумуємо

Вам також може сподобатися:

Опублікувати коментар Скасувати відповідь

Будьмо дружніми!

Популярні Статті

Привіт, Я Віталій Подоба!

Архів

Рубрики

Теги

Програміст Початківець - 10 кроків до вашої першої роботи (Безкоштовний Емейл Курс)

Програміст Початківець - 10 кроків до вашої першої роботи (Безкоштовний Емейл Курс)