kiaplayer28 ноя 2014 в 08:00

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

9 мин

49K

Веб-разработка * PHP * Yii *

Комментарии 42

Vidog 28 ноя 2014 в 08:11

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

kiaplayer 28 ноя 2014 в 09:39

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

VadNov 1 дек 2014 в 03:33

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

gollumrsdn 2 дек 2014 в 12:52

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

vagrant init hashicorp/precise64

И затем

vagrant up --provider hyperv

VadNov 2 дек 2014 в 12:58

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

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

E_STRICT 28 ноя 2014 в 08:13

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

kiaplayer 28 ноя 2014 в 08:18

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

Fesor 28 ноя 2014 в 16: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 28 ноя 2014 в 10:58

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

kiaplayer 28 ноя 2014 в 11:13

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

shushu 28 ноя 2014 в 12:44

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

kiaplayer 28 ноя 2014 в 13:05

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

E_STRICT 28 ноя 2014 в 14:03

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

windoctor 28 ноя 2014 в 08:22

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

kiaplayer 28 ноя 2014 в 08:35

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

Fesor 28 ноя 2014 в 16:49

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

kiaplayer 29 ноя 2014 в 17:29

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

Daedmen 30 ноя 2014 в 22:40

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

hlogeon 1 дек 2014 в 05: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 1 дек 2014 в 06:15

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

dotzero 1 дек 2014 в 07:06

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

kiaplayer 1 дек 2014 в 07:21

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

ilyarsoftware 22 дек 2014 в 23:40

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

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

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

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

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

E_STRICT 23 дек 2014 в 04:17

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

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

ilyarsoftware 23 дек 2014 в 07:33

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

Fesor 23 дек 2014 в 08:14

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

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

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

E_STRICT 23 дек 2014 в 11:25

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

ilyarsoftware 23 дек 2014 в 12:06

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

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

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

E_STRICT 23 дек 2014 в 16:08

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

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

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

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

ilyarsoftware 23 дек 2014 в 16:43

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

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

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

Fesor 23 дек 2014 в 17:51

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

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

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

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

ilyarsoftware 23 дек 2014 в 18: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 23 дек 2014 в 19:28

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

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

ilyarsoftware 24 дек 2014 в 02:01

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

E_STRICT 23 дек 2014 в 19:51

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

ilyarsoftware 24 дек 2014 в 02:05

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

kiaplayer 23 дек 2014 в 05:33

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

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

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

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

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

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

not_ice 1 дек 2014 в 05:48

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

kiaplayer 1 дек 2014 в 07:18

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

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

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

maxatwork 1 дек 2014 в 19:40

Use the docker, Luke!

Fesor 1 дек 2014 в 20:05

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

maxatwork 1 дек 2014 в 21:04

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий