Перейти на PRO

Каков стандартный процесс развертывания Django-приложения в production?

Тип вопроса: Devops Вероятность: 10% Категория: Python Разработчик

Ответ

Развертывание Django в production — это многоэтапный процесс, обеспечивающий безопасность, производительность и надежность. Он кардинально отличается от использования manage.py runserver.

Ключевые шаги:

  1. Настройка проекта (settings.py)

    • Установите DEBUG = False. Это отключает отладочную информацию и страницы с ошибками.
    • Заполните ALLOWED_HOSTS списком доменов, с которых разрешены запросы.
    • Используйте переменные окружения (например, через python-dotenv) для хранения секретов (SECRET_KEY, пароли от БД).
    • Настройте production-базу данных (например, PostgreSQL).

  2. WSGI-сервер Для обработки Python-кода используется production-ready WSGI-сервер, такой как Gunicorn или uWSGI. Он эффективно управляет рабочими процессами.

    # Запуск Gunicorn с 4 рабочими процессами, слушающего порт 8000
gunicorn myproject.wsgi:application --workers 4 --bind 0.0.0.0:8000

  3. Веб-сервер (Reverse Proxy) Nginx или Apache ставится перед Gunicorn. Его задачи:

    • Принимать HTTP/HTTPS трафик.
    • Отдавать статические файлы (/static/, /media/) напрямую, не нагружая Django.
    • Перенаправлять все остальные запросы на Gunicorn.
    • Терминировать SSL (обрабатывать HTTPS).

    Пример конфигурации Nginx:

    server {
    listen 80;
    server_name your_domain.com;

    location /static/ {
        alias /path/to/your/project/static/;
    }

    location /media/ {
        alias /path/to/your/project/media/;
    }

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

  4. Сбор статики Перед запуском необходимо собрать все статические файлы проекта в одну директорию (STATIC_ROOT), которую будет обслуживать Nginx.

    python manage.py collectstatic

  5. Управление процессом Чтобы процесс Gunicorn запускался автоматически и перезапускался в случае сбоя, используется менеджер процессов, например, Systemd.

Ответ 18+ 🔞

А, ну вот, опять про этот ваш продакшн, да? Джингу, Нгинкс... Ёпта, народ, вы там совсем с катушек съехали, что ли? Ну ладно, слушай сюда, сейчас я тебе на пальцах, как для дебила, объясню, как эту шарманку на боевых рельсах развернуть, чтобы она не развалилась на первом же запросе.

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

Итак, поехали по кочкам:

  1. Настройки (settings.py) — тут надо мозги включить, а не пальцем в небо тыкать.

    • DEBUG = False — выключай нахуй, сразу! А то какой-нибудь умник увидит твои секреты в ошибке и тебе пиздец. Страницы ошибок будут теперь скучные, белые, но зато безопасные.
    • ALLOWED_HOSTS — сюда пиши свои домены. Если напишешь ['*'], то тебя любой левый бот вгонит в минуса, это как дверь нараспашку оставить с табличкой «заходи, всё твоё».
    • Секреты (SECRET_KEY, пароли от базы) — не пиши их в код, ёбушки-воробушки! Засунь их в переменные окружения. Через python-dotenv или как угодно. Представь, что выкладываешь код на гитхаб, а там твой ключ как на ладони. Пиздец и срамота.
    • База данных — PostgreSQL, только он. SQLite — это для игрушек, на нём продакшн крутить — это как на велосипеде с квадратными колёсами в Париж-Дакар ехать. Задолбаешься.

  2. WSGI-сервер (наш главный работяга) Вот тут вступает в дело Gunicorn (или uWSGI, но первый попроще). Это такой здоровый мужик, который будет твой Django-код крутить в несколько потоков. runserver — это один хиленький офисный хлюпик, а Gunicorn — это бригада грузчиков.

    # Запускаем бригаду из 4 грузчиков (workers), слушаем на всех интерфейсах порт 8000
gunicorn myproject.wsgi:application --workers 4 --bind 0.0.0.0:8000

    Но запускать его так, из консоли — это по-детски. Он упал, и всё, сайт лёг.

  3. Веб-сервер (Reverse Proxy, он же наш секретарь-приёмщик) Это Nginx (или Apache, но первый — наше всё). Его задача — стоять на входе и разгребать поток.

    • Пришёл запрос на картинку (/static/logo.png) или файл (/media/photo.jpg) — Nginx сам, не отвлекая Гunicorn, хвать из папки и отдал. Быстро и без напряга.
    • Пришёл запрос на что-то умное (например, /admin/) — Nginx вежливо пересылает его Гunicorn-у на порт 8000: «на, братан, разберись».
    • Ещё он SSL (HTTPS) на себя берёт. В общем, незаменимая, блядь, вещь.

    Вот тебе кусок его конфига, чтоб не пиздел, что сложно:

    server {
    listen 80;
    server_name твой_домен.ru; # Сюда свой домен впиши, мудя!

    # Статику отдаём сами, не трогаем Django
    location /static/ {
        alias /путь/к/твоему/проекту/static/; # Путь укажи правильный, а то нихуя не найдёт
    }

    location /media/ {
        alias /путь/к/твоему/проекту/media/;
    }

    # Всё остальное — проксируем на Gunicorn
    location / {
        proxy_pass http://127.0.0.1:8000; # Тот самый порт, где наш работяга слушает
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

  4. Сбор статики А то Django свои CSS, JS и картинки по всем углам проекта раскидал. Надо всё в одну кучу собрать, чтобы Nginx знал, где искать. Делается одной командой, но ДО запуска, ёпта!

    python manage.py collectstatic

    После этого в папке STATIC_ROOT будет аккуратненько всё лежать.

  5. Автозапуск и слежка (чтобы не упал) Запускать Гunicorn вручную — это пиздец какой-то атавизм. Используем Systemd (если на линуксе). Напишешь ему service-файл, и он будет твоего работягу как родного следить: упал — поднял, сервер перезагрузился — запустил. Красота, в рот меня чих-пых!

Вот и вся магия. Вроде бы дохуя шагов, но если по порядку, то ничего сложного. Главное — не пытайся на runserver выкатываться, а то опозоришься на всю округу.

© ХакСобесов, 2026
support@hacksobesov.com