Запуск Web-приложений Django в Production-режиме (UWSGI/Nginx)

Django-приложения довольно сильно отличаются от php-приложений как структурой проекта, так и методом запуска.  Django-приложения по методу запуска больше похожи на Java, чем на PHP и классические ASP-проекты. Сегодня мы будем строить классическую связку из python-приложения и web-сервера Nginx обслуживающего реверс-проксирование запросов к приложению и предоставление файлов из каталогов media и static. LXC-изоляция в моем случае используется для поддержания python-окружения проекта и именно таким способом я предпочитаю изолировать проекты, а виртуальное окружение я предпочитаю не использовать, так как пару раз уже были проблемы при переносе Django-проектов.

 
 
Логотип GITA-DEV

Автор: Черноусов Антон aka Gita-Dev
Опубликовано: 19 Фев 2018 (последние правки 1 месяц, 1 неделя)

aptitude git install postgres ubuntu прокси

Схема сервера для запуска web-приложений Django представлена ниже.

Классическая схема запуска Django WEB-приложений

Запуск Django-проекта осуществляется при помощи uwsgi-сервера, он же будет поддерживать и контролировать состояние Django-приложения. Взаимодействием с клиентами занимается Nginx, он проксирует запросы к приложению и статическим файлам, и дополнительно проверяет запросы на наличие SQL-инъекций и других потенциальных угроз (использование ModSecurity для nginx мы рассмотрим в следующей главе).

Подготовка к запуску Python WEB-приложения

Настройка web-сервера (для запуска Django-приложений) начинается с установки необходимых пакетов:

# aptitude install uwsgi uwsgi-plugin-python3
# aptitude install python3-pip git
# aptitude install python3-psycopg2

Пакет python3-psycopg2 используется для работы с базой данных postgresql, и если у вас используется другая СУБД, то установите соответствующие пакеты. Установим необходимые для запуска web-приложения версии пакетов, описанные в файле requirements.txt (обычно, в Django-проектах этот файл присутствует):

# pip3 install -r requirements.txt

Как вы ,наверное, заметили я рассматриваю третью версию Python. Для второй версии используйте команду pip и соответствующие пакеты. Обратите внимание на небольшую деталь: установленные при помощи pip3 пакеты размещаются в каталоге /usr/local/lib/python3.4/dist-packages/, а установленные из репозитория Ubuntu модули расположены в каталоге /usr/lib/python3.4/.

Настройка UWSGI для запуска Django-приложений

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

[uwsgi]
http-socket = 127.0.0.1:8000
chdir = /opt/web-projects/mh24_webportal/
master = true
module = mh24_webportal.wsgi:application
env = DJANGO_SETTINGS_MODULE=mh24_webportal.settings
pythonpath = /usr/lib/python3.4:/usr/local/lib/python3.4/dist-packages:/usr/lib/python3/dist-packages
uid = www-data
gid = www-data
processes = 5
threads = 5
plugins = python3,logfile
logger = file://var/log/uwsgi/app/web-portal.log

Представленный пример запускает типовое Django-приложение не использующее виртуальное окружение (используются системные библиотеки). Сейчас мы подробнее рассмотрим параметры UWSGI-скрипта запускающего Django-приложение:

http-socket - используйте именно http-socket, а не просто socket, так как второй вариант потребует особой настройки nginx, а параметр 127.0.0.1:8000 говорит, что серверная часть будет слушать порт 8000 на локальном хосте, если вы хотите проверить как работает приложение, то разрешите удаленный доступ к порту 8000 используя параметр 0.0.0.0:8000

  • chdir - корневой каталог приложения
  • master - запуск в режиме мастера
  • module - запускаемый модуль (каталогmh24_webportal -> файл wsgi.py - > приложение application )
  • env - Задаем переменный окружения и в примере задан файл настроек
  • pythonpath - перечисляем каталоги в которых производится поиск модулей для проекта
  • uid - идентификатор пользователя
  • gid - идентификатор группы
  • processes - сколько запускать процессов
  • threads - сколько запускать потоков
  • plugins - загружаемые плагины
  • logger - параметры логирования

Файл называется web-portal.ini и расположен в каталоге /etc/uwsgi/apps-available. По аналогии с nginx-конфигурацией для автозапуска при старте сервера, создайте символическую ссылку на файл в каталог /etc/uwsgi/apps-enabled. Для первого тестового запуска web-приложения выполните команду:

# uwsgi --ini ./web-portal.ini

Для проверки работоспособности приложения можно попробовать выполнить curl-запрос и проверить лог-файлы:

# curl http://127.0.0.1:8000

Настройка Nginx для обслуживания Django-приложений

В простейшем варианте nginx должен напрямую обслуживать работу с каталогами static и media (так как, там только статические файлы) и проксировать запросы к WEB-приложению UWSGI.

Конфигурационный файл, который выполняет описанный функционал представлен ниже:

server {
   listen 80 default_server;
   server_name _;

   access_log /var/log/nginx/web-portal-access.log;
   error_log /var/log/nginx/web-portal-error.log;

   location /static/ {
       index index.html;
       autoindex off;
   }

   location /media/ {
       alias /opt/web-projects/mh24_webportal/mh24_webportal/media/;
       index index.html;
       autoindex off;
   }

   location / {
       proxy_pass http://127.0.0.1:8000;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-for $proxy_add_x_forwarded_for;
       proxy_set_header Host $host:$server_port;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_connect_timeout 600;
       proxy_read_timeout 600;
       proxy_send_timeout 600;
       client_max_body_size 1024M;
   }
}

Рассмотрим некоторые параметры конфигурации более детально:

  • location /static/ и /media/ описывают статические файлы, которые напрямую считываются с файловой системы
  • location / - основной редирект на web-приложение
  • autoindex off - запрещает просмотр содержимого каталога
  • У параметра alias обязательно указывайте завершающий /, в противном случае, запрос склеит имя файла и каталога.

Остальные параметры довольно типовые и я их многократно уже описывал. Повторяться не буду.

Похожие статьи

Отправка оповещений Django-приложения в приватный чат Rocket.Chat

Отправка оповещений Django-приложения в приватный чат Rocket.Chat

Вчера я подумал, что если я все же вернулся к использованию Rocket.Chat и он меня уже не так бесит как предыдущие версии, то можно настроить систему оповещений о событиях на сайте и сбоях в работе Django-приложения в приватный чат Rocket.Chat. Для Python быстро нашелся вполне работоспособный модуль который идеально подошел для отправки сообщений в приватные чаты.


Создание и публикация Django-приложения (Часть первая, создание типового Django-приложения)

Создание и публикация Django-приложения (Часть первая, создание типового Django-приложения)

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


Использование jQuery Ajax для отправки данных Django-форм без обновления WEB-страницы

Использование jQuery Ajax для отправки данных Django-форм без обновления WEB-страницы

Я последнее время довольно активно использую Java Script в своих проектах. 21-ый век все таки на дворе и надо соответствовать. Хотя почему то считается, что использовать чистый Ajax для работы с формами не стоит и необходимо предоставить возможность работы и с перезагрузкой страницы, но мне кажется, что врят ли сейчас кто-то пользуется IE6, ну и если и пользуется, это его персональное горе.


Логирование ошибок в Django-проекте на боевом сервере

Логирование ошибок в Django-проекте на боевом сервере

Как вы наверное знаете у Django Framework имеется отличная система отладки и вывода отладочной информации при ошибке WEB-приложения и включается режим отладки простым DEBUG = True. Естественно, что на продакшн (боевых) сервера такое поведение недопустимо и в случае сбоя клиенту отображается лишь страница 500 с соответствующим кодом возврата и конечно клиенту этого вполне достаточно, но нам то необходимо оперативно отреагировать на сбой web-приложения и принять меры.


Создание Sitemap.xml для Django-проектов

Создание Sitemap.xml для Django-проектов

Для чего нужен файл sitemap.xml я думаю объяснять не стоит и все кто знаком с web-разработкой понимают, что этот файл так же важен как и robots.txt. Если вы используете полноценную CMS, то там за вас всю работу уже проделали и например в Django CMS поддержка Sitemap.xml и Robots.txt есть что называется из коробки, но в чистых Django Framework-проектах все эти операции придется проделать самостоятельно.


Миграция WEB-приложения Django с версии 2.7 на 3.5 (на практическом примере)

Миграция WEB-приложения Django с версии 2.7 на 3.5 (на практическом примере)

Про консоль управления виртуализацией WebVirtCloud (бывший WebVirtManager) я уже как то рассказывал, но главной его проблемой как я уже сказал является то что он пострен на базе устаревшего Python2 и автор тащит его вперед именно в таком виде. Переписывать он его отказывается мотивируя это тем что все и так работает, но на самом деле там внутри довольно много легаси-мусора. Я его умудился немного переписать под свежую редакцию Django и Python3, но дело еще далеко до завершения хотя пользоваться уже можно.


Отзывы и комментарии