Эта статья является адаптированным переводом материала с сайта: Как запустить свой пакет на PyPI
Разработчики Django знают: способ запуска сервера зависит от контекста. Вы не будете использовать команду для локальной разработки, если деплоите сайт на хостинг или VPS. Чтобы выбрать правильный метод, нужно понимать, как Django обрабатывает запросы и статику в разных режимах.
Вот четыре основных сценария и соответствующих им способа запуска Django-сервера.
1. Обычный запуск сервера: Стандарт для разработки
Это самый частый и простой способ запустить проект для работы на локальной машине.
- Назначение: Полностью интегрированный запуск, при котором Django-сервер самостоятельно обрабатывает все запросы от браузера и обслуживает статические файлы (CSS, JavaScript, изображения).
- Порт по умолчанию: Обычно используется порт 8000.
- Команда:Bashpython manage.py runserver
- Смена порта: Порт можно указать в качестве позиционного аргумента сразу после команды runserver:Bashpython manage.py runserver 7000
Это может быть полезно для интеграции с другими инструментами, которые требуют определенный порт или проксирование. Сервер будет доступен по адресу http://localhost:7000.
2. Запуск для проверки боевого режима (с поддержкой статики)
В режиме продакшена, когда DEBUG=False, Django по умолчанию перестает отдавать статические файлы. Это ожидаемое поведение, так как обслуживанием статики должен заниматься отдельный, более эффективный веб-сервер (например, Nginx или Apache).
Однако это создает проблему при разработке или тестировании кастомных страниц ошибок (404, 500). Если DEBUG=False и страница ошибки вызвана, она отобразится без стилей, потому что Django не отдает статику.
- Назначение: Позволяет протестировать, как будут выглядеть страницы (например, кастомные 404/500) в режиме DEBUG=False, но при этом гарантирует, что статические файлы будут доступны.
- Команда: Чтобы запущенный Django-сервер продолжал обрабатывать статику даже в боевом режиме, используйте флаг --insecure:Bashpython manage.py runserver --insecure
3. Запуск на Виртуальном Хостинге: Интерфейсы WSGI и ASGI
При развертывании на виртуальном хостинге или в большинстве облачных PaaS-сервисов, вам не нужно запускать manage.py runserver. Вместо этого ваше Django-приложение взаимодействует с внешним веб-сервером (который уже настроен провайдером) через стандартизированные интерфейсы:
- WSGI (Web Server Gateway Interface): Это стандартный интерфейс для синхронного взаимодействия между Python-приложениями и веб-серверами. Большинство традиционных хостингов полагаются на него.
- ASGI (Asynchronous Server Gateway Interface): Это более современный стандарт, который поддерживает как синхронную, так и асинхронную обработку запросов. Он необходим для работы с такими функциями, как WebSocket-ы.
На хостинге вы просто настраиваете файл, который инициирует приложение (часто это wsgi.py), и хостинг-провайдер использует его для запуска и управления вашим проектом.
4. Запуск на VPS: Обратное проксирование (Nginx/Apache + Gunicorn/Passenger)
Для максимального контроля, масштабируемости и производительности, на выделенном сервере (VPS) используется архитектура обратного прокси.
Схема работы:
- Внешний веб-сервер (Nginx или Apache): Принимает все входящие запросы.
Он быстро и эффективно обслуживает статические (/static) и медиа-файлы (/media), используя настроенные пути на диске.
Он перенаправляет (проксирует) динамические запросы к Django-приложению на определенный внутренний порт или сокет. - Шлюз (Gunicorn, Phusion Passenger или UWSGI): Эти программы называются шлюзами веб-серверов. Они запускают ваше Django-приложение (используя WSGI/ASGI) и прослушивают внутренний порт/сокет, на который Nginx отправляет запросы.
Пример Nginx: Конфигурация Nginx часто использует proxy_pass для передачи запросов на сокет, который прослушивается Gunicorn: proxy_pass http://unix:/tmp/HOST_PLACE_SETUP.socket;. - Системный сервис (Daemon): Поскольку серверы могут перезагружаться, используется системный демон (например, systemd сервис). Его задача — гарантировать, что шлюз (например, Gunicorn) запущен и автоматически перезапускается при сбое или перезагрузке системы.
Этот подход (Nginx + Gunicorn) является наиболее рекомендуемым для продакшена, так как он разделяет задачи и обеспечивает стабильность и высокую скорость отдачи статики.
Заключение
Выбор метода запуска напрямую зависит от стадии разработки и среды развертывания. Использование runserver — это для удобства, а архитектура Nginx/Gunicorn — для надежности и скорости в продакшене.
Надеюсь, это подробное руководство поможет вам уверенно управлять своим Django-сервером!
Если у вас есть конкретные вопросы по настройке Gunicorn или Nginx (например, по скрипту systemd сервиса), я могу предоставить более детальную информацию по ссылке)