И вот тут пришло понимание — среда должна быть максимально одинаковая у всех, при этом она должна быть и максимально приближенной к реальным условиям эксплуатации конечных продуктов. При этом нельзя лишать разработчиков их любимых IDE. Что бы там не говорили, но большинство разработчиков используют Windows, а конечные web хостинги с PHP — unix. Я в своей практике не раз натыкался на «грабли» — локально под Windows все работает — выкладываем на хостинг и все плохо.
Так я пришел к выводу — нужно организовать симбиоз Windows и Unix. Решение, в общем то, лежит на поверхности — виртуальная машина под windows, с любой unix-like системой внутри.
В качестве системы виртуализации был выбран VMware Workstation.
Добавляем к виртуальной машине две сетевых платы. Одна тип «NAT» (нужно же нашей виртуалке в инет ходить), другая тип «Только для узла». Через нее мы будем ходить с родительской машины.
В виртуалку был установлен Ubuntu Server (выбор исключительно основан на моих предпочтениях, плюс подкупает наличием, и своевременным обновлением, всех необходимых пакетов), плюс стандартный LAMP (инструкций по установке в интернете хватает). Пока ничего необычного.
А вот дальше немного «магии» по настройке этого хозяйства, так чтобы было всем удобно.
Обязательно устанавливаем VMware Tools в виртуалке. Создаем на любом локальном диске под Windows папку «web» (название может быть любым, но оно потом должно быть таковым у всех участников команды). Подключаем эту папку к виртуалке, как общую папку
Смотрим куда у нас она подключилась в системе
Видим, что точка монтирования "/mnt/hgfs".
Теперь нам нужно, чтобы папки из "/mnt/hgfs/web" автоматически подключались к apache.
В первую очередь добавляем в "/etc/apache2/sites-enabled" конфиг:
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /mnt/hgfs/web
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
Таким образом у нас получается, что любой из проект мы сможем открыть по адресу «httр://имя_сервера/имя_папки/». Но не всегда это удобно. А потому добавляем создание еще и локальных доменов.
Создаем файл "/root/web/elap.conf" следующего содержания:
<VirtualHost *:80>
ServerName domen
ServerAdmin webmaster@localhost
DocumentRoot path
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
<Directory "path">
Options Indexes FollowSymLinks MultiViews
AllowOverride all
Require all granted
</Directory>
</VirtualHost>
Затем пишем скрипт следующего содержания:
#!/bin/sh
workdir="/mnt/hgfs/web/"
apconf="/etc/apache2/sites-enabled/local.conf"
apelconf="/root/web/elap.conf"
echo > ${workdir}/local.conf
LIST=`find $workdir -maxdepth 1 -type d`
for PATH_DOMEN in $LIST
do
domen=`echo $PATH_DOMEN | sed s~${workdir}~~`
if !( test -z ${domen} ) then
cat ${apelconf} | sed s~domen~${domen}.local~ | sed s~path~${PATH_DOMEN}~ >> ${workdir}/local.conf
fi
done
dc=`diff $apconf ${workdir}/local.conf`
if !( test -z "${dc}" ) then
cat ${workdir}/local.conf > $apconf
/etc/init.d/apache2 restart
fi
И добавляем его в крон (я поставил на раз в минуту) — только вы создали новую папку в папке «web», пока из гита тянете в нее данные — домен в виртуалке вида «httр://имя_папки.local» уже подключен.
Теперь нам нужно, чтобы и Windows узнала об этих локальных доменах. Можно было пойти двумя путями — поднять в виртуалке днс сервер или воспользоваться файлом «hosts» в windows. Я решил пойти вторым путем.
Смотрим адрес который выдан на сетевую карту тип «Только для узла». К сожалению, для каждой инсталяции VMware он индивидуален (либо я не нашел как его зафиксировать), а потому, в последующем, при настройке этой связки на компьютерах членов команды, нужно его изменять. Одно радует — в последующем он не меняется уже локально.
Видим, что нужная нам сетевая карта «eth0» с адресом «192.168.81.128». Добавляем в «C:\Windows\System32\drivers\etc\hosts» следующую строку:
192.168.81.128 web
И пишем скрипт следующего содержания:
@echo off
set workdir=d:\webdir %workdir% /A:D /B > %workdir%list_project.txt
find /V ".local" C:\Windows\System32\Drivers\etc\hosts > %workdir%hosts_new
for /F %%i in (%workdir%list_project.txt) do (
echo 192.168.81.128 %%i.local >> %workdir%hosts_new
)
copy %workdir%hosts_new C:\Windows\System32\Drivers\etc\hosts
Теперь после добавления нового проекта в папку «web» нам необходимо один раз запустить этот скрипт от имени администратора (!!!) и локальный домен станет вам доступен.
Затем просто клонируем виртуалку всем сотрудникам.
Собственно такая система обкатана, и плодотворно работает. Осталась не решенной пока одна проблема — БД. Сейчас мы во всех проектах сохраняем БД в папке «sql» и при установке локальной копии проекта приходится вручную заливать базу. Возникают вопросы как отслеживать изменения в базе. Как оповещать о них. Если у вас есть решение — прошу в комментарии.
Комментарии (28)
kozzztik
24.07.2015 13:16+1Все это похоже на какой то невероятный костыль. Если есть проблемы с развертыванием проекта на локальных машинах, то нужно не засахаривать среду, в которой он разварачивается, а сделать нормальное развертывание? Если конфиг слишком сложный, что его верстальщик не может осилить, то может следует его упротить(задача сильно не оригинальная)?
Под заголовком «Организация среды для совместной веб-разработки» ожидаешь увидешь историю успеха CI. Слабо себе представляю как будет удобнее отлаживать проект, запущенный в виртуалке, когда сам ты на хостовой системе.
Да и больших проблем разрабатывать веб проекты прямо под убунтой тоже не замечено.
BAV_Lug Автор
24.07.2015 13:53Что плохого в «засахаривании среды»? Если потом развертывание любого проекта заключается в одной команде «git fetch».
Слабо себе представляю как будет удобнее отлаживать проект, запущенный в виртуалке, когда сам ты на хостовой системе.
В этом и прелесть этого подхода — вы все делаете в своей любимой IDE под Windows. И сразу видите результат под Linux. Без каких либо дополнительных телодвижений. Опять таки — никто не мешает настроить дополнительные инструменты — тот же xdebug например.kozzztik
24.07.2015 18:13-1Отлаживать в моей любимой IDE под Ubuntu мне лично гораздо проще, чем наварачивать виртуальную машину с волшебными скриптами и пытатся потом там что то удаленно отладить, для каждого запуска синхронизируя все это.
И вообще говоря, также просто делать все это в той же любимой IDE под Windows или Mac, написав скрипт развертывания и инструкцию по настройке сайта. Если процесс элементарной отладки простого веб приложения требует таких усилий, то ваш проект стал невероятно громоздким уже независимо от того, что же он на самом деле из себя представляет.
webportal
24.07.2015 21:32+1Вам тоже советуем посмотреть а лучше поработать с Vagrant, а уже потом писать комментарии о том с чем работали, а не строить теории на диване. Кстати говоря дабы не засирать свою любимую или не очень бубунту так же рекомендуется использовать Vagrant…
kozzztik
25.07.2015 05:03Дабы не засирать свой любимый или не очень интернет советую внимательнее читать оригинальные комментарии. Кстати говоря вам советуем посмотреть, а лучше поработать с python-env.
webportal
25.07.2015 18:12Я ответил не к изначальному комменту а именно к тому к которому нужно… Из него прекрасно видно что вы не работали с Вагрантом и ему подобными инструментами.
kozzztik
26.07.2015 19:15-1Даже если бы это было так, это никак не отменяет того факта, что для решения проблем, обозначенных в сабже, виртуализация в любом ее виде не нужна.
rhamdeew
26.07.2015 22:54Вообще в настройке удаленной отладки в случае с xdebug нет ничего сложного. Можно отлаживать хоть в виртуалке, хоть на выделенном сервере и все это с локальной машины.
В случае если у вас Linux, то гораздо проще насоздавать отдельные машины с необходимым вам стеком. Сегодня это может быть LAMP, завтра может быть ROR с Mongo.
Правда Vagrant я заменил бы на Docker. Как то не очень логично имея на борту ядро линукс эмулировать целый виртуальный компьютер чтобы там крутилось еще одно Linux ядро с вашим технологическим стеком. Тут лучше запускать контейнеры.
zenn
24.07.2015 14:46+1Вы не поверите, но вы изобрели невероятный костыль, когда можно ровно в 1 команду поднять аналогичную виртуальную среду при помощи vagrant и готового «бокса», к примеру — scotchbox.
BAV_Lug Автор
24.07.2015 17:27-3Забавно — приложение на 300 метров не костыль, а два скрипта на 20 строк — костыль. Хабр, такой хабр.
Знаете — я еще из той эпохи динозавров, которые помнят, что чем меньше инструмент, тем лучше. И программы я стараюсь писать с оглядкой на используемую память.
А так да — обвесим комп некостыльными программами, че тормозит? не проблема докинем памяти, опять тормозит? не вопрос купим новую железку и так до бесконечности.Ekstazi
24.07.2015 17:53+4Смысл в том, что для вагранта есть кучу готовых образов под любые нужды и поддерживаются они большим сообществом. Кроме всего прочего вагрант позволяет предоставить доступ к своей виртуальной системе (и даже по ssh), даже если вы сидите за nat. Кроме всего прочего под вагрант написано немало плагинов, например, я пользуюсь vagrant-hostmanager и vagrant-vbguest, которые позволяют мне автоматически установить дополнения гостевой ос и прописать доменное имя сайта в моем hosts файле. Перечислять плюсы я могу слишком долго, а о минусах вам уже пытались рассказать выше. Вы предлагаете пилить под каждый случай отдельную систему с конфигурацией, мы же — использовать уже готовые инструменты, которые берут все проблемы на себя. Если вас не устраивает vagrant — используйте docker, хотя это и немного разного рода программы.
rhamdeew
26.07.2015 22:55А VMware Workstation у вас ничео не весит чтоли? )
BAV_Lug Автор
26.07.2015 23:13Ну так в случае с vagrant тоже придется иметь локальную систему виртуализации (виртуал бокс или вмваре — не суть). Это просто надстройка, причем чем-то это мне напоминает ситуацию с Word — 90 процентов юзеров пользуется им как блокнотом. Так же и с вагрантом этим — модная штука, но вот я не смог придумать ситуацию, зачем она мне могла бы понадобится. В 99% случаев, при разработке под веб с устоявшимся используемым стеком технологий, достаточно одной виртуалки. А если так, то это не более чем игрушка.
Радует, что не у всех мозги уже закостенели — и есть почти 4 десятка людей, добавивших статью в избранное. А значит не зря я это сюда выложил, хоть статью и заминусили.rhamdeew
26.07.2015 23:22То есть если вам оно ни к чему то и другим не нужно? )
Vagrant по сути удобная надстройка над имеющимися системами виртуализации, по сути также как Docker в роли удобной надстройки над LXC.
С тем же вагрантом вы можете запилить единожды полностью настроенный образ с вашим стеком и для его поднятия новому разработчику нужно будет только пару команд в терминале ввести и поправить пути в конфиге. Это на самом деле удобно.
Помнится однажды я тоже экспериментировал с виртуализацией и запускал Virtualbox в headless-режиме из bash-скрипта. Этакий самопальный аналог вагранта. Все работает, но плюсов нет и сохраняется стойкое ощущение конструирования велосипеда при наличии популярной известной штуки решающей эти же самые проблемы.
Ваш реверанс в сторону комментаторов про закостенение мозгов честно говоря не понятен. Не думаю что будет хорошо если 4 десятка людей вместо того чтобы пользоваться нормальным софтом будут допиливать напильником ваш велосипед.
P.S. Надо бы еще Ansible и ему подобные штуки в этом посте упомянуть.BAV_Lug Автор
26.07.2015 23:48Хм, так вопрос в том, что это мне начали доказывать тут, что мол я не правильно живу — изобретаю мол велосипед. Я никому не пытался навязать мое решение, как единственно правильное. Лично для меня, и команды с которой я работаю — оно отличное. Вот и все. Этим я и поделился. Повторюсь — ставить монстрообразный вагрант ради поднятия одной виртуалки — как по мне, полный бред. Тем, кому нужно больше виртуалок — выбирайте решения сами.
rhamdeew
27.07.2015 00:03Вы поделились своим решением на популярнейшем ркскоязычном IT-ресурсе с живым коммюнити и естественно получили фидбек. Это естественно. Комментарии не стоит принимать близко к сердцу, но вот советы от более опытных товарищей могут пригодиться. Ведь довольно часто бывает что комментарии оказываются даже ценнее самой статьи.
Насчет Vagrant — вы ругаете продукт который даже не пробовали использовать.Ekstazi
27.07.2015 12:31BAV_Lug, на счет вагранта поясню — локально у меня хранится только конфиг для него. Дальше сам вагрант следит за тем, чтоб скачать актуальный образ с интернета (например с ubuntu), развернуть в нем веб стек и выполнить какие-то дополнительные операции. Плюс он сам следит за апдейтами образа и автоматически обновит его у всех в команде. Это еще один огромный плюс, благодаря которому я и использую его. А благодаря средствам типа puphpet и phansible, я могу за минуту сгенерировать конфиг (для системы развертывания типа puppet или ansible) под нужную мне конфигурацию, не растрачивая время на тестирование и отладку. Поиграться — интересно, я два месяца сам игрался так, а потом мне это надоело, я плюнул на все и стал использовать готовое. Вам я советую хотя бы ознакомиться с ним, авось понравится.
kabal375
24.07.2015 16:53+3Всем читателям хаба «Виртуализация» несомненно очень интересно было наконец узнать, как пользоваться VMware Workstation.
berezuev
поставил линукс @ напиши пост…
А так, вы с этим постом опоздали лет эдак на 5..) Возвращайтесь, когда узнаете про Vagrant
BAV_Lug Автор
Видимо вы дочитали статью только до установки системы в виртуалку — это ваше право.
berezuev
Я таки прочитал ее полностью. У меня на работе тоже есть доступ к некоторым сайтам в виртуалках коллег. Однако, по прежнему, ничего нового и интересного.
Более того, о чем вообще можно говорить, если вы только недавно начали использовать системы контроля версий?
BAV_Lug Автор
Кто вам сказал, что это произошло недавно?
SerafimArts
Иначе подобных проблем бы не возникало. Для развёртывания БД достаточно было бы слить миграции и сидеры и одной кнопкой поднять нужное.
Да, безусловно статья интересна начинающим, но, увы (или наоборот к счастью) в реальной жизни таким уже очень давно не приходилось заниматься, всё делается проще и удобнее, благо жизнь не стоит на месте и появляются более удобные инструменты.
BAV_Lug Автор
Очень не люблю теоретиков, которые нахватались «умных слов» (как они сами думают), а на деле 2+2 сложить не могут.
SerafimArts
Я не думаю что тут вообще есть о чём-то рассказывать, т.к. данный функционал есть как в виде отдельных либ, так и в виде куска ядра любого популярного (и не очень) фрейма.
Я думаю этого будет достаточно, чтоб понять весь смысл оных: laravel.com/docs/5.1/migrations#migration-structure Т.к. описание выглядит как «миграции нужны для версионирования структуры любой реляционной БД».
webportal
Кстати а зачем всё таки вам 2 сетевых интерфейса в виртуалке? Когда можно обойтись одним в режиме моста.