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

    Под впечатлением статьи 5 Easy Ways to Get Started with PHP on Vagrant хочу поделиться своим способом использования Vagrant для PHP-проекта.

    Чего хотелось достигнуть:
    • На машине разработчика устанавливаются только Vagrant и VirtualBox;
    • Настройки виртуальной машины хранятся в репозитории проекта, позволяя разработчику быстро её разворачивать, а также гибко настраивать под нужды проекта и делиться этими настройками с членами команды;

    Этих целей удалось достигнуть с помощью Chef-Solo. Получилась некая заготовка как для создания новых проектов на её основе, так и для интеграции в неё уже существующих проектов: vagrant-php.



    Сценарий работы с таким проектом для нового члена команды очень прост:

    1. Необходимо установить Vagrant и VirtualBox, а также несколько плагинов Vagrant:
      $ vagrant plugin install vagrant-librarian-chef-nochef vagrant-omnibus
      
    2. Загрузить проект из репозитория:
      $ git clone repo path
    3. Скопировать Vagrantfile и запустить виртуальную машину:
      $ cd path
      $ cp .chef/Vagrantfile Vagrantfile
      $ vagrant up
      

    Всё, виртуалка развернулась, пакеты установились, приложение работает!

    Плагин «vagrant-librarian-chef-nochef» предназначен для загрузки внешних cookbook'ов Chef'а и управления их зависимостями без установки самого Chef'а на локальную машину. Этот плагин позволяет не хранить внешние cookbook'и в своем репозитории, а загружать их при первом включении виртуальной машины.

    Плагин «vagrant-omnibus» позволяет указать конкретную версию Chef, которая будет установлена в виртуальную машину (это позволяет использовать практически любой образ с vagrantcloud.com, а также дает возможность зафиксировать версию Chef).

    Что внутри?


    • Ubuntu Trusty 14.04 (32 bit, current);
    • Nginx (последняя версия из Nginx PPA);
    • PHP 5.6 (из ondrej PPA), Composer;
    • Memcached (из стандартного репозитория Ubuntu);
    • MySQL 5.5 (из стандартного репозитория Ubuntu);
    • PostgreSQL 9.3 (из PostgreSQL PPA).

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

    Как интегрировать данное окружение со своим PHP-проектом?


    Если есть существующий PHP-проект, то необходимо загрузить проект из репозитория:
    $ git clone repo path
    

    Если же необходимо начать новый проект, то сначала необходимо создать каталог для него:
    $ mkdir path
    

    Затем нужно скопировать каталог ".chef" в каталог проекта и внести необходимые настройки в файл ".chef/nodes/10.2.2.10.json" (см. ниже про структуру json-файла) и ".chef/Vagrantfile".

    Теперь остается лишь скопировать файл ".chef/Vagrantfile" в корень проекта и запустить виртуальную машину:
    $ cd path
    $ cp .chef/Vagrantfile Vagrantfile
    $ vagrant up
    

    Если создается новый проект, то необходимо войти на виртульную машину через SSH под пользователем приложения (см. ниже про SSH доступ), установить проект с помощью Composer, а затем загрузить содержимое проекта из виртуальной машины в локальный каталог:
    $ composer create-project --prefer-dist yiisoft/yii2-app-basic /home/php-app/www
    

    Также желательно добавить строку "/Vagrantfile" в файл ".gitignore" проекта. Это позволит разработчику вносить локальные изменения в настройки виртуальной машины (например, уменьшать размер оперативной памяти), не отражая эти изменения в VCS.

    После этого следует проверить работоспособность проекта в виртуальном окружении и если проект работоспособен, то можно делать commit каталога проекта (в новый или уже существующий репозиторий).

    SSH доступ


    Зайти на виртуальную машину через SSH можно двумя способами:
    • Как администратор:
      $ vagrant ssh
    • Как пользователь, под которым развернуто приложение:
      $ ssh php-app@10.2.2.10 -i '.chef/files/id_rsa'

    По умолчанию вход по паролям выключен (параметр [«openssh»][«server»][«password_authentication»]), поэтому для входа под пользователем приложения используются ключи, указанные в параметре [«php-app»][«ssh»][«authorized_keys»]. В этом массиве перечислены полные пути к файлам на виртуальной машине. Так как каталог ".chef" монтируется в каталог "/tmp" виртуальной машины, то пути выглядят так: "/tmp/.chef/files/...". По умолчанию указан публичный ключ «id_rsa.pub», приватный ключ для которого лежит тут же под именем «id_rsa».

    Структура каталога ".chef"


    • files/ — каталог для хранения файлов, используемых в рецепте «php-app» (эти файлы доступны внутри виртуальной машины по пути "/tmp/.chef/files/");
    • nodes/ — каталог для хранения настроек виртуальных машин;
    • cookbooks/ — каталог для хранения загруженных внешних cookbook'ов (создается автоматически);
    • site-cookbooks/ — каталог для хранения внутренних cookbook'ов самого проекта;
    • tmp/ — временный каталог (создается автоматически);
    • Cheffile — зависимости для внутренних cookbook'ов (нужны для «librarian-chef»);
    • Cheffile.lock — зафиксированные версии cookbook'ов (файл создается автоматически);
    • solo.rb — файл настроек для Chef-Solo, запускаемого внутри виртуальной машины;
    • Vagrantfile — шаблон файла с настройками Vagrant (этот файл будет использоваться другими членами команды в качестве образца).

    Структура json-файла с настройками виртуальной машины


    В параметре «run_list» перечислены рецепты, которые будут выполнены при разворачивании машины и подготовке окружения. Все остальные параметры являются настройками соответствующих cookbook'ов.

    В каталоге ".chef/nodes" есть несколько готовых примеров для приложений на базе фреймворка Yii2:
    • yii2_advanced.json — настройки для разворачивания расширенного шаблона приложения Yii2;
    • yii2_basic.json — настройки для разворачивания базового шаблона приложения Yii2.

    Само окружение никак не завязано на Yii2, но эти настройки можно использовать в качестве примера.

    Cookbook «php-app» является локальным (расположен в ".chef/site-cookbooks" и комитится в репозиторий проекта) и предназначен для разворачивания приложения на сервере. Он выполняет следующие действия:
    1. Создание для приложения отдельного системного пользователя (параметры [«php-app»][«user»] и [«php-app»][«group»]);
    2. Создание необходимых каталогов (параметры [«php-app»][«project_dir»] и [«php-app»][«log_dir»]);
    3. Создание отдельных php-fpm pool'ов для приложения (параметр [«php-app»][«php»][«pools»]);
    4. Создание виртуальных хостов Nginx (параметр [«php-app»][«vhosts»]);
    5. Добавление записей в локальный hosts-файл виртуальной машины (параметр [«php-app»][«hosts»]);
    6. Создание баз данных (параметры [«php-app»][«mysql»] и [«php-app»][«pgsql»]);
    7. Загрузка проекта из git-репозитория (при необходимости, см. раздел про расположение проекта);
    8. Установка Composer и всех зависимостей проекта (параметр [«php-app»][«composer»]);
    9. Выполнение произвольных команд (параметр [«php-app»][«init_commands»]).

    Данный сценарий описан в файле ".chef/site-cookbooks/php-app/recipes/default.rb" и снабжен комментариями. В процессе разработки приложения этот сценарий может дополняться новыми действиями.

    Если в вашем PHP-проекте используется Composer, то в json-файле необходимо заполнить параметр [«php-app»][«composer»][«github_auth_token»], иначе зависимости проекта не будут установлены из-за ограничений Github API. Сгенерировать данный токен можно в настройках аккаунта Github.

    Полный список возможных настроек cookbook'а «php-app» можно увидеть в файле ".chef/site-cookbooks/php-app/attributes/default.rb".

    Настройка каталога проекта


    Расположение каталога проекта в виртуальной машине регулируется параметром [«php-app»][«project_dir»]. Обычно вместе с этим параметром необходимо изменить и параметр [«php-app»][«vhosts»][«variables»][«root»], чтобы виртуальный хост указывал на правильный каталог.

    Варианты расположения каталога проекта:
    • Проект расположен в общем каталоге (в каталоге "/vagrant" виртуальной машины, равному локальному каталогу проекта);
    • Проект расположен вне общего каталога (например, в "/home/php-app/www").

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

    Недостатки этого варианта:
    • В общем каталоге для всех файлов используется одинаковый режим доступа на стороне виртуальной машины (по умолчанию «777»);
    • В общем каталоге не учитывается регистр имен файлов (если на локальной машине используется Windows);
    • Для создания символических ссылок в общем каталоге требуется запуск виртуальных машин с правами администратора локальной машины (если на локальной машине используется Windows);
    • Если разработчик использует Linux на локальной машине, то дисковые операции с общим каталогом будут крайне медленными (эту проблему можно решить, настроив доступ к общему каталогу через NFS в Vagrantfile).

    Расположение проекта вне общего каталога (например, в "/home/user/www") позволяет приблизится к условиям реального сервера, но тоже имеет некоторые недостатки:
    • Разработчику необходимо позаботиться о синхронизации файлов между локальной и виртуальной машиной (переключение между ветками проекта также придется делать дважды — в локальном каталоге проекта и внутри виртуальной машины);
    • Локальные git-комиты не будут доступны в виртуальной машине.

    Если проект будет расположен вне общего каталога, то в json-файле необходимо заполнить параметр [«php-app»][«git»][«repository»] для загрузки проекта при подготовке виртуальной машины. Для доступа к репозиторию будет использоваться приватный ключ, указанный в параметре [«php-app»][«ssh»][«deployment_key»].

    В IDE PhpStorm/IDEA есть возможность настроить deployment-сервер. В этом случае изменения локальных файлов проекта будут автоматически выгружаться в виртуальную машину.

    Для этого необходимо добавить deployment-сервер (с помощью кнопки «Add» в меню «File — Settings — Deployment») со следующими настройками (некоторые настройки зависят от настроек в json-файле):
    • Type: SFTP
    • SFTP host: 10.2.2.10
    • Port: 22
    • Root path: /home/php-app/www
    • User name: php-app
    • Auth type: Key pair (OpenSSH)
    • Private key file: каталог_проекта/.chef/files/id_rsa
    • Passphrase:
    • Web server root URL: demo.local
    • Deployment path on server: /
    • Web path on server: /

    Затем нужно назначить добавленный сервер сервером по умолчанию (с помощью кнопки «Use as Default» в меню «File — Settings — Deployment») и установить значение параметра «Upload changed files automatically to the default server» равным «Always» или «On explicit save action» (в окне «File — Settings — Deployment — Options»).

    Настройка MySQL-сервера


    Для настройки MySQL-сервера используется внешний cookbook «mysql», поэтому для изменения стандартных настроек необходимо использовать ключ «mysql» в json-файле. По умолчанию MySQL-сервер доступен для внешних подключений по стандартному порту.

    В параметре [«php-app»][«mysql»][«root_connection»] необходимо указать параметры доступа для администратора баз данных. Пароль администратора устанавливается в параметре [«mysql»][«server_root_password»].
    Список создаваемых баз необходимо указать в ключе [«php-app»][«mysql»][«databases»]:
    {
        ...
        "php-app": [
            ...
            "mysql": {
                "root_connection": {
                    "host": "127.0.0.1", 
                    "username": "root", 
                    "password": "" 
                },
                "databases": [
                    {
                        "name": "yii2advanced", 
                        "username": "root", 
                        "password": "", 
                        "encoding": "utf8", 
                        "collation": "utf8_general_ci"
                    },
                    {
                        "name": "yii2_advanced_tests", 
                        "username": "root", 
                        "password": "", 
                        "encoding": "utf8", 
                        "collation": "utf8_general_ci"
                    }
                ]
            }
            ...
        ],
        ...
    }
    

    Настройка PosgtreSQL-сервера


    Для настройки PosgtreSQL-сервера используется внешний cookbook «postgresql», поэтому для изменения стандартных настроек необходимо использовать ключ «postgresql» в json-файле. По умолчанию PostgreSQL-сервер доступен для внешних подключений по стандартному порту.

    В параметре [«php-app»][«pgsql»][«root_connection»] необходимо указать параметры доступа для администратора баз данных. Пароль администратора устанавливается в параметре [«postgresql»][«password»][«postgres»]. Этот пароль не должен быть пустым.

    Список создаваемых баз необходимо указать в ключе [«php-app»][«pgsql»][«databases»]:
    {
        ...
        "php-app": [
            ...
            "pgsql": {
                "root_connection": { 
                    "host": "127.0.0.1", 
                    "username": "postgres", 
                    "password": "password" 
                },
                "databases": [
                    {
                        "name": "yii2advanced", 
                        "username": "yii2advanced", 
                        "password": "", 
                        "encoding": "UTF8", 
                        "collation": "en_US.UTF-8"
                    },
                    {
                        "name": "yii2_advanced_tests", 
                        "username": "yii2advanced", 
                        "password": "", 
                        "encoding": "UTF8", 
                        "collation": "en_US.UTF-8"
                    }
                ]
            }
            ...
        ],
        ...
    }
    

    Настройка отладки в PhpStorm/IDEA


    Чтобы иметь возможность отлаживать приложение, выполняемое внутри виртуальной машины, необходимо добавить PHP-сервер (с помощью кнопки «Add» в меню «File — Settings — PHP — Servers») со следующими настройками:
    • Name: demo.local
    • Host: demo.local
    • Port: 80
    • Debugger: Xdebug
    • Use path mappings: Включено (каталог проекта должен соответствовать каталогу [«php-app»][«project_dir»])

    Затем нужно создать configuration c типом «PHP Web application» (через пункт меню «Run — Edit configurations»), указав созданный PHP-сервер.

    Заключение


    Полученное окружение получилось достаточно гибким, все настроки ПО полностью прозрачны и настраиваемы. Использование Chef-Solo позволяет развернуть проект практически на любой машине (не обязательно виртуальной) за считанные минуты, при этом не требуя от разработчика никаких дополнительных действий.

    Буду рад услышать ваши комментарии.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 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 стоит, я с ним активно работаю. Но вот как-то не получилось завести. Или может когда я пробовал ещё не всё работало.

              Наверное стоит ещё раз попробовать. Пока выкручивался снэпшотами.
        +1
        config.vm.synced_folder будет тормозить сильно
        www.midwesternmac.com/blogs/jeff-geerling/nfs-rsync-and-shared-folder
          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
                Попробуйте установить nfs сервер на гостевую машину
                habrahabr.ru/post/211887/#comment_7292017
              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
                                Возможно описать настройку Vagrant одним файлом используя ansible?
                                  0
                                  Чисто теоритически, минимум два файла. Плэйбук, по которому будет происходить провиженинг, и инвентори файл, в котором расписана какие серваки какие и как к ним коннектится (доступы, ключи и т.д.)

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

                                  Но если хотите все одним файлом — Docker. Там будет вам один файл, в котором простым bash скриптом провиженится контейнер и он же поднимается. Но тогда придется что-то еще для деплоя использовать что бы там поднимать ваши контейнеры.
                                    0
                                    Нет. А зачем это нужно?
                                      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
                                                  Хороший аргумент, посмотрю на досуге.
                                                  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
                              Use the docker, Luke!
                                0
                                Чувакам на шиндовсе и на маках придется таки использовать еще и vagrant.
                                  0
                                  Use the boot2docker, Luke!
                                  Хотя внутри это, конечно, тот же самый VirtualBox, только сделано все гораздо незаметнее, чем Vagrant.

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое