Pull to refresh

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

Reading time 3 min
Views 18K
image

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

Получив однажды ссылку от заказчика на 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/1yu1s7pr3qlr8ag/vagrant-unison-0.0.15.gem — для установки через
vagrant plugin install vagrant-unison-0.0.15.gem

Пользуюсь уже несколько дней и до сих пор щипаю себя, чтобы убедиться, что отсутствие тормозов и глюков мне не снятся.
Правда, по слухам, для комфортной работы нужен 4 ядерный процессор (и желателен SSD + Parallels)

P.S. В связи с появившимися комментариями, прикрепляю иллюстрацию из статьи
Vagrant — NFS shared folders for Mac/Linux hosts, Samba shares for Windows
image

P.S. Не смотря на то что мой fork привлек внимание (в основном буржунета) и до сих пор живет своей жизнью, вынужден заявить что на данный момент я все-же пользуюсь nfs_guest. Я пытался воспользоваться им перед unison, но на моем OSX он тихо отказывался работать, пока я не выяснил, что для работы nfs на OSX необходимо иметь запись localhost в /etc/hosts. nfs к сожалению не сообщает приложениям о событиях в файловой системе, но на фоне проблем с синхронизацией и нагрузкой на процессор, это терпимо. Невыносимые моргания SourceTree, как выяснилось, можно отключить в настройках (Refresh automaticly when files change)
Tags:
Hubs:
+17
Comments 32
Comments Comments 32

Articles