Всем привет! Сегодня хочу поделиться своим подходом к локальной разработке 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 syncUV:
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 или предпочитаете нативную разработку? Поделитесь своим опытом в комментариях.