Перестать использовать Docker?

Если бы несколько лет назад вы спросили меня, могу ли я представить себе работу без Docker, я бы, наверное, рассмеялся. В то время Docker был стандартом почти для каждой команды, которую я знал. Нужна база данных? Запусти docker run. Нужно обеспечить согласованность окружения? Используй docker-compose.

Это звучало идеально, и какое-то время Docker действительно решал множество проблем.

Но со временем я постепенно осознал, что, особенно в локальной разработке, Docker начал создавать больше проблем, чем решал. Наша команда начала задавать себе простой вопрос: «Мы все еще используем Docker, потому что это лучший выбор, или просто потому, что так делают все?»

Удивительный ответ заключался в том, что для локальной разработки Docker замедлял нашу работу.

Эта статья — не попытка раскритиковать Docker; мы по-прежнему используем его в продакшене и в наших CI/CD-пайплайнах. Вместо этого я хочу поделиться, почему мы отказались от него для локальных настроек и какие инструменты в конечном итоге стали лучшими альтернативами Docker.

От восторга к головной боли

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

Конечно, то тут, то там возникали мелкие проблемы. Но хорошие времена длились недолго. Вскоре эти незначительные заминки превратились в серьезные ежедневные препятствия.

Он пожирал наши ноутбуки заживо

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

Синхронизация файлов была кошмаром

Получение мгновенной обратной связи после изменения кода — основа работы любого разработчика. Но с монтированием томов Docker, особенно на macOS и Windows, производительность ввода-вывода была мучительно медленной. Ожидание нескольких лишних секунд для обновления страницы после изменения одной строки кода может показаться мелочью, но это накапливается, когда вы делаете это сотни раз в день.

Отладка стала сложнее

Когда что-то шло не так внутри контейнера, отладка была гораздо сложнее, чем при запуске приложения нативно. Подключение отладчика, просмотр логов или отслеживание проблем с производительностью требовали дополнительных шагов. Мы тратили слишком много времени на решение «проблем с контейнерами» вместо решения реальных бизнес-задач.

Катализатор перемен: смена бизнес-модели

Изменение бизнес-модели Docker Desktop стало важным поворотным моментом. Дело было не столько в стоимости, сколько в том, что это разрушило представление многих разработчиков о Docker как о фундаментальной части инфраструктуры.

Это изменение послужило катализатором, заставив нашу команду остановиться и критически оценить инструмент, который мы использовали ежедневно. Мы начали задавать себе вопросы: «Не стала ли наша зависимость от Docker Desktop просто привычкой? Теперь, когда это коммерческий продукт с четкими условиями лицензирования, предлагает ли он по-прежнему наилучшую ценность для локальной разработки?»

Именно этот момент побудил нас активно искать и оценивать другие варианты на рынке, а не пассивно принимать статус-кво. Нашей целью было найти инструмент — бесплатный или нет, — который принес бы большую эффективность и лучший опыт в наш рабочий процесс локальной разработки.

Мой путь к поиску альтернатив: два направления, которые я исследовал

Мои поиски шли в двух направлениях: во-первых, найти более легковесные инструменты для контейнеризации, и, во-вторых, полностью выйти за рамки мышления контейнерами и вернуться к более прямолинейной локальной среде разработки.

Путь 1: Улучшенные инструменты для контейнеризации

Для разработчиков, которым все еще нужны контейнеры или чьи рабочие процессы тесно интегрированы с Kubernetes, отказ от Docker Desktop не означает отказ от контейнеризации. Существует несколько отличных альтернатив.

• Podman: Разработан Red Hat, его главная особенность — бездемонная (daemonless) архитектура. Это означает, что он потребляет меньше ресурсов и более безопасен. Его интерфейс командной строки почти идентичен Docker, так что вы даже можете использовать alias docker=podman для плавного перехода с минимальной кривой обучения.

• Colima: Если вы пользователь macOS, Colima — отличный выбор. Он чрезвычайно легковесен, быстро запускается и потребляет мало ресурсов. Под капотом он использует Lima (виртуальные машины Linux на macOS) для предоставления среды Linux для контейнеров и совместим с Docker CLI.

• Rancher Desktop: Этот проект с открытым исходным кодом предоставляет десктопное приложение, которое объединяет управление Kubernetes и контейнерами. Если вам нужны не только контейнеры, но и локальный кластер K8s, Rancher Desktop — это комплексное решение.

Эти инструменты смягчают некоторые проблемы с производительностью и лицензированием Docker Desktop. Однако на macOS и Windows они по-прежнему зависят от виртуализации, что означает, что они не могут полностью устранить присущие ей накладные расходы на производительность.

Путь 2: Возвращение к «старой школе», но более эффективной интегрированной среде

Когда я уже был готов сдаться, я открыл для себя другой путь: почему локальная разработка вообще должна быть в контейнере? Особенно для таких команд, как моя, в основном занимающихся веб-разработкой, все, что нам действительно нужно, — это стабильные версии PHP, Node.js, MySQL, Redis и так далее.

Это привело меня к изучению нового поколения локальных интегрированных сред разработки.

ServBay

Это мое самое большое открытие за последнее время, и теперь это мой основной инструмент. Вы можете думать о нем как о прокачанной версии MAMP. ServBay решает многие болевые точки традиционных интегрированных сред (таких как MAMP и XAMPP).

• Превосходная производительность: Поскольку все службы работают нативно на хост-машине, нет накладных расходов на виртуализацию. Это означает, что все, от времени отклика приложения до операций ввода-вывода файлов, значительно быстрее, чем в Docker. К тому же, установщик ServBay невероятно легковесен — всего 20 МБ.
• Гибкое управление несколькими версиями: ServBay позволяет одновременно запускать несколько версий различных языков разработки и служб, включая, но не ограничиваясь, Python, Rust, Java, PHP, Node.js и MySQL. Вы даже можете назначать определенные версии для каждого из ваших сайтов. Это невероятно полезно при поддержке нескольких устаревших проектов.
• Простота использования: Он предлагает чистый графический интерфейс, который делает такие задачи, как добавление сайтов, настройка доменов и включение SSL одним щелчком мыши, невероятно простыми. Нет необходимости вручную редактировать сложные файлы конфигурации.
• Полный набор инструментов: Он поставляется с такими распространенными инструментами, как Redis, Memcached, DNS-сервер, локальный туннелинг и даже локальный ИИ, встроенными и готовыми к использованию «из коробки».

Для подавляющего большинства сценариев веб-разработки скорость и удобство, которые предлагает ServBay, позволили мне наконец попрощаться с шумом вентиляторов и долгим ожиданием, которые сопровождали Docker.

MAMP / XAMPP / WAMP

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

Итак, как же выбрать?

Идея «перестать использовать Docker» — это не абсолютный приказ, а призыв переоценить свои инструменты. Правильный выбор зависит от ваших конкретных потребностей.

• Если ваш рабочий процесс тесно связан с Kubernetes или вам часто нужно создавать образы для разных архитектур, инструменты для контейнеризации, такие как Podman или Rancher Desktop, по-прежнему будут вашим лучшим выбором.
• Если вы пользователь macOS и ищете легковесную среду выполнения контейнеров, стоит попробовать Colima.
• Но если вы, как и я, в основном веб-разработчик (особенно с PHP, Node.js и т. д.), который ценит максимальную скорость и простоту в своей локальной среде, я настоятельно рекомендую попробовать интегрированный инструмент, такой как ServBay или MAMP. Это позволит вам снова сосредоточить свою энергию на написании кода, а не на борьбе с инструментами.

Заключительные мысли

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

Наша цель — писать код эффективно и с удовольствием. Если инструмент начинает становиться обузой, не бойтесь искать ему альтернативу. Для меня переход с Docker Desktop на ServBay был правильным решением. Мой ноутбук снова работает тихо, а процесс разработки стал гораздо плавнее.