Django, Docker и DigitalOcean: деплой без боли

Пятого августа 2026 года вышел Django 6.1, но действующей версией с длительной поддержкой остаётся Django 5.2 LTS — именно её мы советуем ставить в продакшен, потому что ветка LTS получает исправления безопасности три года и не заставляет обновляться каждые восемь месяцев. Рядом обновился и язык: стабильная линейка теперь Python 3.14, а 3.13 переведён в режим поддержки. При этом инфраструктура под такой стек стоит смешных денег: минимальный Droplet у DigitalOcean обходится в 4 доллара в месяц за 512 МБ памяти и одно ядро, а с 1 января 2026 года провайдер перешёл на посекундную тарификацию с минимальным списанием в одну минуту. Развернуть боевое приложение на Django сегодня можно за сумму, сопоставимую с чашкой кофе. Вопрос лишь в том, как сделать это так, чтобы потом не переписывать всё заново при первом же обновлении.

Мы в West Star Ltd за последние годы вывели в прод десятки приложений на Django — от внутренних сервисов автоматизации до клиентских порталов с интеграцией в учётные системы. За это время накопился набор приёмов, которые превращают деплой из стрессового события в предсказуемую рутину. В этой статье мы разберём связку из трёх компонентов — Django как фреймворк, Docker как способ упаковки, DigitalOcean как площадку — и честно расскажем, где эта схема работает отлично, а где начинает трещать по швам.

ПОЧЕМУ ИМЕННО ЭТА СВЯЗКА

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

DigitalOcean в этой тройке отвечает за простоту. У больших облаков вроде AWS входной порог по сложности высокий: чтобы поднять один сайт, приходится разбираться в десятке сервисов. DigitalOcean даёт понятный виртуальный сервер с фиксированной ценой, предсказуемым счётом и человеческой документацией. Для малого и среднего бизнеса, для внутренних инструментов, для первых версий продукта это ровно то, что нужно: минимум абстракций, максимум контроля.

Django замыкает связку как фреймворк, который изначально спроектирован под продакшен. В нём из коробки есть система миграций базы данных, панель администратора, защита от типовых атак и продуманная работа со статикой. Django не заставляет собирать приложение из десятка несовместимых библиотек — большая часть нужного уже внутри и проверена годами эксплуатации на крупных проектах.

ЧТО КЛАДЁМ В КОНТЕЙНЕР

Первое правило — контейнер должен быть маленьким и воспроизводимым. Базовый образ мы берём из линейки slim: полноценный образ Python тянет за собой сотни мегабайт того, что в продакшене не нужно. Внутри образа фиксируем точную версию интерпретатора — не просто Python 3, а именно 3.13 или 3.14, чтобы поведение не менялось при пересборке через полгода.

Зависимости фиксируем по версиям до последней цифры. Строка вида «Django больше пятой версии» — это мина замедленного действия: однажды выйдет несовместимое обновление, и сборка сломается в самый неподходящий момент. Мы держим отдельный файл с точными версиями и обновляем его осознанно, а не случайно. Для сборки удобно использовать многоступенчатый подход: на первом шаге ставятся инструменты компиляции и собираются пакеты, а в финальный образ переносится только результат. Так итоговый контейнер весит меньше и в нём меньше поверхности для атак.

Приложение внутри контейнера запускаем не через встроенный отладочный сервер Django, а через полноценный сервер приложений — обычно это Gunicorn. Встроенный сервер не рассчитан на нагрузку и прямо об этом предупреждает в документации. Перед сервером приложений ставим Nginx, который отдаёт статические файлы, терминирует шифрование и распределяет запросы. Классическая продакшен-схема выглядит так: Nginx принимает трафик, статику отдаёт сам, а динамические запросы передаёт Gunicorn, за которым уже работает Django.

БАЗА ДАННЫХ И СТАТИКА — ГДЕ ЧАЩЕ ВСЕГО ПАДАЕТ

Две вещи ломают деплой новичков чаще всего: база данных и статические файлы. Разберём обе.

По базе данных главный принцип — она не должна жить внутри контейнера приложения. Контейнеры по своей природе эфемерны: их пересоздают при каждом обновлении, и всё, что внутри, исчезает. Данные должны храниться отдельно — либо в отдельном контейнере с постоянным томом, либо, что мы советуем для боевых проектов, в управляемой базе данных, которую DigitalOcean предоставляет как отдельную услугу с автоматическими резервными копиями. PostgreSQL здесь стандартный выбор: Django работает с ним лучше всего, и именно его возможности фреймворк использует наиболее полно.

Статика — вторая ловушка. В режиме отладки Django отдаёт статические файлы сам, но в продакшене этот механизм выключается, и разработчик внезапно видит сайт без стилей и картинок. Правильный порядок такой: при сборке образа выполняется команда сбора статики в отдельную папку, а отдаёт эту папку Nginx, а не Django. Для пользовательских загрузок — аватарок, документов, вложений — нужно отдельное постоянное хранилище, потому что при пересоздании контейнера они тоже пропадут. Для растущих проектов мы выносим такие файлы в объектное хранилище, совместимое с протоколом S3, которое у DigitalOcean называется Spaces.

ОТ КОДА ДО СЕРВЕРА: ПОРЯДОК ДЕЙСТВИЙ

Хороший деплой — это последовательность, которую можно повторить вслепую. В нашей практике она выглядит так.

1. Код собирается в образ автоматически при попадании в основную ветку репозитория — вручную образы в продакшене мы не собираем.

2. Готовый образ попадает в реестр контейнеров. У DigitalOcean есть собственный реестр, что удобно: сервер тянет образ из той же экосистемы, где и работает.

3. На сервере запускается связка контейнеров, описанная в одном файле оркестрации: приложение, Nginx и, если база локальная, контейнер с базой. Один файл — один источник правды о том, как устроен продакшен.

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

5. После запуска проверяется здоровье приложения по специальному служебному адресу, и только потом трафик переводится на новую версию.

Отдельно про шифрование трафика. Сегодня нет причин работать без защищённого соединения: бесплатные сертификаты от Let's Encrypt выпускаются автоматически и продлеваются без участия человека. Мы настраиваем автоматическое продление сразу, чтобы через три месяца сайт внезапно не начал ругаться на просроченный сертификат.

СЕКРЕТЫ, ЛОГИ И ОБНОВЛЕНИЯ

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

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

Обновления мы накатываем маленькими порциями и часто, а не большими редкими релизами. Маленькое обновление легко откатить: если новая версия образа повела себя плохо, возвращаемся на предыдущий образ за минуту, потому что он всё ещё лежит в реестре. Именно поэтому мы храним несколько последних образов, а не только текущий.

ОГРАНИЧЕНИЯ И СЛАБЫЕ МЕСТА

Честный разговор о том, где эта схема даёт сбои.

1. Один Droplet — единая точка отказа. Пока приложение живёт на одном сервере, любая его поломка означает простой. Резервирование, балансировка нагрузки и несколько серверов — это уже другой уровень сложности и стоимости, к которому связка из этой статьи напрямую не ведёт.

2. Docker добавляет накладные расходы в обучении. Команде, которая раньше деплоила загрузкой файлов на сервер, придётся освоить сборку образов, тома, сети и оркестрацию. На короткой дистанции это замедляет, а не ускоряет, и это нормально.

3. Минимальный Droplet за 4 доллара реально мал. 512 МБ памяти хватает для сайта-визитки или небольшого пет-проекта, но полноценное приложение с базой данных, кэшем и фоновыми задачами упрётся в память быстро. Реальный рабочий проект чаще начинается с сервера за 12–24 доллара, и это стоит закладывать в расчёты сразу.

4. Управляемая база данных удобна, но платна и заметно дороже самого сервера приложений. Экономия на ней через размещение базы в контейнере оборачивается риском потерять данные и отсутствием нормальных резервных копий — цена ошибки здесь несопоставима с экономией.

5. Миграции базы данных при неаккуратном обращении ломают продакшен. Необратимое изменение схемы, выкаченное без плана, способно положить приложение целиком. Дисциплина обратной совместимости — не пожелание, а обязательное условие спокойного деплоя.

6. DigitalOcean неидеален по географии. Для аудитории в Казахстане ближайшие дата-центры находятся не рядом, и задержки сети будут ощутимее, чем у локального хостинга. Для многих проектов это некритично, но для чувствительных к скорости сервисов это нужно измерять, а не предполагать.

ЧТО ДЕЛАТЬ

Разработчику. Начните с одного файла оркестрации и точной фиксации версий — это фундамент, на котором держится всё остальное. Настройте автоматическую сборку образа и научитесь откатываться на предыдущий за минуту. Не выносите базу данных в контейнер приложения и с первого дня перенаправляйте логи наружу.

Руководителю. Заложите в план не только сервер, но и управляемую базу данных, хранилище для загрузок и время команды на освоение контейнеров. Требуйте, чтобы деплой был описан как повторяемая процедура, а не как знание в голове одного человека — иначе его отпуск станет вашим риском.

Собственнику. Эта связка позволяет запустить рабочий продукт дёшево и без раздувания инфраструктуры — начать можно с десятков долларов в месяц. Но закладывайте, что при росте нагрузки расходы вырастут предсказуемо, а не внезапно, и что настоящая надёжность требует резервирования, которое стоит отдельных денег. Дешёвый старт и отказоустойчивый продакшен — это две разные точки на одной дороге.

ЧАСТЫЕ ВОПРОСЫ

Обязательно ли использовать Docker для деплоя Django?
Нет, Django можно развернуть и без контейнеров, напрямую на сервере. Но как только проектов становится больше одного или в команде появляется второй человек, расхождение сред начинает съедать время. Docker окупается именно на повторяемости и на предсказуемости обновлений.

Какую версию Django выбрать для нового проекта?
Для продакшена мы советуем действующую версию с длительной поддержкой — сейчас это Django 5.2 LTS, которая получает исправления безопасности три года. Более свежая 6.1 подходит, если вам нужны её новые возможности и вы готовы обновляться чаще.

Хватит ли Droplet за 4 доллара для боевого приложения?
Для сайта-визитки или небольшого внутреннего инструмента — да. Для полноценного приложения с базой данных, кэшем и фоновыми задачами 512 МБ памяти закончатся быстро, и реалистичный старт — это сервер за 12–24 доллара плюс отдельная база данных.

Где хранить пользовательские загрузки?
Не внутри контейнера — при обновлении они исчезнут. Для небольших объёмов подойдёт постоянный том на сервере, для растущих проектов — объектное хранилище, совместимое с протоколом S3. Так файлы переживают любые пересборки и переезды приложения.