Недостатки локальной разработки с помощью Vagrant и Docker
Долгое время игрался с Vagrant и Docker, для создания полного виртуального окружения, да бы приблизить локальную среду к тому, что крутиться на боевом сервере.
Применить их в работе захотел по причине, что на Mac OS установка и настройка некоторых стандартных для сервера программных средств стал переходить грани разумного. Захотелось решить проблему чтения мануалов “как поставить на тот и это” раз и навсегда.
Для начала отмечу, что Vagrant и Docker это разные системы, если Vagrant - это инструмент для создания виртуальной среды разработки, то Docker это движок, позволяющий «упаковать» приложение со всем его окружением и зависимостями в контейнер. Поэтому, часто они даже примиряются совместно (у Vagrant есть даже provisioning (поставщик) основанный на Docker). Но так как Docker может нормально работать на Linux и Mac OS X, то рассматривать, как инструмент буду отдельно.
Опущу преимущества применения Vagrant и Docker, это за меня сделают рекламщики, и буду говорить только о проблемах.
Vagrant
Так как Vagrant, был разработан специально для создания среды разработки, то начал именно с него. К сожалению, после восторга от использования, быстро пришло разочарование и осознания, что не все так радужно.
Начнем с того, чтобы быстро и удобно поднимать виртуалки нужно освоить один (или несколько) из доступных provisioning, синтаксис у большинства легкий и освоить с ними работу можно за пару дней, ни кто не запрещает использовать готовые рецепты, благо на просторах github их тысячи.
Более серьезный недостаток был обнаружен при работе с проектом. Использование Vagrant предполагает, что одна или несколько директорий будет проброшена во внутрь виртуальной машины, чтобы было легко редактировать код. И тут вы столкнетесь с тем, что синхронизация довольно медленный процесс (владельцем Mac OS и Linux повезло можно использовать NFS, где все довольно быстро). Но беда не только в скорости синхронизации, мне “повезло” и в том, что в качестве основного инструмента я использую Python, где есть еще момент с “перезагрузкой” кода … и вот тут не спасет даже NFS. Порой применение изменений может занять до 2 минут, будем откровенны не этого я жду от “удобной” локально разработки. Правда есть решение на основе notify (или fswatch для Mac OS), но это лишний костыль.
Третий недостаток это скорость развертывания среды и размер виртуальных машин. Vagrant поднимает каждый раз отдельную виртуальную машину - от сюда на один даже простецкий проектик у вас будет от 2 до 4 Гб отожранного дискового пространства, а на Mac, это не самый дешевый ресурс. Также первый, холодный, запуск виртуалки может занять до 3 минут, конечно зависит от того, что у вас крутиться на ней.
Docker
Изучая Vagrant часто натыкался, что Docker использую как его замену, но только на Mac OS X и Linux (на Windows он не работает по понятным причинам).
Как не странно Docker решил все, что мне не понравилось в Vagrant: он быстрый, как синхронизации так и в работе; в нем нет проблемы с Python; при развертывании он использует кеш, из-за чего процесс занимает не 10 минут, а считанные секунды; занимает значительно меньше места.
Но у Docker, как инструмент создания окружения есть свои недостатки. Во-первых он создавался не для этого и от сюда в некоторых местах придется использовать костыли (к примеру, запуск контейнеров на разных доменах), во-вторых, мне не нравиться как он устанавливается на Mac, тут тоже приходиться применять костыли. Но сам процесс разработки стал значительно приятнее, и как бонус если вы используете Docker у себя на сервере, можно безболезненно перенести.
Итог
От идеи зарабатывать локально с помощью виртуальных окружений, я не отказался, но применять ее повсеместно передумал. В данный момент использую схему Vagrant с Docker, как provisioning, для наиболее крупных проектов, остальное разрабатывается стандартными средствами (brew в помощь). Оба инструменты хороши по своему, примирять их можно и нужно, но строить иллюзий на их счет не стоит.