Статьи

Джанго в производстве — часть 1 — стек

Декабрь 16, 2018

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

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

Gunicorn

Веб-приложения на основе Python традиционно запускались под Apache с использованием таких модулей, как mod_python или mod_wsgi. Апач, однако, может быть своего рода ресурсом, особенно на виртуальных серверах, которые часто имеют ограниченную память. Кроме того, как я подробно расскажу позже в этой серии, частое развертывание кода в размещенном на Apache приложении может быть проблематичным. Новое решение в порядке.

Для нас, «крутых ребят», есть большой выбор веб-серверов на основе Python, многие из которых проверены в этом детальном (хотя и немного старом) тесте Николаса Пиеля .

Gunicorn предлагает супер простую конфигурацию, чрезвычайно малую площадь, и это чистый Python — так что вы можете установить его с быстрой установкой gunicorn.

Обслуживание вашего приложения

Запуск сервера Gunicorn не может быть проще. По своей природе похож на сервер разработки Django, вы просто запускаете python manage.py run_gunicorn из директории вашего проекта. В производстве, однако, есть еще лучший метод.

Gunicorn устанавливает исполняемый скрипт в вашу среду, который называется gunicorn_django. Чтобы использовать его, вы указываете, какой модуль настроек использовать в командной строке: gunicorn_django path / to / project / settings. Мы можем использовать это для обслуживания приложения из системы управления процессами, такой как Supervisor.

Руководитель

На рабочем сервере приложение должно запускаться и останавливаться в операционной системе. Чтобы достичь этого, обычно требуется система управления процессом (особенно для демонов, которые не выполняют эту работу сами, как у Gunicorn). Supervisor является особенно хорошим примером и довольно прост в настройке. В Ubuntu установите его с помощью sudo apt-get install supervisor. Затем поместите файл конфигурации в /etc/supervisor/conf.d/app_name.conf с необходимыми параметрами. Пример конфигурации, показанный ниже, показывает, как Gunicorn может обслуживать приложение Django под пользователем www-data из собственного virtualenv и сохранять все свои выходные данные в файле журнала. Сервер также запускается автоматически и перезапускается в случае сбоя.

[program:app_name]
command=/path/to/env/bin/gunicorn_django app_name/settings
directory=/path/to/app/
user=www-data
autostart=true
autorestart=true
stdout_logfile=/path/to/app/django_logs/supervisord.log
redirect_stderr=true

Nginx

Из-за простоты Gunicorn, он не предназначен для показа миру как «голый» сервер. Вместо этого рекомендуется размещать обратный прокси-сервер, который выполняет непосредственную работу с клиентом (браузером).

Это связано с тем, как используются рабочие процессы, поэтому (возможно, намеренно) медленный клиент может легко выполнить атаку типа «отказ в обслуживании» (DoS), которая в итоге завершит работу всего приложения. Для более подробного объяснения см. Страницу развертывания в документации Gunicorn.

Как это бывает, nginx отлично работает как обратный прокси. Он также чрезвычайно быстрый, стабильный и простой в настройке. Следующая конфигурация настраивает nginx для обслуживания приложения, работающего на порту 8000 (по умолчанию для Gunicorn):

upstream app_server {
    server localhost:8000;
}

server {
    listen          80;
    client_max_body_size    4G;
    keepalive_timeout       5;

    access_log  /var/log/nginx/app_name.access.log;

    location /static/ {
        alias   /path/to/app/staticfiles/;
    }

    location / {
        proxy_pass          http://app_server;
        proxy_redirect      off;
        proxy_set_header    Host            $host;
        proxy_set_header    X-Real-IP       $remote_addr;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Вы также могли заметить, что эта конфигурация обслуживает статический носитель из каталога, называемого staticfiles, внутри папки приложения. Я бы порекомендовал, чтобы приложение Django contrib (с тем же именем) использовалось для управления статическим носителем для проекта — и это легко сделать, выполнив python manage.py collectstatic на сервере.

MySQL

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

Миграция базы данных

При развертывании кода на сервере приложений часто бывает необходимо выполнить миграцию базы данных. В этом случае Юг — идеальный инструмент для работы. Кроме того, соответствующие библиотеки должны присутствовать на сервере для вашей конкретной базы данных. Для MySQL это устанавливается из pip как модуль с именем mysql-python.

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

В следующем посте этой серии я буду рассказывать о выполнении длительных фоновых задач с помощью Celery .


Источник: http://www.robgolding.com/blog/2011/11/12/django-in-production-part-1—the-stack/

39
Share: