Pull to refresh

Comments 35

А как насчет скорости и ресурсоемкости? Сколько памяти съедает такой сетап? Я конечно понимаю что для декстопа всё равно, но я иногда люблю подевелопить но ноут(нет)буке.
У меня съедает примерно 380 — 400 мегабайт памяти. Сначала было ощущение, что проект работает с таким сетапом медленнее, сейчас не могу это подтвердить.

Где-то в комментариях одной из статей читал о проблемах Shared Folders на windows, когда жутко падает производительность. Но там был пример для Rails проекта.

Пробовал ставить это всё на машину с 2Гб памяти и Ubuntu 12.04 на борту — работать можно, хотя дополнительных 400 Мб отдавать на ВМ в данном случае наверно не стоит.
Shared Folders


Там раньше была другая проблема: права на файлы не менялись, там и на файлы и на папки они забивались на мертво (какие конкретно были права не помню), на vmware те же проблемы были. Сейчас может конечно с этим лучше стало.
Вообще, он съедает не больше чем виртуалка на VirtualBox, потому что на нем и основан (в общем случае)
Сам пользуюсь vagrant уже наверно с полгода или больше. Лично меня избавил от ненужных курений мануалов как сделать то или иное действие на OS X. У меня вопрос по поводу share folder. Вы ж ее шарите что бы код редактировать прозрачно через ide c хост машины, верно?
так вот, я использую nfs конфигурацию, так как она вроде бы быстрее.
и вместо:
config.vm.share_folder "www", "/var/www", "www", :create => true

у меня:
config.vm.share_folder("www", "/vagrant", "./www", :nfs => true)

Все хорошо, но наблюдается такой неприятный момент, когда я редактирую файл из IDE есть небольшая задержка до того момента как сама виртуальная машина поймет, что изменения в файле произошли. Таким образом быстро вернувшись в браузер после дописания кусочка кода я могу обнаружить сообщения о том что файла не существует, стоит мне обновиться еще раз и все на месте.
Мне кажется это проблема может быть в настройках nfs сервера, в данном случае им выступает ХОСТ машина.

вопрос такой: как у вас с производительностью share папки? для каких целей вы ее использовали? замечали нечто подобное?

краткость не моя черта
К сожалению, мой опыт работы с Vagrant/Chef мал, и такого рода неприятности не встречались.

для каких целей вы ее использовали?


У меня все проекты, над которым я работаю, лежат на одном уровне, т.к. используют общую папку модулей. Я просто сделал ту директорию, где они лежат, как Shared, а уже на ВМ настроил только VirtualHosts. Этим я избежал клонирования из репозиториев всех проектов.
Vagrant не использовал, игрался с VirtualBox. Пробовал шарить папки через samba/nfs/sshfs. Любой из этих способов непригоден, если сервером выступает гостевая система. Они дико тормозят при вызове, например git status. nfs, плюс ко всему, может повесить систему если Вы потушите виртуалку, забыв отмонтировать шару. Как я ни извращался с настройками, nfs вел себя неадекватно, если сервер пропадал.

Я пришел к выводу, что сервером может выступать только хост-система. Пробуем nfs — опять печаль. Кеш. Мне не удалось полностью отключить кеш. Изменения в файлах происходили совсем не моментально и даже не быстро. Не подходит.

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

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

попробуйте vagrant, куда проще танцов с бубном вокруг virtual box имхо

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

Именно

что касается изменения в файлах они происходят достаточно быстро, почти мгновенно

Меня раздражало приблизительно такое:

быстро вернувшись в браузер после дописания кусочка кода я могу обнаружить сообщения о том что файла не существует


попробуйте vagrant, куда проще танцов с бубном вокруг virtual box имхо

Как-то не проникся пока еще.
Есть ещё вопрос: а где вы храните БД? на хост-машине или на ВМ? Если на хост, то как вы завершаете работу в конце дня? Какой именно командой? Может это как-то автоматизируется?

Я к тому, что мне приходится всегда делать vagrant suspend/halt, чтобы ВМ потом работа с того же места.
БД у меня достаточно крупные, и часто перезаливаются, я использую удаленные сервера. В некоторых случаях удобно работать с одной базой в паре с человеком
Еще из полезностей:
1. Учим шеф:
learnchef.opscode.com/

2. В качестве тестового шеф-сервера очень здорово использовать chef-zero:
github.com/jkeiser/chef-zero
Это полноценный шеф-сервер, но хранит все в памяти, потребляя минимум ресурсов.
Вы уверены что обычному web разработчику нужно использовать chef-server? В контексте статьи для dev-env chef-solo с головой, да и в продакшене он нужен единицам проектов.
Не chef-server, а chef-zero:
— поддерживается knife-ом из коробки;
— никаких хуков для использования поиска не требуется;
— все инструкции от chef-server-а подходят к chef-zero;
— chef-solo команда Chef более не рекомендует использовать, потому что причин на это более нет
Отличная статья, спасибо!
Пока, правда, не совсем понятно, начиная с каких объёмов, стоит это дело автоматизировать.
Пока у меня один комп для разработки и один тестовый сервер, кажется, их проще настроить вручную. А с какого момента стоит начать думать про vagrant?
Спасибо.

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

На счёт Vagrant — я думаю тут по желанию разработчика. Например, тому же верстальщику, который на вашем проекте делает одну страничку, легче сказать установить Vagrant и запустить через vagrant up, чем разбираться с Apache, PHP, MySQL, ставить базу вручную и т.д.

В общем, лучше попробовать, и решить — надо оно вам, или нет. В любом случае, возможностям, которые предлагают данные утилиты, применений масса.
Это примерно как спросить „с какого момента нужно начинать использовать систему контроля версий?“.
Ответ: Почти, всегда!
Если научится использовать эту связку инструментов то даже для throw-away проектов которые вы разрабатываете всего 24 часа на хакатоне, польза будет больше разного рода overhead'ов
chef puppet это конечно хорошо, но нормальное пакетирование пакетов и настроек в перспективе лучше.
По сути все настройки и конфигурации сводятся к наборам зависимых пакетов. Для клонирования машинки достаточно подключить репозиторий и установить те же пакеты что и на исходной машинке.

>Вы не хотите больше помогать новому человеку на проекте (верстальщик, программист) устанавливать всё с нуля

А разве не проще импортировать уже настроенную ВМ?
Настроенная ВМ весит 400+ Мб, Конфиг для Vagrant весит несколько килобайт и может лежать в системе контроля версий.
Тут уж дело каждого.
…а потом, в какой-то момент на всех „настроенных ВМ“ нужно будет, например поднять PostgreSQL до 9.1
Опять будете пересылать образы?
Да образы придется обновить + прощай все что там юзер себе настроил.
Если вы используете Шеф неважно с Vagrant, EC2, VDS или bare-metal, настройки серверов можно хранить в отдельном repo и после прогона например knife cook на каждой машине шеф доставит всё что нужно, и перегрузит всё что нужно. И верстальщику не нужно думать что в каком-то файлике нужно закоментировать строчну номер 321.
Спасибо, понял в чем преимущества. Получается более дальновидное решение.
Описанный в статье Vagrantfile 100% работает, и проверялся на версии 1.2.2. Возможно, вы используете новую версию конфига, и тогда да — синтаксис скорее всего другой. Подробнее о версиях конфига тут
Автор, спасибо, туториал очень пригодился! Со скрипом, но вроде начинает укладываться…
Важным моментом является сохранение состояния ВМ. Если этого не делать, то после каждого запуска через vagrant up, софт будет ставиться заново. При этом теряется весь смысл нашей задумки. Для решения этой ситуации, Vagrant имеет следующие команды:
vagrant suspend — сохраняет текущее состояние и после команды vagrant up работа продолжается с сохраненной точки
vagrant halt — выключает ВМ
После выполнения этих команд, можно смело перезагружать ОС и возобновлять работу заново.

Команда vagrant suspend приостанавливает работу ВМ. vagrant up после этого действительно возобновит её работу.
Но выполнение vagrant up после vagrant halt вызывает повторный provison.
А чем это все отличается от простого создания образа вирт. машины с последующей установка туда нужных программ/настроек?
В посте подробно это описано.
Установкой программ/настроек вам придется заморочиться всего 1 раз, после этого это будет делать Chef. И новый сотрудник, которому вы дадите box, сделает только vagrant up, и всё само настроится. Во вторых, Vagrant поддерживает полезные плагины, которые были описаны в сегодняшнем посте, в третьих это удобство работы, из коробки ssh, ну и например еще такой сайт как puphpet.com
А почему я не могу дать новому сотруднику свой образ VirtualBox?
Новому сотруднику вы дадите конфиги и рецепты для Chef, а он уже запустит vagrant up — и все установится автоматически, и скачается box с нужной операционной системой, и поставится нужный софт, идентичный вашему.
Давать образы VirtualBox несколько странно и монструозно.
Вобщем, если вы не ощутили мощи и полезности из статей о Vagrant на хабре и из предыдущего моего комментария, то уже переубедить вас мне будет сложно. Это просто удобно, попробуйте Vagrant и вам понравится :)
Почему странно? Это как раз быстро. Система то уже установлена и настроена. Включил и работай.

Это просто удобно, попробуйте Vagrant и вам понравится :)

Попробую, если дадите ссылку где Vargant настраивает среду для андроид разработчика. Ubuntu + Ant + Android NDK + SDK + Eclipse ADT.

Я более чем уверен что образ машины передать в разы быстрее чем даже просто ждать пока оно скачает все это. Как Vargant будет справлятся с загрузкой компонентов из GUI я вообще не представляю (В SDK manager). Впрочем, возможно у него есть CLI, но все равно время загрузки все убъет напрочь.

P.S. Мне кажется этот Vargant заточен исключительно под веб.
Only those users with full accounts are able to leave comments. Log in, please.