Производительность shared-папок в vagrant

в 16:18, , рубрики: java, php, shared folders, sshfs, unison, vagrant, виртуализация

Руководя крупной и регулярно пополняющейся командой программистов, столкнулся с необходимостью быстро разворачивать среду разработки без танцев с бубном в духе «странно, у меня этот же код работает, а у тебя какая версия такой-то библиотеки?»

Получив однажды ссылку от заказчика на Vagrant с вопросом «а почему мы это сих пор это не используем?» принялся осваивать это чудо.

Спустя некоторое время подготовил Vagrantfile, за считанные минуты разворачивающий сложную систему репозиториев, библиотек, серверов и деплоеров. И все бы хорошо, но одна маленькая неприятная деталь — все это либо жутко тормозило/глючило, либо (при локальном выполнении) не обеспечивало прямого доступа к хранящимся внутри vagrant репозиториям.

Многие скажут, а зачем нужен этот прямой доступ, если можно хранить копии файлов на host машине и доставлять их на guest машину автоматически, при сохранении их в IDE.

Все верно, но есть нюанс — команде нужна возможность переключать ветви (branches) git репозиториев на сервере, наблюдать результат в браузере и редактировать код ветвей у себя в IDE не отходя от кассы.

Многие скажут, а в чем проблема, есть же ssh и консольный git и даже покажут маньяка, который вбивает команды консольного git клиента с клавиатуры быстрее, чем клиент успевает их выполнять. Можно согласиться и с этим утверждением, но имея 10 репозиториев и несколько десятков ветвей на репозиторий, я предпочитаю наблюдать и управлять всем этим визуально, через SourceTree, и иметь практически любую команду по управлению этой махиной, в досягаемости трех кликов.

Перепробовано.

  1. Shared Folders — скорость отработки скриптов оказалась в 10 раз меньше чем при выполнении с guest папок
  2. SSHFS
    • постоянные реиндексирования в phpStorm
    • выпадание всех файлов из git index при переключении ветвей, с необходимостью постоянно делать reset --hard
    • неспособность IDE и git клиентов заметить происшедшие изменения в файлах
  3. 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. совместимости с 1.7.x;
  2. поддержки repeat режима;
  3. возможности решать конфликт базы даных 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

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

Автор: dmatora

Источник

Поделиться

* - обязательные к заполнению поля