Что происходит при выполнении команды manage.py runserver в Django?

Ответ

Команда python manage.py runserver запускает легковесный веб-сервер, предназначенный исключительно для разработки. Он не подходит для использования в production из-за низкой производительности и отсутствия проверок безопасности.

Процесс запуска:

  1. Запуск WSGI-сервера. Django использует встроенный в Python модуль wsgiref для создания простого, однопоточного HTTP-сервера. Этот сервер реализует стандарт WSGI (Web Server Gateway Interface) для взаимодействия с самим Django-приложением.

  2. Привязка к адресу и порту (Binding). Сервер начинает "слушать" указанный IP-адрес и порт. По умолчанию это 127.0.0.1:8000, что делает его доступным только на локальной машине.

    • 0.0.0.0:8000 делает сервер доступным со всех сетевых интерфейсов компьютера.
  3. Обработка HTTP-запросов. При поступлении HTTP-запроса сервер передаёт его Django-приложению. Далее запрос проходит через стандартный цикл Django: middleware, URL-маршрутизатор, view-функция и возвращается в виде HTTP-ответа.

Пример запуска:

# Запуск на стандартном порту 8000, доступен только локально
python manage.py runserver

# Запуск на порту 8080, доступен из локальной сети
python manage.py runserver 0.0.0.0:8080

Важные моменты:

  • Если указанный порт уже занят другим процессом, возникнет ошибка OSError: [Errno 98] Address already in use.
  • Для production-окружения используется связка из Application Server (например, Gunicorn или uWSGI) и Web Server (например, Nginx).

Ответ 18+ 🔞

Слушай, а давай разберёмся с этой командой python manage.py runserver, а то некоторые её воспринимают как волшебную палочку для всего. Так вот, это, блядь, не волшебная палочка, а детский велосипед с подстраховочными колёсами. Только для разработки, ёпта! Сунул это в продакшн — и пиши пропало, накрылся медным тазом твой сервис. Производительность — хуй с горы, безопасность — доверия ебать ноль.

Как эта штука изнутри работает, если по-простому:

  1. Запускается WSGI-сервер. Дядька Джанго хватает встроенный в Питон модуль wsgiref и делает из него примитивный, однопоточный HTTP-сервак. Он умеет только одно — болтать с самим Джанго по протоколу WSGI, как два старых деда у подъезда.

  2. Привязка к адресу (Binding). Сервер садится на указанный IP и порт и начинает слушать, как ишак. По умолчанию он стеснительный — 127.0.0.1:8000, то есть только с самой машины до него достучаться можно.

    • А вот если дать ему команду 0.0.0.0:8000, он превращается в распиздяя, который готов болтать со всеми в локальной сети. Подозрение ебать чувствую, когда так делают.
  3. Обработка запросов. Прилетает HTTP-запрос — сервер, не долго думая, суёт его в жерло Джанго. А там уже всё по накатанной: middleware, URL-роутинг, view-функция... и обратно выплёвывается готовый ответ.

Вот как это выглядит в жизни:

# Запустили локально, только для себя. Всё чинно, благородно.
python manage.py runserver

# А вот это уже — внимание, манёвр! — открыли для всей сети на порту 8080.
# Только не забудь потом фаерволл настроить, а то пидары налетят.
python manage.py runserver 0.0.0.0:8080

Что важно помнить, чтобы не обосраться:

  • Если порт уже занят каким-нибудь другим процессом, получишь классическое «Address already in use». Значит, кто-то уже там сидит, блядь. Иди ищи, кто.
  • Для настоящего, боевого сайта нужна взрослая связка: Application Server (типа Gunicorn) чтобы приложение крутилось, и Web Server (типа Nginx) чтобы статику раздавать и запросы умно распределять. А runserver — это так, для разминки и отладки, пока кофе пьёшь.