Всем привет! Сегодня хочу поделиться своим подходом к локальной разработке backend‑приложений. Речь пойдёт о том, как вернуться к использованию виртуальных окружений, отказавшись от контейнеризации там, где она скорее мешает, чем помогает.

Каждый разработчик давно знает о преимуществах Docker. Мы привыкли воспринимать его как универсальное решение для любых инфраструктурных задач. Некогда революционная парадигма разработки стала обыденностью и сегодня часто принимается как no‑brainer решение при разработке очередного проекта на локальной машине. Но давайте на минуту остановимся и зададимся вопросом: всегда ли эта избыточная изоляция оправдана? Действительно ли нам нужен «мини‑сервер» на каждом этапе написания кода, или мы просто следуем моде, жертвуя скоростью и комфортом?

Почему мы вообще полюбили Docker (аргументы «за»)

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

  • Идентичность окружений (Dev = Prod). Это «золотой стандарт». Контейнеризация минимизирует риск пресловутого «на моей машине работает, а на сервере — нет». Мы получаем гарантию того, что приложение получит именно те зависимости и системные библиотеки, которые были протестированы и одобрены для эксплуатации.

  • Стерильность хост‑машины. Нам не нужно превращать свою рабочую станцию в «свалку» из разномастных версий Python, Node.js или системных библиотек. Все зависимости живут внутри контейнера, а в системе остаётся только сам Docker.

  • Унификация через IDE. Современные IDE научились «прозрачно» интегрироваться с Docker‑контейнерами. Вы пишете код в привычном интерфейсе, а линтинг, автодополнение и отладка работают внутри изолированного контейнера. Это позволяет вообще не устанавливать интерпретаторы языков напрямую в ОС.

  • Лёгкая оркестрация (Docker Compose). Это, пожалуй, главная киллер‑фича. Одной командой docker-compose up мы поднимаем не только приложение, но и весь сопутствующий стек: базу данных, Redis, очереди сообщений и сторонние API‑заглушки. Такая связность сервисов «из коробки» экономит часы на настройку локальной инфраструктуры.

  • Кроссплатформенность. Docker даёт иллюзию одинакового поведения на Windows, macOS и Linux. Разработчик может сменить ноутбук, но процесс запуска проекта останется прежним.

И как бы красиво всё это ни звучало, на практике всё не так безупречно.

  • Запуск контейнера — операция не самая быстрая. Это не просто «запуск программы», а создание полноценной изолированной среды. Чтобы всё заработало, система должна создать для контейнера виртуальные «стены»: ограничить доступ к файлам, изолировать сетевые порты и виртуализировать системные вызовы ядра. На macOS или Windows это дополнительно требует работы целой виртуальной машины (Docker Desktop), которая эмулирует работу Linux. В результате каждый раз, когда вы «просто запускаете код», ваш компьютер тратит ресурсы на поддержание этой прослойки, упаковку слоёв файловой системы и синхронизацию ресурсов. А с ростом числа проектов, и, соответственно, контейнеров, система становится более медлительной, могут возникать конфликты имён.

  • Также не на всех операционных системах сборки ведут себя одинаково. Иногда приходится компилировать пакеты для совместимости с вашей ОС. Например, на macOS с процессорами Apple Silicon (ARM64) запуск образов, рассчитанных на архитектуру x86_64, требует эмуляции через QEMU. Это не только замедляет запуск, но и часто приводит к проблемам при сборке C‑расширений библиотек: компилятор может пытаться собрать код под целевую архитектуру, не находя нужных системных зависимостей внутри контейнера.

  • Интерпретатор, подключённый из Docker, часто более медленный и ограниченный, а иногда его вообще невозможно настроить под какой‑нибудь старый проект, потому что IDE прекратила поддержку старых версий. Разбираться в ошибках бывает очень утомительно. Вывод журналов в консоль часто менее удобен, могут отсутствовать гиперссылки на фрагменты кода. Нормальная отладка часто либо невозможна, либо сильно ограничена и сопряжена с трудностями (вспомним лаги при индексации файлов).

Какая есть альтернатива

Использовать Docker по его прямому назначению, а именно — для поднятия инфраструктуры (ну и развёртывания в прод, конечно), а разработку самого проекта вести на своей локальной машине. Так, уже более года я использую Docker исключительно как вспомогательный инструмент: для того чтобы поднять локальную базу данных, сторонние back‑to‑back сервисы, брокеры сообщений и так далее. Так как у меня MacOS, мне удобно вести разработку в виртуальном окружении, но с некоторыми нюансами.

Поскольку я работаю над множеством разнородных проектов, мне пришлось решать проблемы с версиями интерпретатора Python и версиями дополнительных пакетных менеджеров.

Для решения первой проблемы на помощь пришёл pyenv. Это очень мощный инструмент, который позволяет держать систему максимально стерильной. У меня даже Python не установлен глобально (если не считать предустановленный unix‑овый 3.10). Я не буду приводить полную инструкцию установки pyenv в систему (можно посмотреть тут), скажу лишь, что делал её с помощью Homebrew.

Далее появляется выбор: используется ли в проекте нестандартный пакетный менеджер?

Если ответ "нет", то развёртываем виртуальное окружение со всеми необходимыми пакетами из requirements.txt и настраиваем интерпретатор в вашей любимой IDE.

Если "да", то также развёртываем виртуальное окружение, а затем уже в него устанавливаем необходимый пакетный менеджер определённой версии. Большинство современных пакетных менеджеров могут работать в рамках уже созданного виртуального окружения и устанавливать все пакеты проекта именно туда.

Вкратце опишу процесс работы с Poetry и UV.

Сначала устанавливаем необходимую для версию Python в pyenv и делаем её локальной:

pyenv install 3.10.13
pyenv local 3.10.13

Создаём виртуальное окружение и обновляем pip:

python -m venv .venv
source .venv/bin/activate
pip install --upgrade pip

Определяем версию пакетного менеджера в проекте и ставим его в наше окружение, а затем устанавливаем зависимости из pyproject.toml или соответствующего лок-файла.

Poetry:

pip install poetry==2.4.1
poetry sync

UV:

pip install uv==0.10.9
uv sync

Советы

Чтобы poetry не создавал своего виртуального окружения внутри вашего (как матрёшка), необходимо запустить команду, которая создаст poetry.toml в корне вашего проекта (можно добавить в .gitignore).

poetry config virtualenvs.create false --local

Для UV достаточно просто назвать ваше виртуальное окружение .venv и он сам определит его как destination для устанавливаемых пакетов.

Выводы

Преимущества подхода:

  • Универсальность: каким бы старым или новым ни был проект, вы сможете его запустить. Мы вручную контролируем всю среду исполнения, собирая её как конструктор.

  • Скорость: проекты будут запускаться быстро, а системные ресурсы использоваться максимально эффективно. Больше никаких поднятий виртуальных ОС, контейнерных IDE helper и прочих ресурсных издержек.

  • Удобство: нативные средства запуска и отладки вашей IDE раскрываются в полную силу. Доступ к стеку вызовов, отслеживание и контроль ресурсов, возможность беспроблемного запуска консольных команд, удобный вывод в консоль и многое другое.

  • Аутентичность: всё, что вам требуется — это ваша IDE и pyenv. Чистая система без глобальных версий и замусоренного Docker — вот он, путь настоящего самурая!

А как вы справляетесь с «зоопарком» зависимостей? До сих пор всё упаковываете в Docker или предпочитаете нативную разработку? Поделитесь своим опытом в комментариях.