Запуск Django-приложений (Production mode)

    Общий рейтинг статьи: 0 (проголосовало 0 )
    Опубликовано:  [просмотров 280]


    Django-приложения довольно сильно отличаются от php-приложений как структурой проекта, так и методом запуска.  Django-приложения по методу запуска больше похожи на Node.js и Java, чем на PHP и классические ASP-проекты. 

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

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

    Общая схема сервера для запуска web-приложений Django 

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

    Настройка 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

    Представленный пример INI-файл запускает типовое 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 - параметры логирования

    Так же обратите внимание на некоторые особенности с настройкой прав доступа. 

    Так как наши uwsgi-приложения запускаются от имени пользователя www-data обязательно смените владельца log-каталога:

    # chown -R www-data:www-data /var/log/uwsgi/app/

    При использовании обычных сокет файлов, создайте каталог где будут находиться socket-файлы (ситуация с правами аналогичная лог-файлам):

    # mkdir /opt/web-projects/run
    # chown www-data:www-data /opt/web-projects/run

    Файл называется 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 (так как там только статические файлы) и проксировать запросы с 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 обязательно указывайте завершающий /, в противно случае запрос склеит имя файла и каталога, соответственно ничего подобного он найти не сможет.

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


    Связанные записи в блоге

    Обсуждение статьи

    Ваш комментарий: