Как стать автором
Обновить

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

поставил линукс @ напиши пост…

А так, вы с этим постом опоздали лет эдак на 5..) Возвращайтесь, когда узнаете про Vagrant
Видимо вы дочитали статью только до установки системы в виртуалку — это ваше право.
Я таки прочитал ее полностью. У меня на работе тоже есть доступ к некоторым сайтам в виртуалках коллег. Однако, по прежнему, ничего нового и интересного.
Более того, о чем вообще можно говорить, если вы только недавно начали использовать системы контроля версий?
Кто вам сказал, что это произошло недавно?
Иначе подобных проблем бы не возникало. Для развёртывания БД достаточно было бы слить миграции и сидеры и одной кнопкой поднять нужное.

Да, безусловно статья интересна начинающим, но, увы (или наоборот к счастью) в реальной жизни таким уже очень давно не приходилось заниматься, всё делается проще и удобнее, благо жизнь не стоит на месте и появляются более удобные инструменты.
Для развёртывания БД достаточно было бы слить миграции и сидеры и одной кнопкой поднять нужное
Ну так распишите подробнее. Просьба из концовки статьи в силе.
Очень не люблю теоретиков, которые нахватались «умных слов» (как они сами думают), а на деле 2+2 сложить не могут.
Я не думаю что тут вообще есть о чём-то рассказывать, т.к. данный функционал есть как в виде отдельных либ, так и в виде куска ядра любого популярного (и не очень) фрейма.

Я думаю этого будет достаточно, чтоб понять весь смысл оных: laravel.com/docs/5.1/migrations#migration-structure Т.к. описание выглядит как «миграции нужны для версионирования структуры любой реляционной БД».
Кстати а зачем всё таки вам 2 сетевых интерфейса в виртуалке? Когда можно обойтись одним в режиме моста.
Все это похоже на какой то невероятный костыль. Если есть проблемы с развертыванием проекта на локальных машинах, то нужно не засахаривать среду, в которой он разварачивается, а сделать нормальное развертывание? Если конфиг слишком сложный, что его верстальщик не может осилить, то может следует его упротить(задача сильно не оригинальная)?

Под заголовком «Организация среды для совместной веб-разработки» ожидаешь увидешь историю успеха CI. Слабо себе представляю как будет удобнее отлаживать проект, запущенный в виртуалке, когда сам ты на хостовой системе.

Да и больших проблем разрабатывать веб проекты прямо под убунтой тоже не замечено.
Что плохого в «засахаривании среды»? Если потом развертывание любого проекта заключается в одной команде «git fetch».

Слабо себе представляю как будет удобнее отлаживать проект, запущенный в виртуалке, когда сам ты на хостовой системе.
В этом и прелесть этого подхода — вы все делаете в своей любимой IDE под Windows. И сразу видите результат под Linux. Без каких либо дополнительных телодвижений. Опять таки — никто не мешает настроить дополнительные инструменты — тот же xdebug например.
Отлаживать в моей любимой IDE под Ubuntu мне лично гораздо проще, чем наварачивать виртуальную машину с волшебными скриптами и пытатся потом там что то удаленно отладить, для каждого запуска синхронизируя все это.

И вообще говоря, также просто делать все это в той же любимой IDE под Windows или Mac, написав скрипт развертывания и инструкцию по настройке сайта. Если процесс элементарной отладки простого веб приложения требует таких усилий, то ваш проект стал невероятно громоздким уже независимо от того, что же он на самом деле из себя представляет.
Вам тоже советуем посмотреть а лучше поработать с Vagrant, а уже потом писать комментарии о том с чем работали, а не строить теории на диване. Кстати говоря дабы не засирать свою любимую или не очень бубунту так же рекомендуется использовать Vagrant…
Дабы не засирать свой любимый или не очень интернет советую внимательнее читать оригинальные комментарии. Кстати говоря вам советуем посмотреть, а лучше поработать с python-env.
Я ответил не к изначальному комменту а именно к тому к которому нужно… Из него прекрасно видно что вы не работали с Вагрантом и ему подобными инструментами.
Даже если бы это было так, это никак не отменяет того факта, что для решения проблем, обозначенных в сабже, виртуализация в любом ее виде не нужна.
Вообще в настройке удаленной отладки в случае с xdebug нет ничего сложного. Можно отлаживать хоть в виртуалке, хоть на выделенном сервере и все это с локальной машины.
В случае если у вас Linux, то гораздо проще насоздавать отдельные машины с необходимым вам стеком. Сегодня это может быть LAMP, завтра может быть ROR с Mongo.

Правда Vagrant я заменил бы на Docker. Как то не очень логично имея на борту ядро линукс эмулировать целый виртуальный компьютер чтобы там крутилось еще одно Linux ядро с вашим технологическим стеком. Тут лучше запускать контейнеры.
Puphpet вам в помощь. И не будет нужды делать свои костыли. Плюс вам верно написали вверху, что надо использовать vagrant для подобных вещей.
В нашей команде у разработчиков на компах сначала стояла винда, но постепенно все заменили ее на Ubuntu, это оказался самый простой и удобный вариант для нас.
Для решения проблемы с БД, посмотрите как устроены миграции в Laravel и в Symfony, также есть Liquibase
Вы не поверите, но вы изобрели невероятный костыль, когда можно ровно в 1 команду поднять аналогичную виртуальную среду при помощи vagrant и готового «бокса», к примеру — scotchbox.
Забавно — приложение на 300 метров не костыль, а два скрипта на 20 строк — костыль. Хабр, такой хабр.
Знаете — я еще из той эпохи динозавров, которые помнят, что чем меньше инструмент, тем лучше. И программы я стараюсь писать с оглядкой на используемую память.

А так да — обвесим комп некостыльными программами, че тормозит? не проблема докинем памяти, опять тормозит? не вопрос купим новую железку и так до бесконечности.
Смысл в том, что для вагранта есть кучу готовых образов под любые нужды и поддерживаются они большим сообществом. Кроме всего прочего вагрант позволяет предоставить доступ к своей виртуальной системе (и даже по ssh), даже если вы сидите за nat. Кроме всего прочего под вагрант написано немало плагинов, например, я пользуюсь vagrant-hostmanager и vagrant-vbguest, которые позволяют мне автоматически установить дополнения гостевой ос и прописать доменное имя сайта в моем hosts файле. Перечислять плюсы я могу слишком долго, а о минусах вам уже пытались рассказать выше. Вы предлагаете пилить под каждый случай отдельную систему с конфигурацией, мы же — использовать уже готовые инструменты, которые берут все проблемы на себя. Если вас не устраивает vagrant — используйте docker, хотя это и немного разного рода программы.
А VMware Workstation у вас ничео не весит чтоли? )
Ну так в случае с vagrant тоже придется иметь локальную систему виртуализации (виртуал бокс или вмваре — не суть). Это просто надстройка, причем чем-то это мне напоминает ситуацию с Word — 90 процентов юзеров пользуется им как блокнотом. Так же и с вагрантом этим — модная штука, но вот я не смог придумать ситуацию, зачем она мне могла бы понадобится. В 99% случаев, при разработке под веб с устоявшимся используемым стеком технологий, достаточно одной виртуалки. А если так, то это не более чем игрушка.

Радует, что не у всех мозги уже закостенели — и есть почти 4 десятка людей, добавивших статью в избранное. А значит не зря я это сюда выложил, хоть статью и заминусили.
То есть если вам оно ни к чему то и другим не нужно? )
Vagrant по сути удобная надстройка над имеющимися системами виртуализации, по сути также как Docker в роли удобной надстройки над LXC.

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

Помнится однажды я тоже экспериментировал с виртуализацией и запускал Virtualbox в headless-режиме из bash-скрипта. Этакий самопальный аналог вагранта. Все работает, но плюсов нет и сохраняется стойкое ощущение конструирования велосипеда при наличии популярной известной штуки решающей эти же самые проблемы.

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

P.S. Надо бы еще Ansible и ему подобные штуки в этом посте упомянуть.
Хм, так вопрос в том, что это мне начали доказывать тут, что мол я не правильно живу — изобретаю мол велосипед. Я никому не пытался навязать мое решение, как единственно правильное. Лично для меня, и команды с которой я работаю — оно отличное. Вот и все. Этим я и поделился. Повторюсь — ставить монстрообразный вагрант ради поднятия одной виртуалки — как по мне, полный бред. Тем, кому нужно больше виртуалок — выбирайте решения сами.
Вы поделились своим решением на популярнейшем ркскоязычном IT-ресурсе с живым коммюнити и естественно получили фидбек. Это естественно. Комментарии не стоит принимать близко к сердцу, но вот советы от более опытных товарищей могут пригодиться. Ведь довольно часто бывает что комментарии оказываются даже ценнее самой статьи.

Насчет Vagrant — вы ругаете продукт который даже не пробовали использовать.
BAV_Lug, на счет вагранта поясню — локально у меня хранится только конфиг для него. Дальше сам вагрант следит за тем, чтоб скачать актуальный образ с интернета (например с ubuntu), развернуть в нем веб стек и выполнить какие-то дополнительные операции. Плюс он сам следит за апдейтами образа и автоматически обновит его у всех в команде. Это еще один огромный плюс, благодаря которому я и использую его. А благодаря средствам типа puphpet и phansible, я могу за минуту сгенерировать конфиг (для системы развертывания типа puppet или ansible) под нужную мне конфигурацию, не растрачивая время на тестирование и отладку. Поиграться — интересно, я два месяца сам игрался так, а потом мне это надоело, я плюнул на все и стал использовать готовое. Вам я советую хотя бы ознакомиться с ним, авось понравится.
Всем читателям хаба «Виртуализация» несомненно очень интересно было наконец узнать, как пользоваться VMware Workstation.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории