Рубрики
Без рубрики

Двенадцатифакторная методология, применяемая к приложению Django

В последние несколько недель я участвовал в горстке инженера по надежности DevOps/сайта (SRE) Inter … с меткой Python, Django, WebDev, DevOps.

В последние несколько недель я участвовал в нескольких интервью инженера DevOps/Site Ingencyer (SRE). Несколько интервьюеров просили руководящие принципы, настраивающие и эксплуатирующие облачный родной Приложения. Мой разум сразу же идет в Двенадцатифакторная методология приложения , первоначально созданный людьми, которые построили Хероку – Одна из первых общедоступных платформ в качестве услуги (PAAS).

В совокупности точки служат абстрактным приложениям из инфраструктуры, на которой они запускаются, прокладывая путь для конфигурации, масштабируемости и надежности. Чтобы проиллюстрировать, как это работает на практике, я настроил приложение Django и использую его, чтобы объяснить, как применяется каждая 12 -факторная точка. Надеюсь, вы найдете это полезным!

  • Кодовая база
  • Зависимости
  • Конфигурация
  • Служба поддержки
  • Строить, выпустить, запустить
  • Процессы
  • Привязка порта
  • Параллелизм
  • Одноразовая способность
  • Dev/Prod Capity
  • Журналы
  • Административные процессы

Примечание : Фрагменты кода в следующих разделах не цепляются вместе идеально. Фрагменты существуют в первую очередь, чтобы помочь сообщить, что происходит таким образом, что может только код.

Кодовая база

A кодовая база является полным источником материала данной программы или приложения. Его структура будет варьироваться в зависимости от технологии, но для приложения Django под названием mysite создан с Django-admin startProject , похоже, так:

$ git init
Initialized empty Git repository in /home/hector/Projects/django-blog/.git/
$ git add .
$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached ..." to unstage)
        new file: .gitignore
        new file: Pipfile
        new file: Pipfile.lock
        new file: mysite/manage.py
        new file: mysite/mysite/ __init__.py
        new file: mysite/mysite/asgi.py
        new file: mysite/mysite/settings.py
        new file: mysite/mysite/urls.py
        new file: mysite/mysite/wsgi.py
        new file: setup.cfg

Отлично – у нас есть сами кодовая база ! Мы постепенно рассмотрим преобразование кодовые базы в развертывает В следующих разделах.

Зависимости

Приложения имеют зависимости Анкет 12 Фактор хочет, чтобы мы явно объявили эти зависимости, чтобы их можно было воспроизводить. Первый шаг к достижению этого происходит с Pipfile Анкет Он был создан инструментом управления зависимостями Python под названием Pipenv После выполнения следующих команд:

pipenv install django~=3.1
pipenv install black --dev --pre # --pre is needed because of black's versioning scheme
pipenv install flake8~=3.8 --dev
pipenv install isort~=5.7 --dev

Внутренняя часть Pipfile написан в Очевидный минимальный язык Тома (Toml) и содержит манифест зависимостей с питоном, необходимыми для проекта:

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
django = "~=3.1"

[dev-packages]
black = "*"
flake8 = "~=3.8"
isort = "~=5.7"

[requires]
python_version = "3.8"

[pipenv]
allow_prereleases = true

В настоящее время мы стараемся сделать это на шаг дальше, захватив все Необходимые зависимости приложения в изображении контейнера. В большинстве случаев стремление к созданию изображения контейнера приводит к использованию Docker , что подразумевает добавление Dockerfile :

FROM python:3.8

ENV PYTHONUNBUFFERED=1

RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app

COPY ./Pipfile* .
RUN pip install pipenv
RUN pipenv install --system --deploy --ignore-pipfile
COPY ./mysite .

ENTRYPOINT ["python", "manage.py"]

Чтобы убедиться, что все в рабочем состоянии, мы можем создать и проверить изображение контейнера, используя следующие команды. Здесь Runserver Аргумент запускает сервер разработки Django:

$ docker build -t mysite .
$ docker run --rm mysite runserver
Watching for file changes with StatReloader
Performing system checks...

System check identified no issues (0 silenced).

You have 18 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions.
Run 'python manage.py migrate' to apply them.
March 01, 2021 - 20:45:33
Django version 3.1.7, using settings 'mysite.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

Выглядит неплохо! Теперь у нас есть все, что нужно, чтобы раскрутить приложение, захваченное в контейнере. Кроме того, у нас есть все связанные инструкции по созданию изображения, определенного декларативным способом (например, Pipfile , Dockerfile )

Конфигурация

В двенадцатифакторном мире, Конфигурация определяется как все, что может варьироваться между развертывает из кодовая база . Это позволяет один кодовая база быть развернутым в разных средах без настройки. Некоторые примеры Конфигурация включают:

  • Строки соединения с базой данных, Memcached и другими службами поддержки.
  • Учетные данные для внешних служб (например, Amazon S3, Google Maps и т. Д.).
  • Информация о целевой среде (например, Постановка против Производство )

После того, как мы определили конфигурацию для нашего приложения, нам нужно работать над тем, чтобы сделать ее расходным путем через переменные среды Анкет В приведенном ниже примере мы сосредоточены на изменении пути Джанго СЕКРЕТНЫЙ КЛЮЧ и ОТЛАЖИВАТЬ Настройки установлены в настройки.py (Дом для всех настроек конфигурации Django).

diff --git a/mysite/mysite/settings.py b/mysite/mysite/settings.py
index d541c62..3a99d45 100644
-------- a/mysite/mysite/settings.py
+++ b/mysite/mysite/settings.py
@@ -9,7 +9,7 @@ https://docs.djangoproject.com/en/3.1/topics/settings/
 For the full list of settings and their values, see
 https://docs.djangoproject.com/en/3.1/ref/settings/
 """
-
+import os
 from pathlib import Path

 # Build paths inside the project like this: BASE_DIR / 'subdir'.
@@ -20,10 +20,10 @@ BASE_DIR = Path( __file__ ).resolve().parent.parent
 # See https://docs.djangoproject.com/en/3.1/howto/deployment/checklist/

 # SECURITY WARNING: keep the secret key used in production secret!
-SECRET_KEY = "#v5hnkypk39qex@9zb2j2as3n9f7)jgvz05*9t&0@2y$kx$7lw"
+SECRET_KEY = os.getenv("DJANGO_SECRET_KEY", "secret")

 # SECURITY WARNING: don't run with debug turned on in production!
-DEBUG = True
+DEBUG = os.getenv("DJANGO_ENV") == "Development"

 ALLOWED_HOSTS = []

Здесь мы использовали стандартную библиотеку Python ОС Модуль, чтобы помочь нам прочитать конфигурацию из среды. Теперь две настройки могут быть легче перенастроены через развертывает Анкет

Чтобы доказать, что это работает, мы можем изменить среду с помощью -e флаг Docker Run :

$ docker build -t mysite .
$ docker run --rm \
    -e DJANGO_SECRET_KEY="dev-secret" \
    -e DJANGO_ENV="Development" \
    mysite runserver
Watching for file changes with StatReloader
Performing system checks...

System check identified no issues (0 silenced).

You have 18 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions.
Run 'python manage.py migrate' to apply them.
March 01, 2021 - 21:25:57
Django version 3.1.7, using settings 'mysite.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
^C%

ХОРОШО. Все продолжало работать так, как это работало раньше. Теперь посмотрим, что произойдет, если мы попытаемся сделать Django_env = производство , что вызовет Отладка Настройка для оценки в Ложный :

$ docker run --rm \
    -e DJANGO_SECRET_KEY="prod-secret" \
    -e DJANGO_ENV="Production" \
    mysite runserver
CommandError: You must set settings.ALLOWED_HOSTS if DEBUG is False.

Ага! Это CommandError выглядит зловещим, но это индикатор, что наше изменение Django_env успешно пробился в среду выполнения приложения!

Служба поддержки

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

В качестве примера, скажем, у вас есть экземпляр базы данных PostgreSQL, работающий на вашей рабочей станции, который подключен к вашему приложению для постоянных данных. Позже, когда приходит время развертывания в производстве, тот же подход к настройке локального экземпляра PostgreSQL должен работать, когда он будет заменен на экземпляр Amazon Relational Database Service (RDS).

Чтобы достичь этого с помощью Django, нам нужно изменить способ настроения подключения к базе данных. Это происходит через Базы данных Словарь в настройки.py :

diff --git a/mysite/mysite/settings.py b/mysite/mysite/settings.py
index 3a99d45..fcff52a 100644
-------- a/mysite/mysite/settings.py
+++ b/mysite/mysite/settings.py
@@ -75,8 +75,12 @@ WSGI_APPLICATION = "mysite.wsgi.application"

 DATABASES = {
     "default": {
- "ENGINE": "django.db.backends.sqlite3",
- "NAME": BASE_DIR / "db.sqlite3",
+ "ENGINE": "django.db.backends.postgresql",
+ "NAME": os.getenv("POSTGRES_DB"),
+ "USER": os.getenv("POSTGRES_USER"),
+ "PASSWORD": os.getenv("POSTGRES_PASSWORD"),
+ "HOST": os.getenv("POSTGRES_HOST"),
+ "PORT": os.getenv("POSTGRES_PORT"),
     }
 }

Здесь мы изменили Базы данных так что все необходимые настройки для дефолт База данных извлекаются из окружающей среды. Теперь не имеет значения, запускается ли приложение с ХОЗЯИН равна Localhost или MySite.123456789012.us-East-1.rds.amazonaws.com Анкет В любом случае, приложение должно быть в состоянии успешно подключиться к базе данных, используя настройки, найденные в среде.

Строить, выпустить, запустить

В Зависимости Раздел мы создали строить в виде изображения контейнера. Но нам также нужна уникальная ярлыка для идентификации и дифференциации между версиями изображения контейнера. Уникальность может быть в форме временной метки или увеличения числа, но лично мне нравится использовать ревизии GIT. Ниже приведен пример, который использует текущую ревизию GIT для помещения изображения контейнера:

$ # Get a reference to the latest commit of the current
$ # branch and make it short (only 7 characters long).
$ export GIT_COMMIT="$(git rev-parse --short HEAD)"
$ docker build -t "mysite:$GIT_COMMIT" .
$ docker images | grep mysite
mysite e87b8c4 4f3dc2772c57 2 minutes ago 978MB

Как вы можете видеть из вывода, ссылка MySite: E87B8C4 уникален для изображения контейнера, который мы построили. Если мы внесем дополнительные изменения в кодовая база и посвятить их базовому репозиторию GIT, следуя этим же шагам приведут к новому контейнеру с новой уникальной ссылкой.

Далее нам нужно объединить изображение контейнера сборка Выше с соответствующим набором Конфигурация Чтобы произвести Выпуск Анкет Здесь мы будем использовать легкий Docker Compose Файл конфигурации для описания соединения между двумя ( сборки и выбросы ) декларативным образом. В производственной системе вы, вероятно, сделаете что -то подобное, используя Kubernetes развертывание или Amazon ECS Определение задачи :

version: "3"
services:
  web:
    image: mysite:e87b8c4
    environment:
      - POSTGRES_HOST=mysite.123456789012.us-east-1.rds.amazonaws.com
      - POSTGRES_PORT=5432
      - POSTGRES_USER=mysite
      - POSTGRES_PASSWORD=mysite
      - POSTGRES_DB=mysite
      - DJANGO_ENV=Staging
      - DJANGO_SECRET_KEY=staging-secret
    command:
      - runserver
      - "0.0.0.0:8000"
    ports:
      - "8000:8000"

Этот бит Docker сочиняет конфигурацию связывает вместе MySite: E87B8C4 сборка с набором конкретной среды Конфигурация Чтобы произвести Выпуск Анкет Если изображение контейнера и Docker Compose Fronippet доступны на одном хосте, то приложение готово к немедленному выполнению на этом хосте.

Наконец, у нас есть запустить сцена. Для Docker Compose это так же просто, как использование Docker-Compose Up запустить Интернет оказание услуг. Для более сложной системы оркестровки контейнеров, вероятно, будет задействовано еще несколько шагов:

  • Изображение контейнера опубликовано в центрально доступном реестре контейнеров.
  • Манифест развертывания представлен для оценки в планировщик контейнера.
  • Compute подключен к планировщику контейнера с адекватными ресурсами для размещения экземпляров приложения.

Процессы

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

Однако иногда целые компоненты приложения должны быть динамически построены, например, связанные с ним CSS и JavaScript. Чтобы быть по -настоящему без гражданства, мы хотим генерировать эти компоненты во время строить Фаза и запечатлеть их в изображении контейнера.

У Джанго есть Несколько встроенных механизмов Для обработки статических активов, но я предпочитаю использовать стороннюю библиотеку с именем Отбелить Анкет В первую очередь, потому что это помогает упаковать как приложение, так и его поддерживающие статические активы вместе, что позволяет думать о развернуть как атомная операция.

После установки отбеливания с использованием Pipenv с командой, аналогичной той, которую мы использовали в Зависимости Чтобы установить Django, нам необходимо настроить приложение Django для использования Whitenoise для управления статическим активом. Здесь мы вводим отбеливание в Django Insted_apps и Промежуточное программное обеспечение Иерархия, чтобы захватить статическое управление активами в средах разработки и не развития:

diff --git a/mysite/mysite/settings.py b/mysite/mysite/settings.py
index 216452b..f4e32c6 100644
-------- a/mysite/mysite/settings.py
+++ b/mysite/mysite/settings.py
@@ -31,6 +31,7 @@ ALLOWED_HOSTS = []
 # Application definition

 INSTALLED_APPS = [
+ "whitenoise.runserver_nostatic",
     "django.contrib.admin",
     "django.contrib.auth",
     "django.contrib.contenttypes",
@@ -41,6 +42,7 @@ INSTALLED_APPS = [

 MIDDLEWARE = [
     "django.middleware.security.SecurityMiddleware",
+ "whitenoise.middleware.WhiteNoiseMiddleware",
     "django.contrib.sessions.middleware.SessionMiddleware",
     "django.middleware.common.CommonMiddleware",
     "django.middleware.csrf.CsrfViewMiddleware",
@@ -122,3 +124,7 @@ USE_TZ = True
 # https://docs.djangoproject.com/en/3.1/howto/static-files/

 STATIC_URL = "/static/"
+
+STATIC_ROOT = "/static"
+
+STATICFILES_STORAGE = "whitenoise.storage.CompressedManifestStaticFilesStorage"

Две настройки внизу ( static_root и Staticfiles_storage ) Скажите Django, где хранить собранные файлы в файловой системе изображения контейнера и какие операции предварительной обработки должны применяться.

Затем нам необходимо обеспечить, чтобы Django предварительно обработали все статические активы как часть процесса сборки изображения контейнера. Для Джанго это означает добавление вызова CollectStatic командовать инструкциями по сборке изображения контейнера:

diff --git a/Dockerfile b/Dockerfile
index 4653278..6420680 100644
-------- a/Dockerfile
+++ b/Dockerfile
@@ -10,4 +10,6 @@ RUN pip install pipenv
 RUN pipenv install --system --deploy --ignore-pipfile
 COPY ./mysite .

+RUN python manage.py collectstatic --no-input
+
 ENTRYPOINT ["python", "manage.py"]

Без гражданства достигнута!

Привязка порта

Теперь, когда у нас есть исходный код приложения, зависимости и поддерживающие статические активы внутри изображения контейнера, нам нужен способ разоблачить его полностью автономным образом. Поскольку это веб -приложение, наша цель состоит в том, чтобы использовать протокол HTTP вместо API -интерфейсов более низкого уровня, таких как CGI, FastCGI, сервлеты и т. Д.

Мы видели, как наше приложение связано с портом через HTTP уже несколько раз через Docker Run Призывы выше, но все они использовали сервер приложений HTTP-сервера разработки (например, runserver ). Как мы добиваемся чего-то подобного по производству?

Введите Онломщик а также Uvicorn Анкет Gunicorn-это производственный сервер приложений Python для систем UNIX, а Uvicorn обеспечивает реализацию работника надзора с помощью Асинхронный интерфейс шлюза сервера (ASGI) совместимость.

После установки овиновника и Uvicorn с использованием Pipenv Установка , нам нужно настроить конфигурацию Docker Compose из Строить, выпустить, запустить Использовать овиновщик как точка входа . Мы также добавляем несколько вариантов командной строки, чтобы обеспечить использование API ASGI ASGI (между пиндоном и джанго) вместе с внедрением работника Uvicorn:

diff --git a/docker-compose.yml b/docker-compose.yml
index f5f693d..bac885d 100644
-------- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -20,8 +20,12 @@ services:
     build:
       context: .
       dockerfile: Dockerfile
+ entrypoint: gunicorn
     command:
- - runserver
- - "0.0.0.0:8000"
+ - "mysite.asgi:application"
+ - "-b 0.0.0.0:8000"
+ - "-k uvicorn.workers.UvicornWorker"

После всех этих изменений Docker Compose должен быть в состоянии поднять службу, связанную с портом 8000 Использование стрелкового корня:

$ docker-compose up web
Starting django-blog_web_1 ... done
Attaching to django-blog_web_1
web_1 | [2021-03-06 19:57:43 +0000] [1] [INFO] Starting gunicorn 20.0.4
web_1 | [2021-03-06 19:57:43 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
web_1 | [2021-03-06 19:57:43 +0000] [1] [INFO] Using worker: uvicorn.workers.UvicornWorker
web_1 | [2021-03-06 19:57:43 +0000] [8] [INFO] Booting worker with pid: 8
web_1 | [2021-03-06 19:57:43 +0000] [8] [INFO] Started server process [8]
web_1 | [2021-03-06 19:57:43 +0000] [8] [INFO] Waiting for application startup.
web_1 | [2021-03-06 19:57:43 +0000] [8] [INFO] ASGI 'lifespan' protocol appears unsupported.
web_1 | [2021-03-06 19:57:43 +0000] [8] [INFO] Application startup complete.

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

$ http localhost:8000/admin/
HTTP/1.1 302 Found
cache-control: max-age=0, no-cache, no-store, must-revalidate, private
content-length: 0
content-type: text/html charset=utf-8
date: Sat, 06 Mar 2021 19:59:36 GMT
expires: Sat, 06 Mar 2021 19:59:36 GMT
location: /admin/login/?next=/admin/
referrer-policy: same-origin
server: uvicorn
vary: Cookie
x-content-type-options: nosniff
x-frame-options: DENY

Оно живое!

Параллелизм

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

Указание разных Типы процессов Также не может быть сделано с оружием. Обычно это более тесно связано с использованием двигателя оркестровки контейнера. Позже в Dev/Prod Capity Мы увидим конфигурацию Docker Compose с обоими A база данных и Интернет Тип процесса. В рамках более ориентированной на производственную систему оркестровки контейнеров, такой как Kubernetes, вы достигнете чего-то подобного, создав отдельные наборы стручки – один для каждого Тип процесса Чтобы обеспечить независимое масштабирование.

Одноразовая способность

В облачных средах, приложение Распореотильность важно, потому что это увеличивает ловкость во время выпусков, масштабирования событий и сбоев. Приложение показано Распореотильность Когда он правильно обрабатывает определенные типы асинхронных уведомлений, называемых сигналы Анкет Сигналы помогают местным наблюдательным услугам (например, systemd и Кубелет ) Управляйте жизненным циклом приложения снаружи.

Обиличный зал встроен встроенную поддержку обработка сигнала Анкет Если вы используете его в качестве сервера приложений, он автоматически обрабатывает сигналы, такие как Сигмир облегчить изящное закрытие заявления.

Dev/Prod Capity

Конфигурация позволяет один сборка из кодовая база работать на местном уровне, в постановке и в производстве. Использование того, что для поддержания паритета в разных средах предотвращается несовместимость, не возникает по мере развития программного обеспечения. Это приводит к более высокой уверенности в том, что приложение будет функционировать так же, как и в производстве, как и локально.

Тем не менее, поддержание развития и производственного паритета является постоянной проблемой. Так же, как скорость и безопасность, вы должны постоянно думать об этом, или вы теряете ее.

В настоящее время поддержка операционной системы для ресурсов размещения имен посредством контейнеризации, наряду с инструментами более высокого уровня, такими как Docker и Docker Compose, имеют большое значение для облегчения достижения этого преследования. В качестве примера, см. Следующий файл конфигурации Docker Compose:

version: "3"
services:
  database:
    image: postgres:12.6
    environment:
      - POSTGRES_USER=mysite
      - POSTGRES_PASSWORD=mysite
      - POSTGRES_DB=mysite

  web:
    image: mysite
    environment:
      - POSTGRES_HOST=database
      - POSTGRES_PORT=5432
      - POSTGRES_USER=mysite
      - POSTGRES_PASSWORD=mysite
      - POSTGRES_DB=mysite
      - DJANGO_ENV=Development
      - DJANGO_SECRET_KEY=secret
      - DJANGO_LOG_LEVEL=DEBUG
    build:
      context: .
      dockerfile: Dockerfile
    entrypoint: gunicorn
    command:
      - "mysite.asgi:application"
      - "-b 0.0.0.0:8000"
      - "-k uvicorn.workers.UvicornWorker"
    ports:
      - "8000:8000"

В этом относительно небольшом файле мы определили все услуги, необходимые для запуска нашего приложения локально. Каждая служба ( база данных и Интернет ) запустить как отдельные процессы в своих собственных контейнерах, но объединяются в сеть. С точки зрения нашего приложения Django, эта настройка отличается минимально от истинной настройки оркестровки контейнеров.

Журналы

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

Джанго использует встроенный Python регистрация Модуль для выполнения системного регистрации, что позволяет его настраивать несколько довольно сложными способами. Тем не менее, все, что мы хотим, – это то, что Джанго зарегистрировал все как поток Стандартно. Мы можем сделать это, указав пользовательский словарь конфигурации журнала в настройки.py это похоже на:

LOGGING = {
    "version": 1,
    "disable_existing_loggers": False,
    "handlers": {
        "console": {
            "class": "logging.StreamHandler",
        },
    },
    "root": {
        "handlers": ["console"],
        "level": "WARNING",
    },
    "loggers": {
        "django": {
            "handlers": ["console"],
            "level": "WARNING",
            "propagate": False,
        },
    },
}

Это настраивает родительский корневой регистратор для отправки сообщений с помощью Предупреждение Уровень и выше до обработчика консоли (например, стандартный). Он также имеет поддержку для настройки уровней журнала Django по умолчанию через Django_log_level переменная среды. Подобный динамический переопределение может быть чрезвычайно полезным при устранении неполадок, потому что это позволяет изменять настройки ведения журнала, не требуя нового Выпуск Анкет

Административные процессы

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

Большинство вспомогательных административных задач Django, такие как применение миграции базы данных, отправка тестовых электронных писем и добавление пользователей, уже можно выполнять в качестве одноразовых процессов. Кроме того, Django предоставляет Надежная структура Для добавления дополнительных, которые относятся к вашему приложению (например, переключающие флаги функций, оркестр импорт данных и т. Д.).

Например, мы можем применить выдающиеся миграции базы данных (должно быть некоторые для недавно инициализированного проекта Django) со встроенным мигрировать Команда:

$ docker-compose run --rm --entrypoint "python manage.py" web migrate
Creating django-blog_web_run ... done
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying auth.0012_alter_user_first_name_max_length... OK
  Applying sessions.0001_initial... OK

Здесь мы динамически переопределяем ранее упомянутую конфигурацию Docker Compose с -Entrypoint установить в Python Manage.py вместо Онломщик Анкет Мы также указываем, что мы хотим мигрировать подкоманда будет запущен. Это выполнение приводит к серии межконтатейлеров, которые обеспечивают совместимость нашей схемы базы данных с текущим состоянием модели данных Джанго.

Вот и все! Независимо от того, знали ли вы о 12 -факторной методологии до или нет, я надеюсь, что видение ее применяется к приложению Django, позволяет вам легче интегрировать ее в любую веб -структуру, которую вы используете. Пусть это приведет к более настраиваемым, масштабируемым и надежным приложениям. Аминь Анкет

Благодаря Дэйв Конопка Для предоставления вдумчивых отзывов о моих проектах этого поста.

Оригинал: “https://dev.to/hector/twelve-factor-methodology-applied-to-a-django-app-451g”

Читайте ещё по теме: