kiaplayer Nov 28 2014 at 11:00

Vagrant для PHP-проекта

9 min

49K

Website development*PHP*Yii*

Comments 42

Vidog Nov 28 2014 at 11:11

Если пользуетесь linux-системой, можно использовать LXC — экономичнее и быстрее работает

kiaplayer Nov 28 2014 at 12:39

Я пользуюсь Windows + Git Bash. Можно использовать другой provider вместо VirtualBox, для этого нужно внести изменения в Vagrantfile.

VadNov Dec 1 2014 at 06:33

Пытался настроить Vagrant с Hyper-V. Как-то не получилось. Может есть у кого такой опыт?

gollumrsdn Dec 2 2014 at 15:52

Есть, работает из коробки, но нужен установленный hyper-v на windows 8.1 или 2012r2. Только мало боксов для hyperv на vagrantcloud
Нужно поставить последний vagrant для windows, затем найти подходящий бокс и сделать init, например так:

vagrant init hashicorp/precise64

И затем

vagrant up --provider hyperv

VadNov Dec 2 2014 at 15:58

Hyper-V стоит, я с ним активно работаю. Но вот как-то не получилось завести. Или может когда я пробовал ещё не всё работало.

Наверное стоит ещё раз попробовать. Пока выкручивался снэпшотами.

E_STRICT Nov 28 2014 at 11:13

config.vm.synced_folder будет тормозить сильно
www.midwesternmac.com/blogs/jeff-geerling/nfs-rsync-and-shared-folder

kiaplayer Nov 28 2014 at 11:18

Да, поэтому я описал два варианта хранения проекта в виртуальной машине: в общем каталоге или в домашнем каталоге пользователя приложения (в разделе «Настройка каталога проекта»).

Fesor Nov 28 2014 at 19:56

nfs/smb намного лучше. Единственный плюс родных шаред фолдеров virtualbox — они работают и на win и на nix и не нужно делать if-ов в вагрант файле. Скажем если в команде есть кто-то на windows можно сделать так:

  is_windows = Vagrant::Util::Platform.windows?

  if is_windows
    config.vm.synced_folder ".", "/vagrant", type: "smb"
  else
    config.vm.synced_folder ".", "/vagrant", type: "nfs", mount_options: ['rw', 'vers=3', 'tcp', 'fsc' ,'actimeo=2']
  end

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

shushu Nov 28 2014 at 13:58

Я себе делал скрипт в external tool, который делал rsync и рисовал прогресс бар в шторме. Но всё равно медленновато получается.
Хочется что бы синхронизация мгновенная была. Но решения я пока не нашел.

kiaplayer Nov 28 2014 at 14:13

А чем не подошел deployment-сервер в шторме, описанный в разделе «Настройка каталога проекта»? Сохраняемые файлы автоматически выгружаются в виртуалку, достаточно оперативно получается.

shushu Nov 28 2014 at 15:44

Deployment-сервер еще медленнее.
Особенно это видно когда деплоишь изменения на сервер после git-пулла. Он все файлы просто копирует на сервер.

kiaplayer Nov 28 2014 at 16:05

В этом случае я делаю «git pull» внутри VM.
Правда, перед этим приходится делать «git reset --hard && git clean -fd».

E_STRICT Nov 28 2014 at 17:03

Попробуйте установить nfs сервер на гостевую машину
habrahabr.ru/post/211887/#comment_7292017

windoctor Nov 28 2014 at 11:22

Я думаю, что реализация Homestead гораздо проще, ничего не надо делать, только один раз прописать пути до проекта и все.

kiaplayer Nov 28 2014 at 11:35

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

Fesor Nov 28 2014 at 19:49

Чиф не самая простая штука для рядового PHP-шника не интересующегося всем этим devops стафом. Можно для провиженинга виртуальной машины использовать ansible или puppet. Так же если вам лень делать провиженинг руками можно воспользоваться сервисами phansible.com и puphpet.com/.

kiaplayer Nov 29 2014 at 20:29

Не вижу особой разницы в сложности между Puppet/Ansible/Chef.
Описанный мною сценарий мы успешно применяем в командной разработке, при этом разработчикам не нужно разбираться в рецептах Chef, за них это сделал тимлид. Максимум нужно понимать настройки в JSON-файле и уметь делать «vagrant up» :)

Daedmen Dec 1 2014 at 01:40

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

hlogeon Dec 1 2014 at 08:17

Не очень понимаю, зачем столько телодвижений.
У меня обычный 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

И для нового разработчика все развертывание проекта:

git clone project
cd project
vagrant up

kiaplayer Dec 1 2014 at 09:15

Да, вы правы, можно делать provision с помощью shell-скриптов.
Но для сложных конфигураций это может оказаться сложнее, так как Chef из коробки обеспечивает идемпотентность и имеет наборы готовых рецептов для всех популярных пакетов. То есть банально меньше кода получается :)

dotzero Dec 1 2014 at 10:06

В том-то и проблема, что имеет кукбуки только для популярных пакетов, а для каких-то специфических приходится либо писать свои кукбуки (что лично у меня каждый раз вызывает припадки ненависти к руби), либо использовать тотже самый bash провиженинг.

kiaplayer Dec 1 2014 at 10:21

Можно использовать альтернативный подход: для популярных пакетов использовать Chef cookbooks, а специфические вещи настраивать с помощью shell-скриптов (Vagrant поддерживает запуск нескольких provisioner'ов последовательно).

ilyarsoftware Dec 23 2014 at 02:40

Спасибо за статью, полезный материал.

Когда решал подобный вопрос, мне не давало покоя необходимость изучать дополнительный инструмент (несомненно полезный), необходимость поддерживать актуальное стояние Chef-конфига и держать целую структуру и только для того что бы поднять локальную ВМ. Особенно убивало то, что проверенный конфиг не всегда отрабатывал и приходилось фиксить. Предположу, что вопрос актуальности Chef-конфига на текущий момент может решить пакетный менеджер для Chef (librarian, berkshelf или что там сейчас в апстриме...).

В результате остановился на provision с помощью shell-скриптов, это позволило решить задачу одним файлом Vagrantfile, ничего особенного, но может быть, будет полезно не только мне.

Я понимаю полезность использования Chef и подобных ему инструментов, по возможности изучаю данную тему на предмет повседневного использования. Хочется получить ответы от пользователей Chef на вопросы:

Возможно описать настройку Vagrant одним файлом используя Chef?
Какую методику можно переменить что бы быть уверенным в том что Chef-кофиг ~~не протухнет~~ будет актуальным?
Есть успешный и комфортный опыт использования Chef для развертывания, как рабочего окружения так и локального на Vagrant?

E_STRICT Dec 23 2014 at 07:17

В результате остановился на provision с помощью shell-скриптов

Попробуйте ansible. Он более понятный и не требует знания руби или питона.

ilyarsoftware Dec 23 2014 at 10:33

Возможно описать настройку Vagrant одним файлом используя ansible?

Fesor Dec 23 2014 at 11:14

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

Другой вопрос что одним файлом все делать попросту глупо. Обычно разделяют все на отдельные реюзабельные стэпы (роли) и в плэйбуках или переменных настраивать уже под проект. Ролей готовых на том же ансибл гэлэкси пруд пруди, только выбирать тяжко и надо проверять каждую.

Но если хотите все одним файлом — Docker. Там будет вам один файл, в котором простым bash скриптом провиженится контейнер и он же поднимается. Но тогда придется что-то еще для деплоя использовать что бы там поднимать ваши контейнеры.

E_STRICT Dec 23 2014 at 14:25

Нет. А зачем это нужно?

ilyarsoftware Dec 23 2014 at 15:06

Для удобства использования и поддержки. Пример старта проекта в vagrant:

$ cd project
$ wget http://ilyar.github.io/localserver/Vagrantfile
$ vagrant up
$ open http://project.local

Минимальная область видимости, просто изменять, стабильный результат.

E_STRICT Dec 23 2014 at 19:08

wget http://ilyar.github.io/localserver/Vagrantfile

можно заменить на

git clone https://github.com/ilyar/localserver.git

Не совсем понятно про какую область видимости идёт речь и в чём заключается удобство использования и поддержки в таком случае.

ilyarsoftware Dec 23 2014 at 19:43

Такая замена, не корректна, в примере скачиваем один файл Vagrantfile в существующий проект поэтому именно:

wget http://ilyar.github.io/localserver/Vagrantfile

Под областью видимости, в данном случае, я имею ввиду, что конфигурация виртуальной машины реализована одним файлом (подробнее ilyar.github.io/localserver/), конечный результат почти аналогичен описываемому в статье.

Fesor Dec 23 2014 at 20:51

С тем же успехом можно просто запустить vagrant init ubuntu/trusty

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

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

А еще есть phansible.com и подобные.

ilyarsoftware Dec 23 2014 at 21:27

Спасибо за ссылку, она несомненно пригодится. Без спорно инструменты 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)
Apache 2
MySQL 5.5
PHP 5.5 (with modules: apc, memcached, cli, curl, gd, imap, mysql, mcrypt, sqlite, xdebug, xsl, pear, intl, tidy, readline) and tools:
- phpmyadmin http://localserver/phpmyadmin/
- composer — Dependency Manager for PHP
- composer-asset-plugin — NPM/Bower Dependency Manager for Composer
- php-cs-fixer — PHP Coding Standards Fixer
NodeJs (node, npm, bower)

Еще раз на примере реального проекта на Yii, для того что бы разработчику получить локально действующий проект, достаточно выполнить:

$ git clone https://github.com/ilyar/imotlib.git
$ cd imotlib
$ vagrant up
$ open http://imotlib.local/

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

E_STRICT Dec 23 2014 at 22:28

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

ansible это не язык программирования на изучение которого может понадобится несколько недель. 1 — 2 вечера достаточно для того чтобы понять как это работает и сделать свою простую сборку на подобии того что у вас в bash файле.

ilyarsoftware Dec 24 2014 at 05:01

Хороший аргумент, посмотрю на досуге.

E_STRICT Dec 23 2014 at 22:51

Конкретно для вашего проекта bash может быть вполне уместным. Но если конфигурация станет по сложней, то это будет уже не удобно. Представьте как будет выглядеть допустим вот эта сборка если её поместить целиком в Vagrantfile.

ilyarsoftware Dec 24 2014 at 05:05

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

kiaplayer Dec 23 2014 at 08:33

Возможно описать настройку Vagrant одним файлом используя Chef?

Методика использования Chef основана на использовании cookbook'ов — готовых наборов рецептов. Поэтому настройка сервера так или иначе будет размазана по этим рецептам.

Какую методику можно переменить что бы быть уверенным в том что Chef-кофиг не протухнет будет актуальным?

В описанном мной подходе как раз используется менеджер зависимостей «librarian», который фиксирует версии cookbook'ов в lock-файле. Версия самого Chef также фиксируется с помощью плагина (это описано в начале статьи).

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

В нашей команде мы разворачиваем и dev и prod, см. комментарий.

not_ice Dec 1 2014 at 08:48

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

kiaplayer Dec 1 2014 at 10:18

Да, можно. Методика описана тут: vagrant-php-deploy.

Суть вкратце такова: конфиги production-сервера хранятся в отдельном репозитории, который просто подключается в основной репозиторий проекта. Это позволяет разделить конфиги между разработчиками и системными администраторами.

Если необходимости в таком разделении нет, то можно настройки production-сервера добавить в ".chef/nodes" и немного поправить пути в скрипте «deploy.sh».

maxatwork Dec 1 2014 at 22:40

Use the docker, Luke!

Fesor Dec 1 2014 at 23:05

Чувакам на шиндовсе и на маках придется таки использовать еще и vagrant.

maxatwork Dec 2 2014 at 00:04

Use the boot2docker, Luke!
Хотя внутри это, конечно, тот же самый VirtualBox, только сделано все гораздо незаметнее, чем Vagrant.