Привет, Хабр!) Тем, кто пока не имеет представления, советую почитать предыдущую статью А если кратко, то речь пойдет об окружении для локальной веб разработки, которое полностью настроено и готово для запуска большинства фреймворков и cms. Запускайте Symfony, Laravel, Yii2, и другие фреймворки легко! По принципу клонировал -> запустил. Забудьте про постоянные настройки веб сервера и рабочего окружения. Все что вам нужно уже есть в Stacker
Основные лозунги проекта
Их много — он один!
Все просто, не нужно миграций!
Быстро развернул и начал работать!
Хватит настраивать! Пиши код!
Держи зоопарк под Docker, пусть хостовая машина остается чистой!
Релиз v0.4 что нового?
- Первое, что хотелось бы отметить, взят курс на универсальность. Если раньше прицел был исключительно на Symfony, то теперь это еще и Yii2 и Laravel и многие другие известные фреймворки.
- Мы добавили в сборку новую крутую консоль ZSH в купе с oh-my-zsh Кто знает тот знает, что это, и об этом вкратце не напишешь, а кто не знает, тот просто обязан с этим ознакомится.
- Добавлена поддержка старых версий php + apache2 проекты под ним живут на 81-ом порту
- Для фронтенд разработчиков добавлена поддержка cli для: nodejs, npm, bower, gulp, uglify-js, uglifycss и этот список растет в соответствии с фидбеком.
- Для бекендеров в cli тоже много полезностей это: composer, gem, php, phpunit, symfony, symfony-autocomplete, Yii2 autocomplete — также ждем от вас фидбека.
- Частично причесана структура и файлы для сборки, работа идет
Лучше один раз увидеть, чем 100 раз прочесть
> Обзор нововведений Cli
> Запуск Symfony, Laravel and native php scripts
Планы
Как уже писалось, был взят курс на универсальность и хотелось бы двигаться именно в этом направлении. Конечно, каждый фреймворк или cms это целая вселенная, поэтому, тут можно "расти и вширь и вглубь" И мы приглашаем всех желающих к совместной работе над проектом, важен любой вклад. Делитесь мнением, форкайте, шлите пуллреквесты, правьте баги, записывайте видео, предлагайте свои улучшения или просто пишите, о том, чего не хватает в Stacker
stalkerxxl
Докер… Вагрант… HomeStead… Stacker…
Так и хочется сказать «Горшочек, не вари!!!»…
Fesor
не лучше ли подумать в сторону специализации? "Универсальные вещи" быстро теряют простоту использования и увеличивают количество потенциальных проблем. Ну то есть конечно намного проще сделать "универсальный" контейнер и понапихивать туда всего и вся. Но может стоит упростить процесс формирования контейнеров под себя?
MaxZN
По поводу упростить, можете поподробнее, что вы предлагаете?
Формировать контейнеры под себя можно и сейчас, это довольно простой процесс. Редактируете Dockerfile по своему вкусу, далее запускате:
это тоже самое что и:
Данный процесс ничем не отличается от описанного в документации по докеру.
Fesor
Именно этот этап обычно вызывает больше всего вопросов у новичков и вызывает много рутины. Можно упростить этот этап. Например вы хотите использовать базовый образ php:7.1-fpm-alpine и мы хотим поставить imagemagic. Нам нужно еще как-то поставить все зависимости и т.д. Это занимает время, надо разбираться какие зависимости ставить и т.д. А можно было бы сделать надстройку которая бы это дело разруливала бы.
Ну это просто идеи. Еще одна запускалка docker контейнеров миру не нужна, и уж тем более не нужны жирные образы в которых просто есть все.
MaxZN
Для новичка вообще все вызывает вопросы)
На мой взгляд идея универсального образа не плоха, те же денверы и лампы построены на ней и довольно удобны. Но мне нравится ход ваших мыслей, в сторону «использовать нужное, но не больше». Допускаю, самым простым было бы отключение не нужного, а не добавление нужного. Отключить проще, чем добавлять. С первым нужно знать что нужно, таким образом уже знаешь, что отключить. Чтобы добавить, нужно знать довольно много и всякие надстройки тут не спасут, а только будут дублировать, то что и так уже делает докер это раз, плюс еще добавят сложности это два, так как все равно нужно будет изучать и доку докера и доку этой надстройки.
Идея в простоте, и если мы хотим ее предоставить, то нужно требовать, как можно меньше в плане знаний от пользователя. В принципе запилить sh для отключения не нужного не долго, просто параметрами передавать нужные образы для docker-compose и готово.
pOmelchenko
Упростить? Ну напримере есть puphpet. Можно собрать бокс для вагранта такой который нужен именно вам. Но вот у меня ни разу не получалось собрать такой чтобы ничего не глючило и не фаталило на этапе развертывания.
По этому оценил scotchbox, а теперь и homestead. Хотя до знакомства с вагрантом пользовался нативными решениями, разворачивая апачик и php c mysql для работе на локальной машине.
Fesor
есть и для docker подобные сервисы которые позволяют Dockerfile генерить и docker-compose файлики.
Ну тут уже вопрос тестирования этого puphnet. Насколько я помню там используются свои роли для ансибла, и судя по всему они просто не особо тестируются.
Проблемы обычно возникают в момент сборки образа или провиженинга виртуалки. Обойтись без этих проблем можно запихнув все туда, но мэйнтейнить такие контейнеры весьма муторно. Да и стоит держать ровно то что используется и не больше.
MaxZN
Вы докером пользовались? Какие сложности у вас возникали при сборке образа?
Почему приводите в пример vagrаnt? Vagrant и Docker это разные технологии.
Зачем нужен Docker, если есть тот же Vagrant? Главным образом, просто потому что виртуализация в Docker дешевле. Используя Vagrant, вы эмулируете работу целой операционной системы, тогда как Docker позволяет изолировать просто один процесс. Соответственно, используя одно и то же железо, с помощью Docker вы можете создать больше виртуальных окружений, чем при помощи Vagrant. Более того, LXC контейнеры запускаются (и останавливаются тоже) практически моментально, так как в них не происходит загрузка отдельной ОС. К тому же, Docker использует «слоеную» файловую систему AuFS, благодаря которой контейнеры могут совместно использовать одинаковые части файловой системы, доступные только на чтение. Если образ файловой системы занимает 5 Гб и вы запускаете 100 виртуальных окружений, то Vagrant потребуется 500 Гб места, а Docker — на порядок меньше.
Fesor
Там нет виртуализации. Все работает за счет изоляции.
Для меня основной профит это возможность дистрибуции слепков файловой системы как образов. Это сильно упрощает процесс поддержки инфраструктуры.
Именно по этой причине мне не нравится идея "универсальных образов". Чем больше в них вещей тем больше шансов на поломку. А с учетом того что докер при сборке образа никак не гарантирует нам идемпотентность, чем он меньше и чем меньше причин для его пересборки — тем лучше.
Конечно это не имеет значения если мы не используем докер образы при деплое. Я вот использую и потому для меня это важно.
MaxZN
Да, и это еще один жирный плюс докеру, не стал это упоминать показалось отступлением всторону. Так как разговор сейчас о среде для локальной разработки. Тут, должно быть понятно, что это не про деплой ни одним местом.
Да и в целом, прод это уже за локусом так сказать, там сервер, а за сервер должны отвечать админы. Конечно, если разработчик может полноценно совмещать еще и обязанности админа — это замечательно. Но это больше из разряда легенд о единороге. Пока еще не видел не одного сильного разработчика, что бы он еще при этом был и сильным админом.
pOmelchenko
Вам скинуть дерево дистрибутивов linux? Там все в разы интереснее =)
MaxZN
Так и хочется спросить: — «Почему?»
Если, это не что-то личное. В этом случае вопросов нет.