Django
Ustawienia

Ustawianie strefy czasowej

Możesz ustawić strefę czasową, która będzie używana przez Django w pliku settings.py . Przykłady:

TIME_ZONE = 'UTC'  # use this, whenever possible
TIME_ZONE = 'Europe/Berlin'
TIME_ZONE = 'Etc/GMT+1'

Oto lista prawidłowych stref czasowych

Podczas pracy w środowisku Windows należy ustawić tę samą strefę czasową co system .

Jeśli nie chcesz, aby Django używał datetime uwzględniających strefy czasowe:

USE_TZ = False

Najlepsze praktyki Django wymagają użycia UTC do przechowywania informacji w bazie danych:

Nawet jeśli witryna jest dostępna tylko w jednej strefie czasowej, nadal dobrą praktyką jest przechowywanie danych w UTC w bazie danych. Głównym powodem jest czas letni (DST). Wiele krajów ma system DST, w którym zegary są przesuwane wiosną do przodu, a jesienią do tyłu. Jeśli pracujesz w czasie lokalnym, możesz napotkać błędy dwa razy w roku, gdy nastąpi przejście.

https://docs.djangoproject.com/en/stable/topics/i18n/timezones/

Dostęp do ustawień

Po skonfigurowaniu wszystkich ustawień zechcesz użyć ich w kodzie. Aby to zrobić, dodaj następujący plik do swojego pliku:

from django.conf import settings

Następnie możesz uzyskać dostęp do swoich ustawień jako atrybutów modułu settings , na przykład:

if not settings.DEBUG:
    email_user(user, message)

Korzystanie z BASE_DIR w celu zapewnienia przenośności aplikacji

Nieodpowiednim pomysłem jest umieszczanie ścieżek kodu w aplikacji. Zawsze należy używać względnych adresów URL, aby kod mógł bezproblemowo działać na różnych komputerach. Najlepszym sposobem na skonfigurowanie tego jest zdefiniowanie takiej zmiennej

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

Następnie użyj tej zmiennej BASE_DIR , aby zdefiniować wszystkie pozostałe ustawienia.

TEMPLATE_PATH = os.path.join(BASE_DIR, "templates")
STATICFILES_DIRS = [
    os.path.join(BASE_DIR, "static"),

]

I tak dalej. Gwarantuje to, że możesz bez obaw przenosić swój kod na różne maszyny.

Jednak os.path jest nieco gadatliwy. Na przykład, jeśli twoim modułem ustawień jest project.settings.dev , będziesz musiał napisać:

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

Alternatywą jest użycie modułu unipath (który można zainstalować za pomocą pip install unipath ).

from unipath import Path

BASE_DIR = Path(__file__).ancestor(2)  # or ancestor(3) if using a submodule

TEMPLATE_PATH = BASE_DIR.child('templates')
STATICFILES_DIRS = [
    BASE_DIR.child('static'),
]

Używanie zmiennych środowiskowych do zarządzania ustawieniami na serwerach

Korzystanie ze zmiennych środowiskowych jest szeroko stosowanym sposobem ustawiania konfiguracji aplikacji w zależności od środowiska, jak stwierdzono w aplikacji Twelve-Factor .

Ponieważ konfiguracje mogą się zmieniać między środowiskami wdrażania, jest to bardzo interesujący sposób modyfikowania konfiguracji bez konieczności kopania kodu źródłowego aplikacji, a także utrzymywania tajemnic poza plikami aplikacji i repozytorium kodów źródłowych.

W Django główne ustawienia znajdują się w settings.py w folderze projektu. Ponieważ jest to prosty plik Pythona, możesz użyć modułu os Pythona ze standardowej biblioteki, aby uzyskać dostęp do środowiska (a nawet mieć odpowiednie ustawienia domyślne).

settings.py

import os

SECRET_KEY = os.environ.get('APP_SECRET_KEY', 'unsafe-secret-key')

DEBUG = bool(os.environ.get('DJANGO_DEBUG', True) == 'False')

ALLOWED_HOSTS = os.environ.get('DJANGO_ALLOWED_HOSTS', '').split()

DATABASES = {
    'default': {
        'ENGINE': os.environ.get('APP_DB_ENGINE', 'django.db.backends.sqlite3'),
        'NAME': os.environ.get('DB_NAME', 'db.sqlite'),    
        'USER': os.environ.get('DB_USER', ''),
        'PASSWORD': os.environ.get('DB_PASSWORD', ''),
        'HOST': os.environ.get('DB_HOST', None),
        'PORT': os.environ.get('DB_PORT', None),
        'CONN_MAX_AGE': 600,
    }
}

Za pomocą Django możesz zmienić technologię bazy danych, abyś mógł używać sqlite3 na swoim komputerze programistycznym (i powinno to być rozsądne ustawienie domyślne przy uruchamianiu systemu kontroli źródła). Chociaż jest to możliwe, nie jest wskazane:

Usługi tworzenia kopii zapasowych, takie jak baza danych aplikacji, system kolejkowania lub pamięć podręczna, to jeden z obszarów, w którym ważna jest parzystość deweloperów / prod. ( Aplikacja Twelve-Factor - parzystość deweloperów / prod )

Aby użyć parametru DATABASE_URL do połączenia z bazą danych, spójrz na powiązany przykład .

Korzystanie z wielu ustawień

Domyślny układ projektu Django tworzy pojedynczy settings.py . Często przydaje się to w następujący sposób:

myprojectroot/
    myproject/
        __init__.py
        settings/
            __init__.py
            base.py
            dev.py
            prod.py
            tests.py

Umożliwia to pracę z różnymi ustawieniami, zależnie od tego, czy jesteś w fazie rozwoju, produkcji, testów czy cokolwiek innego.

Po przejściu z domyślnego układu do tego układu oryginalny settings.py settings/base.py się na settings/base.py Gdy co drugi podmoduł „ settings/base.py ” settings/base.py , zaczynając from .base import * . Na przykład oto, jak mogą wyglądać settings/dev.py :

# -*- coding: utf-8 -*-
from .base import *  # noqa

DEBUG = True
INSTALLED_APPS.extend([
    'debug_toolbar',
])
EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'
INTERNAL_IPS = ['192.168.0.51', '192.168.0.69']

Alternatywa nr 1

Aby komendy django-admin działały poprawnie, musisz ustawić DJANGO_SETTINGS_MODULE środowiskową DJANGO_SETTINGS_MODULE (domyślnie myproject.settings ). W fazie rozwoju ustawisz na myproject.settings.dev . W produkcji ustawisz go na myproject.settings.prod . Jeśli używasz virtualenv, najlepiej jest ustawić go w skrypcie postactivate :

#!/bin/sh
export PYTHONPATH="/home/me/django_projects/myproject:$VIRTUAL_ENV/lib/python3.4"
export DJANGO_SETTINGS_MODULE="myproject.settings.dev"

Jeśli chcesz użyć modułu ustawień, który nie jest wskazany przez DJANGO_SETTINGS_MODULE , możesz użyć opcji --settings django-admin :

django-admin test --settings=myproject.settings.tests

Alternatywa nr 2

Jeśli chcesz pozostawić DJANGO_SETTINGS_MODULE w domyślnej konfiguracji ( myproject.settings ), możesz po prostu powiedzieć modułowi settings , którą konfigurację załadować, umieszczając import w pliku __init__.py .

W powyższym przykładzie ten sam wynik można osiągnąć, ustawiając __init__.py na:

from .dev import *

Korzystanie z wielu plików wymagań

Każdy plik wymagań powinien pasować do nazwy plików ustawień. Przeczytaj Używanie wielu ustawień, aby uzyskać więcej informacji.

Struktura

djangoproject
├── config
│   ├── __init__.py
│   ├── requirements
│   │   ├── base.txt
│   │   ├── dev.txt
│   │   ├── test.txt
│   │   └── prod.txt
│   └── settings
└── manage.py

W pliku base.txt umieść zależności używane we wszystkich środowiskach.

# base.txt
Django==1.8.0
psycopg2==2.6.1
jinja2==2.8

A we wszystkich innych plikach -r base.txt podstawowe zależności do -r base.txt i dodaj określone zależności potrzebne w bieżącym środowisku.

# dev.txt
-r base.txt # includes all dependencies in `base.txt`

# specific dependencies only used in dev env
django-queryinspect==0.1.0

# test.txt
-r base.txt # includes all dependencies in `base.txt`

# specific dependencies only used in test env
nose==1.3.7
django-nose==1.4

# prod.txt
-r base.txt # includes all dependencies in `base.txt`

# specific dependencies only used in production env
django-queryinspect==0.1.0
gunicorn==19.3.0
django-storages-redux==1.3
boto==2.38.0

Wreszcie, aby zainstalować zależności. Przykład na dev env: pip install -r config/requirements/dev.txt

Ukrywanie tajnych danych za pomocą pliku JSON

Podczas korzystania z VCS, takich jak Git lub SVN, istnieją pewne tajne dane, których nigdy nie należy wersjonować (niezależnie od tego, czy repozytorium jest publiczne, czy prywatne).

Wśród tych danych znajdziesz ustawienie SECRET_KEY i hasło do bazy danych.

Częstą praktyką ukrywania tych ustawień przed kontrolą wersji jest tworzenie pliku secrets.json w katalogu głównym projektu ( dzięki „ Two Scoops of Django ” za pomysł ):

{
    "SECRET_KEY": "N4HE:AMk:.Ader5354DR453TH8SHTQr",
    "DB_PASSWORD": "v3ry53cr3t"
}

I dodaj go do swojej listy ignorowanych ( .gitignore dla git):

*.py[co]
*.sw[po]
*~
/secrets.json

Następnie dodaj następującą funkcję do modułu settings :

import json
import os
from django.core.exceptions import ImproperlyConfigured

with open(os.path.join(BASE_DIR, 'secrets.json')) as secrets_file:
    secrets = json.load(secrets_file)

def get_secret(setting, secrets=secrets):
    """Get secret setting or fail with ImproperlyConfigured"""
    try:
        return secrets[setting]
    except KeyError:
        raise ImproperlyConfigured("Set the {} setting".format(setting))

Następnie wypełnij ustawienia w ten sposób:

SECRET_KEY = get_secret('SECRET_KEY')
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgres',
        'NAME': 'db_name',
        'USER': 'username',
        'PASSWORD': get_secret('DB_PASSWORD'),
    },
}

Kredyty: Dwie miarki Django: najlepsze praktyki dla Django 1.8, autor: Daniel Roy Greenfeld i Audrey RoyGreenfeld. Prawa autorskie 2015 Two Scoops Press (ISBN 978-0981467344)

Korzystanie z DATABASE_URL ze środowiska

W witrynach PaaS, takich jak Heroku, zwykle informacje o bazie danych są odbierane jako jedna zmienna środowiskowa z jednym adresem URL, zamiast kilku parametrów (host, port, użytkownik, hasło ...).

Istnieje moduł dj_database_url który automatycznie wyodrębnia zmienną środowiskową DATABASE_URL do słownika Python odpowiedniego do wstrzykiwania ustawień bazy danych w Django.

Stosowanie:

import dj_database_url

if os.environ.get('DATABASE_URL'):
    DATABASES['default'] =
        dj_database_url.config(default=os.environ['DATABASE_URL'])