[Из песочницы] Производительность shared-папок в Vagrant
Руководя крупной и регулярно пополняющейся командой программистов, столкнулся с необходимостью быстро разворачивать среду разработки без танцев с бубном в духе «странно, у меня этот же код работает, а у тебя какая версия такой-то библиотеки? «Получив однажды ссылку от заказчика на Vagrant с вопросом «а почему мы это сих пор это не используем?» принялся осваивать это чудо.Спустя некоторое время подготовил Vagrantfile, за считанные минуты разворачивающий сложную систему репозиториев, библиотек, серверов и деплоеров. И все бы хорошо, но одна маленькая неприятная деталь — все это либо жутко тормозило/глючило, либо (при локальном выполнении) не обеспечивало прямого доступа к хранящимся внутри vagrant репозиториям.
Многие скажут, а зачем нужен этот прямой доступ, если можно хранить копии файлов на host машине и доставлять их на guest машину автоматически, при сохранении их в IDE.
Все верно, но есть нюанс — команде нужна возможность переключать ветви (branches) git репозиториев на сервере, наблюдать результат в браузере и редактировать код ветвей у себя в IDE не отходя от кассы.
Многие скажут, а в чем проблема, есть же ssh и консольный git и даже покажут маньяка, который вбивает команды консольного git клиента с клавиатуры быстрее, чем клиент успевает их выполнять. Можно согласиться и с этим утверждением, но имея 10 репозиториев и несколько десятков ветвей на репозиторий, я предпочитаю наблюдать и управлять всем этим визуально, через SourceTree, и иметь практически любую команду по управлению этой махиной, в досягаемости трех кликов.
Перепробовано.
Shared Folders — скорость отработки скриптов оказалась в 10 раз меньше чем при выполнении с guest папок SSHFSпостоянные реиндексирования в phpStorm выпадание всех файлов из git index при переключении ветвей, с необходимостью постоянно делать reset --hard неспособность IDE и git клиентов заметить происшедшие изменения в файлах NFS и NFS Reverse — тупо отказались работать на OSX без плясок с бубном (по отзывам в интернете, тоже не решают вопрос фундаментально) Через несколько дней (недель?) потраченных на изучение этого вопроса, выяснилось, что в своих чаяниях я далеко не одинок, но ничего умнее односторонней синхронизации через rsync, на сегодняшний день общественность толком не видела.Самое близкое, что удалось нащупать — это утилита unison, осуществляющая двухстороннюю инкрементарную синхронизацию, и написанный под нее vagrant plugin — github.com/mrdavidlaing/vagrant-unison
Правда возникла другая проблема. Утилита сама по себе, автоматически синхронизировать папки может лишь в режиме ежесекундного перезапуска, который не поддерживался vagrant плагином. Плагин может обеспечить автоматическую синхронизацию, даже не в repeat, а в event-based режиме, но лишь в одну сторону (host→guest). Более того, плагин писался под версию vagrant 1.1, и на сегодняшний день, не выполнял даже те функции, которые в нем официально заявлены.
Чуть позже выяснилось, несмотря на то, что плагин не обновлялся автором с 26 апреля 2013, 7 месяцев назад другой программист предпринял попытку привести плагин в чувство. Результаты его работы можно наблюдать по адресу: github.com/edtoon/vagrant-unison
Даже его плагин, на последний vagrant (1.7.x) устанавливаться отказывается. Доработав его код мне удалось добиться
совместимости с 1.7.x; поддержки repeat режима; возможности решать конфликт базы даных unison после «vagrant destroy; vagrant up» командой sync-cleanup. Результат представляю вашему вниманию по адресу: github.com/dmatora/vagrant-unisonГотовый плагин: www.dropbox.com/s/913av0bevev63ds/vagrant-unison-0.0.13.gem? dl=0 — для установки через vagrant plugin install vagrant-unison-0.0.13.gem Пользуюсь уже несколько дней и до сих пор щипаю себя, чтобы убедиться, что отсутствие тормозов и глюков мне не снятся.
