Есть, работает из коробки, но нужен установленный hyper-v на windows 8.1 или 2012r2. Только мало боксов для hyperv на vagrantcloud
Нужно поставить последний vagrant для windows, затем найти подходящий бокс и сделать init, например так:
Да, поэтому я описал два варианта хранения проекта в виртуальной машине: в общем каталоге или в домашнем каталоге пользователя приложения (в разделе «Настройка каталога проекта»).
nfs/smb намного лучше. Единственный плюс родных шаред фолдеров virtualbox — они работают и на win и на nix и не нужно делать if-ов в вагрант файле. Скажем если в команде есть кто-то на windows можно сделать так:
Rsync допустим можно на CI сервере поднимать или где еще получив таким образом небольшой профит в плане производительности. А артефакты можно сбрасывать в директорию замаунченую по nfs допустим. Но для разработки штука бесполезная.
Я себе делал скрипт в external tool, который делал rsync и рисовал прогресс бар в шторме. Но всё равно медленновато получается.
Хочется что бы синхронизация мгновенная была. Но решения я пока не нашел.
А чем не подошел deployment-сервер в шторме, описанный в разделе «Настройка каталога проекта»? Сохраняемые файлы автоматически выгружаются в виртуалку, достаточно оперативно получается.
Homestead проще, но не дает такого контроля. Грубо говоря, Homestead — это черный ящик. Предложенный же вариант позволяет самому выбрать, какие пакеты будут установлены, какие конфиги они будут использовать. И все это будет прозрачно для всех членов команды.
Чиф не самая простая штука для рядового PHP-шника не интересующегося всем этим devops стафом. Можно для провиженинга виртуальной машины использовать ansible или puppet. Так же если вам лень делать провиженинг руками можно воспользоваться сервисами phansible.com и puphpet.com/.
Не вижу особой разницы в сложности между Puppet/Ansible/Chef.
Описанный мною сценарий мы успешно применяем в командной разработке, при этом разработчикам не нужно разбираться в рецептах Chef, за них это сделал тимлид. Максимум нужно понимать настройки в JSON-файле и уметь делать «vagrant up» :)
Не очень понимаю, зачем столько телодвижений.
У меня обычный box precise32 работает, что называется из коробки. Да, есть конфиги, которые хранятся в папке проекта с описаниями команд, которые надо выполнить при первом запуске, но не думаю, что это стоит написания целой статьи.
Vagrantfile в итоге выглядит так:
Vagrant.configure("2") do |config|
config.vm.box = "precise32"
config.vm.box_url = "http://files.vagrantup.com/precise32.box"
config.vm.provision :shell, :path => "carcass/vagrant/prepare-precise32.sh"
config.vm.provision :shell, :path => "carcass/vagrant/setup-app.sh"
config.vm.network "forwarded_port", guest: 80, host: 8080 # frontend
config.vm.network :private_network, ip: "192.168.33.10" #Let it be available on this IP
end
И для нового разработчика все развертывание проекта:
Да, вы правы, можно делать provision с помощью shell-скриптов.
Но для сложных конфигураций это может оказаться сложнее, так как Chef из коробки обеспечивает идемпотентность и имеет наборы готовых рецептов для всех популярных пакетов. То есть банально меньше кода получается :)
В том-то и проблема, что имеет кукбуки только для популярных пакетов, а для каких-то специфических приходится либо писать свои кукбуки (что лично у меня каждый раз вызывает припадки ненависти к руби), либо использовать тотже самый bash провиженинг.
Можно использовать альтернативный подход: для популярных пакетов использовать Chef cookbooks, а специфические вещи настраивать с помощью shell-скриптов (Vagrant поддерживает запуск нескольких provisioner'ов последовательно).
Когда решал подобный вопрос, мне не давало покоя необходимость изучать дополнительный инструмент (несомненно полезный), необходимость поддерживать актуальное стояние Chef-конфига и держать целую структуру и только для того что бы поднять локальную ВМ. Особенно убивало то, что проверенный конфиг не всегда отрабатывал и приходилось фиксить. Предположу, что вопрос актуальности Chef-конфига на текущий момент может решить пакетный менеджер для Chef (librarian, berkshelf или что там сейчас в апстриме...).
В результате остановился на provision с помощью shell-скриптов, это позволило решить задачу одним файлом Vagrantfile, ничего особенного, но может быть, будет полезно не только мне.
Я понимаю полезность использования Chef и подобных ему инструментов, по возможности изучаю данную тему на предмет повседневного использования. Хочется получить ответы от пользователей Chef на вопросы:
Возможно описать настройку Vagrant одним файлом используя Chef?
Какую методику можно переменить что бы быть уверенным в том что Chef-кофиг не протухнет будет актуальным?
Есть успешный и комфортный опыт использования Chef для развертывания, как рабочего окружения так и локального на Vagrant?
Чисто теоритически, минимум два файла. Плэйбук, по которому будет происходить провиженинг, и инвентори файл, в котором расписана какие серваки какие и как к ним коннектится (доступы, ключи и т.д.)
Другой вопрос что одним файлом все делать попросту глупо. Обычно разделяют все на отдельные реюзабельные стэпы (роли) и в плэйбуках или переменных настраивать уже под проект. Ролей готовых на том же ансибл гэлэкси пруд пруди, только выбирать тяжко и надо проверять каждую.
Но если хотите все одним файлом — Docker. Там будет вам один файл, в котором простым bash скриптом провиженится контейнер и он же поднимается. Но тогда придется что-то еще для деплоя использовать что бы там поднимать ваши контейнеры.
Под областью видимости, в данном случае, я имею ввиду, что конфигурация виртуальной машины реализована одним файлом (подробнее ilyar.github.io/localserver/), конечный результат почти аналогичен описываемому в статье.
С тем же успехом можно просто запустить vagrant init ubuntu/trusty
Не забудьте что перед использованием вам нужно будет создать необходимые скрипты для провиженинга машины.
Можно просто один раз настроить окружение, сделать роли для ансибла к примеру, подготовить базовые плейбуки для провиженинга и деплоя (или что бы это отдельный человек делал) и использовать из проекта в проект. С типовыми проектами вообще легко так построить процессы. С кастомными типовая структура просто потребует обкатки на нескольких проектах и в большинстве случаев будет работать уменьшая количество времени необходимое на развертывание.
Спасибо за ссылку, она несомненно пригодится. Без спорно инструменты chef, ansible, puppet и п. р. имеют свои плюсы, но без наличия в команде соответствующего специалиста, применять их будет сложно.
Описанный мной подход, без каких либо ноу-хау, прекрасно решает задачу консистентного программного окружения и позволяет легко воспользоваться его возможностями.
С тем же успехом можно просто запустить vagrant init ubuntu/trusty
Если выполнить несколько не сложных действий описанных в комментарии выше станет очевидно что это готовая к работе виртуальная машина, на которой настроено (из описания проекта ilyar.github.io/localserver/):
Ubuntu 14.04 LTS 32-bit (for use 64-bit set VM_ARCH=64)
Еще раз на примере реального проекта на Yii, для того что бы разработчику получить локально действующий проект, достаточно выполнить:
$ git clone https://github.com/ilyar/imotlib.git
$ cd imotlib
$ vagrant up
$ open http://imotlib.local/
В результате имеем настроенное рабочее окружение и проинициализированный проект, разработчику останется только писать код. При необходимости он может поправить настройку ВМ и для этого не потребуется изучать что то дополнительно, потому что все в одном месте с использованием родного bash.
без наличия в команде соответствующего специалиста, применять их будет сложно
ansible это не язык программирования на изучение которого может понадобится несколько недель. 1 — 2 вечера достаточно для того чтобы понять как это работает и сделать свою простую сборку на подобии того что у вас в bash файле.
Конкретно для вашего проекта bash может быть вполне уместным. Но если конфигурация станет по сложней, то это будет уже не удобно. Представьте как будет выглядеть допустим вот эта сборка если её поместить целиком в Vagrantfile.
Представил, «вот эта сборка» сложной не будет, но могу согласится с тем что такое возможно, пока не сталкивался, предвкушая возможные осложне��ия, посматриваю в сторону соответствующих инструментов.
Возможно описать настройку Vagrant одним файлом используя Chef?
Методика использования Chef основана на использовании cookbook'ов — готовых наборов рецептов. Поэтому настройка сервера так или иначе будет размазана по этим рецептам.
Какую методику можно переменить что бы быть уверенным в том что Chef-кофиг не протухнет будет актуальным?
В описанном мной подходе как раз используется менеджер зависимостей «librarian», который фиксирует версии cookbook'ов в lock-файле. Версия самого Chef также фиксируется с помощью плагина (это описано в начале статьи).
Есть успешный и комфортный опыт использования Chef для развертывания, как рабочего окружения так и локального на Vagrant?
В нашей команде мы разворачиваем и dev и prod, см. комментарий.
Можно ли использовать вашу конфигурацию одновременно для разработки и продакшна?
Точнее, есть желание настраивать конфигурацию сервера в одном месте как для целей разработки, так и для продакшна, чтобы не переносить вручную изменения в конфигах.
Суть вкратце такова: конфиги production-сервера хранятся в отдельном репозитории, который просто подключается в основной репозиторий проекта. Это позволяет разделить конфиги между разработчиками и системными администраторами.
Если необходимости в таком разделении нет, то можно настройки production-сервера добавить в ".chef/nodes" и немного поправить пути в скрипте «deploy.sh».
Нужно поставить последний vagrant для windows, затем найти подходящий бокс и сделать init, например так:
И затем
Наверное стоит ещё раз попробовать. Пока выкручивался снэпшотами.
www.midwesternmac.com/blogs/jeff-geerling/nfs-rsync-and-shared-folder
Rsync допустим можно на CI сервере поднимать или где еще получив таким образом небольшой профит в плане производительности. А артефакты можно сбрасывать в директорию замаунченую по nfs допустим. Но для разработки штука бесполезная.
Хочется что бы синхронизация мгновенная была. Но решения я пока не нашел.
Особенно это видно когда деплоишь изменения на сервер после git-пулла. Он все файлы просто копирует на сервер.
Правда, перед этим приходится делать «git reset --hard && git clean -fd».
habrahabr.ru/post/211887/#comment_7292017
Описанный мною сценарий мы успешно применяем в командной разработке, при этом разработчикам не нужно разбираться в рецептах Chef, за них это сделал тимлид. Максимум нужно понимать настройки в JSON-файле и уметь делать «vagrant up» :)
У меня обычный box precise32 работает, что называется из коробки. Да, есть конфиги, которые хранятся в папке проекта с описаниями команд, которые надо выполнить при первом запуске, но не думаю, что это стоит написания целой статьи.
Vagrantfile в итоге выглядит так:
И для нового разработчика все развертывание проекта:
Но для сложных конфигураций это может оказаться сложнее, так как Chef из коробки обеспечивает идемпотентность и имеет наборы готовых рецептов для всех популярных пакетов. То есть банально меньше кода получается :)
Когда решал подобный вопрос, мне не давало покоя необходимость изучать дополнительный инструмент (несомненно полезный), необходимость поддерживать актуальное стояние Chef-конфига и держать целую структуру и только для того что бы поднять локальную ВМ. Особенно убивало то, что проверенный конфиг не всегда отрабатывал и приходилось фиксить. Предположу, что вопрос актуальности Chef-конфига на текущий момент может решить пакетный менеджер для Chef (librarian, berkshelf или что там сейчас в апстриме...).
В результате остановился на provision с помощью shell-скриптов, это позволило решить задачу одним файлом Vagrantfile, ничего особенного, но может быть, будет полезно не только мне.
Я понимаю полезность использования Chef и подобных ему инструментов, по возможности изучаю данную тему на предмет повседневного использования. Хочется получить ответы от пользователей Chef на вопросы:
не протухнетбудет актуальным?Другой вопрос что одним файлом все делать попросту глупо. Обычно разделяют все на отдельные реюзабельные стэпы (роли) и в плэйбуках или переменных настраивать уже под проект. Ролей готовых на том же ансибл гэлэкси пруд пруди, только выбирать тяжко и надо проверять каждую.
Но если хотите все одним файлом — Docker. Там будет вам один файл, в котором простым bash скриптом провиженится контейнер и он же поднимается. Но тогда придется что-то еще для деплоя использовать что бы там поднимать ваши контейнеры.
Минимальная область видимости, просто изменять, стабильный результат.
Не совсем понятно про какую область видимости идёт речь и в чём заключается удобство использования и поддержки в таком случае.
Под областью видимости, в данном случае, я имею ввиду, что конфигурация виртуальной машины реализована одним файлом (подробнее ilyar.github.io/localserver/), конечный результат почти аналогичен описываемому в статье.
Не забудьте что перед использованием вам нужно будет создать необходимые скрипты для провиженинга машины.
Можно просто один раз настроить окружение, сделать роли для ансибла к примеру, подготовить базовые плейбуки для провиженинга и деплоя (или что бы это отдельный человек делал) и использовать из проекта в проект. С типовыми проектами вообще легко так построить процессы. С кастомными типовая структура просто потребует обкатки на нескольких проектах и в большинстве случаев будет работать уменьшая количество времени необходимое на развертывание.
А еще есть phansible.com и подобные.
Описанный мной подход, без каких либо ноу-хау, прекрасно решает задачу консистентного программного окружения и позволяет легко воспользоваться его возможностями.
Если выполнить несколько не сложных действий описанных в комментарии выше станет очевидно что это готовая к работе виртуальная машина, на которой настроено (из описания проекта ilyar.github.io/localserver/):
VM_ARCH=64
)Еще раз на примере реального проекта на Yii, для того что бы разработчику получить локально действующий проект, достаточно выполнить:
В результате имеем настроенное рабочее окружение и проинициализированный проект, разработчику останется только писать код. При необходимости он может поправить настройку ВМ и для этого не потребуется изучать что то дополнительно, потому что все в одном месте с использованием родного bash.
В описанном мной подходе как раз используется менеджер зависимостей «librarian», который фиксирует версии cookbook'ов в lock-файле. Версия самого Chef также фиксируется с помощью плагина (это описано в начале статьи).
В нашей команде мы разворачиваем и dev и prod, см. комментарий.
Точнее, есть желание настраивать конфигурацию сервера в одном месте как для целей разработки, так и для продакшна, чтобы не переносить вручную изменения в конфигах.
Суть вкратце такова: конфиги production-сервера хранятся в отдельном репозитории, который просто подключается в основной репозиторий проекта. Это позволяет разделить конфиги между разработчиками и системными администраторами.
Если необходимости в таком разделении нет, то можно настройки production-сервера добавить в ".chef/nodes" и немного поправить пути в скрипте «deploy.sh».
Хотя внутри это, конечно, тот же самый VirtualBox, только сделано все гораздо незаметнее, чем Vagrant.