Website development
PHP
Yii
Comments 42
+2
Если пользуетесь linux-системой, можно использовать LXC — экономичнее и быстрее работает
0
Я пользуюсь Windows + Git Bash. Можно использовать другой provider вместо VirtualBox, для этого нужно внести изменения в Vagrantfile.
0
Пытался настроить Vagrant с Hyper-V. Как-то не получилось. Может есть у кого такой опыт?
0
Есть, работает из коробки, но нужен установленный hyper-v на windows 8.1 или 2012r2. Только мало боксов для hyperv на vagrantcloud
Нужно поставить последний vagrant для windows, затем найти подходящий бокс и сделать init, например так:
vagrant init hashicorp/precise64

И затем 
vagrant up --provider hyperv

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

Наверное стоит ещё раз попробовать. Пока выкручивался снэпшотами.
0
Да, поэтому я описал два варианта хранения проекта в виртуальной машине: в общем каталоге или в домашнем каталоге пользователя приложения (в разделе «Настройка каталога проекта»).
0
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 допустим. Но для разработки штука бесполезная.
0
Я себе делал скрипт в external tool, который делал rsync и рисовал прогресс бар в шторме. Но всё равно медленновато получается.
Хочется что бы синхронизация мгновенная была. Но решения я пока не нашел.
0
А чем не подошел deployment-сервер в шторме, описанный в разделе «Настройка каталога проекта»? Сохраняемые файлы автоматически выгружаются в виртуалку, достаточно оперативно получается.
0
Deployment-сервер еще медленнее.
Особенно это видно когда деплоишь изменения на сервер после git-пулла. Он все файлы просто копирует на сервер.
0
В этом случае я делаю «git pull» внутри VM.
Правда, перед этим приходится делать «git reset --hard && git clean -fd».
0
Я думаю, что реализация Homestead гораздо проще, ничего не надо делать, только один раз прописать пути до проекта и все.
0
Homestead проще, но не дает такого контроля. Грубо говоря, Homestead — это черный ящик. Предложенный же вариант позволяет самому выбрать, какие пакеты будут установлены, какие конфиги они будут использовать. И все это будет прозрачно для всех членов команды.
+2
Чиф не самая простая штука для рядового PHP-шника не интересующегося всем этим devops стафом. Можно для провиженинга виртуальной машины использовать ansible или puppet. Так же если вам лень делать провиженинг руками можно воспользоваться сервисами phansible.com и puphpet.com/.
0
Не вижу особой разницы в сложности между Puppet/Ansible/Chef.
Описанный мною сценарий мы успешно применяем в командной разработке, при этом разработчикам не нужно разбираться в рецептах Chef, за них это сделал тимлид. Максимум нужно понимать настройки в JSON-файле и уметь делать «vagrant up» :)
0
Я бы еще с помощью aptly или чего-то такого же сделал бы копию репозитарий откуда пакеты ставятся, что бы гарантированно одни и те же пакеты прилетали
+2
Не очень понимаю, зачем столько телодвижений.
У меня обычный 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
+1
Да, вы правы, можно делать provision с помощью shell-скриптов.
Но для сложных конфигураций это может оказаться сложнее, так как Chef из коробки обеспечивает идемпотентность и имеет наборы готовых рецептов для всех популярных пакетов. То есть банально меньше кода получается :)
0
В том-то и проблема, что имеет кукбуки только для популярных пакетов, а для каких-то специфических приходится либо писать свои кукбуки (что лично у меня каждый раз вызывает припадки ненависти к руби), либо использовать тотже самый bash провиженинг.
+1
Можно использовать альтернативный подход: для популярных пакетов использовать Chef cookbooks, а специфические вещи настраивать с помощью shell-скриптов (Vagrant поддерживает запуск нескольких provisioner'ов последовательно).
0
Спасибо за статью, полезный материал.

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

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

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

  • Возможно описать настройку Vagrant одним файлом используя Chef?
  • Какую методику можно переменить что бы быть уверенным в том что Chef-кофиг не протухнет будет актуальным?
  • Есть успешный и комфортный опыт использования Chef для развертывания, как рабочего окружения так и локального на Vagrant?
0
В результате остановился на provision с помощью shell-скриптов
Попробуйте ansible. Он более понятный и не требует знания руби или питона.
0
Чисто теоритически, минимум два файла. Плэйбук, по которому будет происходить провиженинг, и инвентори файл, в котором расписана какие серваки какие и как к ним коннектится (доступы, ключи и т.д.)

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

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

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


Минимальная область видимости, просто изменять, стабильный результат.
0 
wget http://ilyar.github.io/localserver/Vagrantfile
можно заменить на
git clone https://github.com/ilyar/localserver.git

Не совсем понятно про какую область видимости идёт речь и в чём заключается удобство использования и поддержки в таком случае.
0
Такая замена, не корректна, в примере скачиваем один файл Vagrantfile в существующий проект поэтому именно:

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

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

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

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

А еще есть phansible.com и подобные.
0
Спасибо за ссылку, она несомненно пригодится. Без спорно инструменты 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:


  • NodeJs (node, npm, bower)


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

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

В результате имеем настроенное рабочее окружение и проинициализированный проект, разработчику останется только писать код. При необходимости он может поправить настройку ВМ и для этого не потребуется изучать что то дополнительно, потому что все в одном месте с использованием родного bash.
+1
без наличия в команде соответствующего специалиста, применять их будет сложно
ansible это не язык программирования на изучение которого может понадобится несколько недель. 1 — 2 вечера достаточно для того чтобы понять как это работает и сделать свою простую сборку на подобии того что у вас в bash файле.
0
Конкретно для вашего проекта bash может быть вполне уместным. Но если конфигурация станет по сложней, то это будет уже не удобно. Представьте как будет выглядеть допустим вот эта сборка если её поместить целиком в Vagrantfile.
0
Представил, «вот эта сборка» сложной не будет, но могу согласится с тем что такое возможно, пока не сталкивался, предвкушая возможные осложне��ия, посматриваю в сторону соответствующих инструментов.
0
Возможно описать настройку Vagrant одним файлом используя Chef?
Методика использования Chef основана на использовании cookbook'ов — готовых наборов рецептов. Поэтому настройка сервера так или иначе будет размазана по этим рецептам.

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

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

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

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

Если необходимости в таком разделении нет, то можно настройки production-сервера добавить в ".chef/nodes" и немного поправить пути в скрипте «deploy.sh».
0
Чувакам на шиндовсе и на маках придется таки использовать еще и vagrant.
0
Use the boot2docker, Luke!
Хотя внутри это, конечно, тот же самый VirtualBox, только сделано все гораздо незаметнее, чем Vagrant.
Only those users with full accounts are able to leave comments., please.
Language settings
Desktop version
© 2006–2019 «TM»