VagrantWebdev — виртуальная среда для веб-разработки

в 21:24, , рубрики: php, vagrant, Веб-разработка, виртуальная машина, среда разработки, метки: , , ,

Вступительное слово

Изначально я разрабатывал этот проект для родной веб-студии. Я начинал разработку со следующими принципами:

  • Среда должна разворачиваться максимально просто, с этим должен справиться любой новичок-стажер или даже менеджер, если понадобится.
  • Среда должна обеспечивать меня и любого разработчика всем необходимым серверным ПО, при этом инкапсулируя его в виртуальной среде.
  • Сами файлы проектов должны находиться в каталоге, разделяемом хостом и виртуальной машиной, а именно в каталоге проектов IDE. Даже если разработчик — ярый сторонник текстовых редакторов и поклялся на крови, что никогда его жесткий диск не примет в себя ни одной IDE, ему этот принцип так же будет на руку.
  • Хост должен иметь доступ к СУБД, Memcache и Sphinx, запущенным на виртуальной машине, для проведения работ, не требующих «тяжелой артиллерии», а значит проводящихся прямо на машине разработчика — например, для разработки на Django или разработки утилит, общающихся с этими сервисами.
  • Должен быть легкий способ сделать резервную копию данных, спрятанных в виртуальной машине.

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

Для достижения поставленных целей я выбрал Vagrant, так как нет по моему скромному мнению более удачной утилиты для распространения виртуальных машин для разработки. Из списка базовых боксов я выбрал машину на моем любимом и очень популярном Debian Wheezy, к тому же размер выбранного бокса всего 295 Мб.

Проект находится на GitHub'е и ждет своего часа. Он обеспечивает:

  • Веб-сервер (Apache 2.2 + PHP 5.4),
  • Xdebug с возможностями удаленной отладки, профилирования и создания трейсов по триггеру,
  • СУБД: MySQL, PostgreSQL, Redis,
  • Memcache,
  • Sphinx с организацией удобной конфигурации с помощью conf.d.

Так же внутри установлены PHPUnit + DBUnit, Python 2, SQLite и еще некоторое количество приятных вещей. Этот набор сервисов обусловлен нашими потребностями, но если сообществу будет интересно видеть что-то еще — не думаю, что будет проблемой добавить это.

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

VagrantWebdev был протестирован на Windows и на Ubuntu 13.10, и я был бы очень благодарен за помощь в тестировании на других платформах.

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

Организация системы

Как я уже упоминал, в проекте используется Vagrant и бокс с Debian Wheezy, основанный на VirtualBox. Установка достаточно минималистичная, но вместе с тем в комплекте имеются Puppet и Chief, в связи с чем, если в будущем конфигурирование с помощью скрипта перестанет быть наиболее изящным решением, можно будет сменить способ без проблем со сменой бокса.

Параметры

Система имеет некоторое количество параметров, которые влияют одновременно на гостевую ОС, работу утилит и скрипт «провизии» — не знаю, такое ли значение слова «provision» имел в виду Митчел Хашимото, автор Vagrant'а, но мне нравится именно этот вариант.

Все параметры я решил вынести в единый файл, params.ini. Поскольку утилиты я писал на любимом Пайтоне, а выполняться они должны были либо на полноценном интерпретаторе, либо быть запакованными с помощью py2exe, особых проблем с разбором параметров не было, но вот передача параметров в Vagrantfile и далее оказалась проблемой.

То есть, конечно, не проблемой в плане сложности решения, а проблемой в плане сложности изящного решения, так как в Windows Vagrant использует собственный интерпретатор Ruby, в котором отсутствует встроенный модуль для парсинга ini-файлов, что повлекло необходимость изобретения собственного не слишком красивого и не слишком двухколесного велосипеда в виде модуля Params, который поддерживает только самые базовые возможности этого формата конфигураций, но в конкретном данном случае вполне справляется с задачей.

Для изменения доступны следующие параметры:

  • www_dir: каталог веб-проектов, который будет смонтирован в гостевой системе как /var/www. По умолчанию это %Home%htdocs для Windows и ~/htdocs для Unix-like систем.
  • vhosts_section_id: строка, используемая для идентификации «нашей» секции в файле hosts
  • box: название бокса в Vagrant'е
  • box_url: URL, откуда он будет скачан в случае, если данный бокс не установлен в системе
  • memory: объем оперативной памяти, доступной гостевой ОС, по умолчанию 2 Гб
  • server_ip: IP-адрес, по которому будет доступна машина в приватной сети, по умолчанию 192.168.2.10
  • use_smtp: нужно ли использовать доставку электронной почты на внешние домены через SMTP-сервер. По умолчанию присвоено значение 0, так как иной вариант требует от пользователя настройки параметров SMTP-сервера, а это противоречит принципу легкости развертывания даже неопытным пользователем.
  • Параметры SMTP-сервера, которые необходимо заполнить в случае его использования для доставки почты на внешние домены
Утилиты

Для повышения удобства работы со средой я разработал некоторые утилиты, которые, как упоминалось выше, обретаются в каталоге bin. Утилиты разделены на три каталога:
vagrant, обертки для команд утилиты Vagrant. Изначально утилиты этой группы создавались для удобства работы в графических интерфейсах, чтобы наиболее частые действие можно было выполнить двойным щелчком мыши, но позже некоторые из них взяли на себя ответственность за некоторые дополнительные действия, о которых я расскажу чуть позже.
utils — утилиты общего назначения, созданные для автоматизации некоторых важных задач и internal — утилиты, предназначенные для выполнения в гостевой ОС.

Сервисы

Веб-сервер

В данной системе используется классика: Apache 2.2 + PHP 5.4. Веб-сервер обеспечивает доступ к проектам в доменной зоне loc. Домены распределяются в соответствии с именем подкаталога www_dir. К примеру, если проект находится в каталоге /var/www/test, он будет доступен как test.loc и www.test.loc.

Есть три способа указать хосту, где искать домены этой зоны. Первый из них — добавить нужные записи в файл hosts. Для автоматизации этой задачи была разработана утилита PatchHosts. Она отлично справляется с задачей везде, кроме Windows 8.1, так как там запись в файл hosts затруднена даже с правами администратора. В случае ошибки доступа утилита открывает текстовый редактор с контентом, который необходимо скопировать в файл hosts, в Windows 8.1 его можно записать, например, с помощью Блокнота.

Второй способ более красив, но доступен только в случае, если в вашей системе имеется DNS-сервер или прокси для DNS-запросов — например, Dnsmasq. В этом случае можно указать ему явно, где искать домены зоны loc, для dnsmasq в проекте есть соответствующий файл конфигурации.

Ну и третий способ, который я бы не стал рекомендовать — указать в своей системе качестве DNS-сервера 192.168.2.10. В принципе, это может быть решением, но повлечет за собой необходимость менять настройки сети при каждом запуске и при каждой остановке виртуальной машины.

К сожалению, виртуальные хосты Apache так же обновляются лишь полуавтоматически. Изначально (ссылка на старый коммит) для этой цели использовался mod_vhost_alias; он был хорош и радовал изящностью решения, пока не всплыл очень неприятный баг, который оказался фатальным в случае выбранного стека технологий. Пришлось, скрепя сердце, перейти на явное добавление всех хостов в конфигурацию с помощью специальной утилиты. В качестве утешительного приза я сократил избыточность такого способа конфигурирования с помощью mod_macro, позволяющего использовать макросы при настройке Apache.

Для добавления виртуальных хостов в конфигурацию Apache служит утилита из каталога utils подназванием UpdateApacheVHosts. Она должна запускаться после изменения состава проектов; автоматически она запускается при использовании для запуска, перезагрузки или выхода из гибернации утилит из каталога vagrant.

Этот момент очень хотелось бы оптимизировать, я был бы рад любым идеям на этот счет.

Xdebug

Настройки этого расширения для PHP позволяют следующее:

  • Автоматическое обратное подключение к машине разработчика при отладке. Триггером для этого служит передача как параметра запроса или cookie переменной XDEBUG_SESSION_START=session_name. Очень удобная опция, особенно в совокупности с возможностями отладки в таких IDE как PhpStorm или NetBeans. Вам не надо настраивать Xdebug для подключения к определенному IP-адресу, достаточно того, чтобы IDE ожидала подключения на той же машине, с которой отправлен запрос.
  • Профилирование и создание трейса по триггеру. Для этого, как и в предыдущем случае, нужно передать переменные: XDEBUG_TRACE=1 и XDEBUG_PROFILE=1 соответственно. Файлы с результатами сохраняются в каталог %VagrantWebdev%/runtime/xdebug.
СУБД и Memcache

На данный момент в системе доступны следующие СУБД: MySQL, PostgreSQL и Redis. Все они доступны извне, что позволяет использовать VagrantWebdev не только для работы с LAMP-проектами, а так же использовать удобные инструменты для администрирования баз данных, такие как мои любимые HeidiSQL, pgAdmin и RedisDesktopManager.

Для пользователя root в MySQL и пользователя postgres в PostgreSQL установлен пароль password. Только пусть этот секрет останется между нами, хорошо?

Так же в проекте есть утилиты, облегчающие извлечение резервных копий данных. Это следующие утилиты из каталога utils: mysqldump, pg_dumpall и redis_dump. Результаты их работы сохраняются в каталог %VagrantWebdev%/runtime.

Memcache так же доступен извне, а для удобства его очистки в том же каталоге utils имеется утилита flush-memcache.

Все указанные утилиты отправляют в гостевую ОС команды посредством SSH. В основном их название отражает, что именно вызывается в гостевой ОС, вот, к примеру код утилиты mysqldump, версия для Unix-like:

#!/bin/bash
set -e

DIR=$( cd $( dirname "${BASH_SOURCE[0]}" ) && pwd )
cd "$DIR/../.."
vagrant ssh -c "mysqldump -uroot -ppassword --all-databases --set-charset --complete-insert > /vagrant/runtime/mysql-dump.sql" -- -T -n
read -p "Press [Enter] key to exit..."
Sphinx

При конфигурировании Sphinx был использован не всем известный трюк, существующий аж с тех времен, когда Sphinx не дорос еще даже до первой версии. Как известно, Sphinx не имеет средств для создания раздельной конфигурации с помощью ".d" каталога с помощью инструкций наподобие include. Но он может гораздо больше: если файл конфигурации является исполняемым скриптом, Sphinx выполняет его, а в качестве параметров использует то, что скрипт выдал в STDOUT.

Таким образом, с помощью PHP, который отлично показал себя в качестве препроцессора файлов конфигурации, была добавлена возможность раздельной конфигурации. В качестве примера я добавил в базовую поставку индекс information_schema, который собирает информацию по схемам, таблицам и колонкам всего, что есть в MySQL. Конфигурация разделена на два файла: собственно, конфигурация и файл с SQL-запросом для извлечения данных.

К примеру, вот так из него можно получить информацию обо всем, что связано с кодировкой UTF-8, которая больше известна во вселенной MySQL как utf8:

<?php
require __DIR__.'/lib/sphinxapi.php';

$client = new SphinxClient();
$client->SetServer('192.168.2.10', 9312);

$client->SetMatchMode(SPH_MATCH_ANY);
$data = $client->Query('utf8', 'information_schema');
?>
<ul>
    <? foreach ($data['matches'] as $record) { ?>
        <li>
            <p>Type: <?=$record['attrs']['type']?></p>
            <p>Name: <?=$record['attrs']['name']?></p>
        </li>
    <? } ?>
</ul>

Заключительное слово

Вот такой проект я предоставляю общественности. Хочется надеяться, что он поможет разработчикам за пределами нашего локального сообщества, или хотя бы мой рассказ о его особенностях поможет тем, кто решит связаться с чем-то из описанного.

Автор: Andre_487

Источник

Поделиться

* - обязательные к заполнению поля