Вводная
Устали от LAMPов, MAMPов, ручной настройки, конфликтов? Хотите получить полностью настроенное и готовое к работе окружение для web разработки с Nginx, DB(Mysql, Pgsql, Redis), PHP7 на борту и с настроенным xDebug и все это за 5 минут? Stacker идет на помощь!
Мне, как человеку ленивому, склонному к оптимизации процессов разработки, всегда не нравилось настраивать окружение вручную. Не то, что бы я не умел этого делать, печалило отсутствие DRY(dont repeat yourself) принципов в этом отношении. Это раз, а два это наша компания, в которой свой стек для локальной разработки. И мне сложно вспомнить, когда к нам в компанию приходил разработчик и у него стояло точно такое же рабочее окружение, как и у нас.
Кто-то сидит под виндой используя денвер или LAMP, кто-то под MacOS на МАМP, у кого то linux с Apache2 или Nginx. Придя в компанию, имею ввиду в любую компанию, первое что вам нужно сделать — это развернуть проект. Это очевидно, но не быстро, как хотелось бы и как могло бы быть используй вы Docker. А именно с его помощью нам и удалось решить эту проблему, ускорив вход в проект и облегчив жизнь новоиспеченному разработчику.
Устали от LAMPов, MAMPов, ручной настройки, конфликтов, мучаетесь с xDebug? Stacker идет на помощь! Вот и он — Stacker (Symfony docker starter kit for development) В разработке мы часто используем sf2, но пусть это вас не смущает. Stacker — подходит и для нативного php и легко может быть перенастроен на другие фреймворки.
Не буду грузить вас дальше писаниной, тем более, что уже есть видео описывающее процесс установки и настроек. Кому интересно смотрим ставим и пользуемся.
PS. Запилил новое видео о консоли в Stacker, к сожалению не смог выделить больше времени на шлифовку, и запись была с утра), но пока так.
Видео
Комментарии (35)
Preemiere
21.11.2016 16:31Лично мне не нравится подход с публикацией портов. Нет возможности запустить несколько разных проектов, не развешивая их на разные порты.
Я запускаю без публикации портов, при старте контейнера передавая параметр hostname, который привязываю к IP поднятого контейнера.
XDebug'у в docker-entrypoint устанавливаю параметры xdebug.remote_enable=On, xdebug.remote_autostart=On и xdebug.remote_host=<ip хостовой машины>. Настроек со стороны phpstorm вообще не требуется.
MaxZN
21.11.2016 16:42xdebug.remote_autostart=On — так тормозить же будет, на моей железке падение производительности наблюдал в сотни раз
xdebug.remote_host=<ip хостовой машины> — если вы один работаете в компании или с одного хоста все сидят, а так удобнее ставить xdebug.remote_autostart=0 тогда xdebag будет коннектить к каждому самPreemiere
21.11.2016 16:48IP хостовой машины определяется в момент запуска контейнера.
На моей машине параметр xdebug.remote_autostart никак не сказывается на производительности.
Fesor
22.11.2016 11:12Закройте проекты через nginx-proxy какой (я использую dinghy-http-proxy). И тогда форвардить порты на хост не нужно будет.
vvasilenok
21.11.2016 16:43Как-нибудь удалось решить проблему с тормозами? на работе приходится работать под Windows при монтировании папки в контейнер заметно падает скорость загрузки страниц, немного помогает вынос логов внутрь докер контейнера(аткуально для symfony app)
MaxZN
21.11.2016 16:47Сидим под MacOS и Ubuntu, такой проблемы пока не наблюдаем. Возможно вам поможет создание отдельного контейнера под логи с Elastic. Не уверен, что вам это подойдет, просто где-то видел такое решение на github.
qRoC
22.11.2016 08:46Простите, а под чем сидите на MacOS? Пробовал VirtualBox, VMWare, и xhyve(nfs) — производительность ужасная.
Fesor
23.11.2016 09:01производительность ужасная.
В целом все упирается в производительность NFS. Лично я использую dinghy и в целом меня устраивает производительность. Особенно если вынести все кэши внутрь контейнера дабы не сказывалось на производительности.
Альтернатива — использовать rsync для синхронизации файлов на хосте и в виртулке:
https://github.com/brikis98/docker-osx-dev — там же в списке есть несколько альтернатив. Одной из интересных, которую я увы пока не смог попробовать, является docker-unison.
qRoC
24.11.2016 13:13Есть ещё virtio-9p, правда его не пробовал. За Unison спасибо, правда нет тестов, а самому пробовать не охота, уж проще уйти от докера, который, на самом деле, в таком стеке вообще не нужен, только ограничивает.
Fesor
24.11.2016 22:41Есть ещё virtio-9p
Да, у меня все не доходят руки попробовать. Смущает то, что по уровню стабильности работы до NFS ему далеко (хотя возможно для локального использования в dev стэке этого хватит с головой, но надо пробовать). А так по производительности у него нет конкурентов.
правда нет тестов
это rsync в обе стороны. Ну то есть скорость работы будет как на нативной файловой системе, вопрос только в том, что синхронизация между хостом и гостем будет не такой шустрой, но… по опыту могу сказать что этого хватает.
уж проще уйти от докера, который, на самом деле, в таком стеке вообще не нужен
в каком стэке? Честно, все эти неудобства связанные с платформами быстро окупаются если у вас большое количество проектов и серверов. Например в моем случае докер нереально упрощает процесс разработки и деплоя.
qRoC
26.11.2016 11:28в каком стэке? Честно, все эти неудобства связанные с платформами быстро окупаются если у вас большое количество проектов и серверов. Например в моем случае докер нереально упрощает процесс разработки и деплоя.
Ну вот какой смысл в docker, если вы разрабатываете монолит на symfony? Да поставить просто vagrant + ansible для деплоя.Fesor
26.11.2016 12:42Сделать
docker pull redisкак-то проще чем искать роль в ansible galaxy. Илиdocker pull beanstalkd. Ну то есть если есть официальный или полуофициальный образ — это уже неплохо так экономит расходы на поддержание инфраструктуры.
Более того, делать красивые плэйбуки для ансибла, которые гарантируют идемпотентрость действий, это то еще развлечение (хотя удобнее чем через паппеты какие). А с докером — билд сбилдился, залился в docker distribution и потом деплой хоть куда, да и сам деплоймент занимает уже секунды а не минуты.
Так же удобно для распаралеливания тестов, вместо 4-х вагрант боксов поднимаем 4 контейнера с приложением и тестим.
Не говоря о том, что если вдруг нам нужно какие-то фоновые задачи быстро перекинуть на другой сервак мы можем сделать это безумно быстро.
p.s. деплоймент с ансиблом средненького проекта у меня занимал по 5-10 минут на деплой (с провиженингом сервера). Сейчас тот же процесс занимает 30-40 секунд. С учетом того что мне приходится деплоиться по 10-20 раз на дню это неплохо так экономит время.
MaxZN
21.11.2016 18:19Можете показать, как у вас логер настроен? По умолчанию конфигурация идет упоротая. Все подряд пишет, да еще и в один файл.
vvasilenok
21.11.2016 18:50Для всех логов, type: rotating_file плюс для каждого уровня и канала свой файл, еще забыл про вынос файла с кешем так же внутрь контейнера, подозреваю что тоже самое нужно будет проделать и со статикой, на варганте помогает http://www.whitewashing.de/2013/08/19/speedup_symfony2_on_vagrant_boxes.html
MaxZN
21.11.2016 19:12Печалька с виндузом. К сожалению не смогу помочь. Тут бы пригодилось мнение админа, как вам маунты грамотно в винде настроить или если дело не в них, то ткнуть носом и сказать, что нужно делать.
laviro
21.11.2016 18:25где же вы были пол года назад? :)
Пришлось самому такое написать под свои нуждыMaxZN
21.11.2016 18:49Полгода прошло, а чего не поделились с остальными своим решением? )
laviro
21.11.2016 19:15-2Экономлю нервы, а то ведь у нас и загнобить могут :)
Fesor
22.11.2016 14:14Вы сейчас прям демонстрируете основную проблему процесса обучения современных разработчиков. Могут загнобить, потому лишний раз не показываю как я это понимаю. Не задаю вопросов, лучше тихо продолжу использовать как придется и не буду выяснять у сообщества норм я сделал или нет.
Если вас кто-то начинает неконструктивно гнобить — экономьте нервы и игнорируйте. А если же вам пишут что не так — это уже повод задуматься, обсудить.
laviro
22.11.2016 17:27+1Да вы правы, но попрошу обратить внимание, что это проблема не современных разработчиков в целом, а именно данного сообщества в частности. В других более лояльных сообществах новички весьма активно общаются, обучаются, и не бояться быть затравленными.
За те 10 лет что читаю хабр, повидал ни раз, как людям отбивают желание писать.
Я человек впечатлительный, не люблю агрессию, буду потом переживать…
Так что да, все как вы и сказали, я демонстрирую проблему в данном сообществе, ибо ка писал выше, приоритет по нервам выше. Это просто мой выбор.
А так в других местах и делимся и обсуждаем и помогаем, как без этого то…
rhamdeew
21.11.2016 20:52Очень интересно =)
Для себя проблему решил сборкой нескольких контейнеров с LAMP и парой bash-скриптов для старта. В итоге получается что для старта нового проекта нужно просто скопировать директорию вида default-php-5.x и внутри в www положить проект, в db положить базу. Конфиги также линкуются bash-скриптом при старте сервера.
А вообще с docker-compose можно еще веселее конфигурацию замутить.rhamdeew
21.11.2016 20:56Хм… не заметил что у ТС и так все с docker-composer собирается. Прошу прощения =)
Для разработки под Windows еще есть неплохой вариант — http://box.scotch.io/
akaSStalkALEX
22.11.2016 07:55+2Мне нравится методология "The twelve factor app" https://12factor.net/. Используем продолжительное время http://phundament.com — темплейт, реализующий эту методологию тоже на основе Docker только для Yii2.
berezuev
22.11.2016 10:08>> Устали от LAMPов, MAMPов, ручной настройки, конфликтов? Хотите получить полностью настроенное и готовое к работе окружение для web разработки с Nginx, DB(Mysql, Pgsql, Redis), PHP7 на борту и с настроенным xDebug и все это за 5 минут?
«docker-compose up»? Или я что-то не правильно понял?
Vumik
22.11.2016 11:14Раз пошла такая пьянка, то вот Docker-Harbor мой скромный велосипед
В основном для бекенда там, под любой проект можно настроить достаточно быстро
Контейнеры практически все базируются на Alpine, а значит вес их очень мал, что позволяет держать большой зоопарк проектов, даже если место поджимает
Fesor
22.11.2016 11:24- различия в окружениях должны разруливаться через env переменные. В этом стартаре этого нет.
- лично я предпочитаю подход с разделением docker-compose файликов:
docker-compose.yml - базоые сервисы, все что должно быть на проде. А так же все env переменные и т.д. docker-compose.stage.yml - то что деплоится на стэйджинги docker-compose.local.yml - то что надо для локальной работы, например волумы. docker-compose.build.yml - то что надо билдить, по сути `build` инструкции для сервисов из основного файла
Например локально тогда я добавляю в корень проекта
.envфайлик и в нем пишу:
COMPOSE_FILE=docker/docker-compose.yml:docker/docker-compose.build.yml:docker/docker-compose.local.yml
Не пойму зачем нужен отдельный образ
php7consoleесли в вашем основномphp7уже есть cli. Нет смысла множить сущности, так будет только сложнее синхронизировать окружения. Лучше в зависимости от параметров окружения включать/выключать экстеншен xdebug-а. Тогда можно будет в любой момент взять билд с прода и подебажить.
Не оптимально используются кэш инструкций в Dockerfile. Да и в целом выглядит как помойка. Оно конечно понятно что лишнее можно удалить но...
- не понятно зачем делать элиасы команд для docker-compose, вроде как и так не сильно сложно писать.
MaxZN
22.11.2016 16:46— «различия в окружениях должны разруливаться» — даже, если окружение всегда одно, локальное?
— тут несколько с другой стороны заход, докер использовали в качестве альтернативы LAMP и тд. чтобы локальное окружение у всех было одинаковое и чтобы можно было легко перепрыгнуть со своего текущего окружения на наше. А чтоб ничего там не доустанавливать, решили установить максимальный пулл экстенженов для php сразу. Выглядит страшновато и избыточно, обсудим, спасибо за обратную связь.
— образ php7console для консольных утилит, вроде composera. Да, Вы правы cli уже есть в другой сущности, но мы решили отделить таким образом xDebug и php от консоли с npm, composer, и тд. чтобы не держать все это на хостовой машине, но php тут тоже нужен. Например для запуска консольных команд Sf2 и других фреймворков.
— элиасы, да, нужды в них нет, надо вычистить
В целом, нам бы не помешали грамотные контрибьюторы вроде вас, делайте форк, шлите pullrequest. Будем рады.Fesor
22.11.2016 17:53даже, если окружение всегда одно, локальное?
То есть продакшена у вас никогда не будет? В целом использовать docker только для локальной разработки можно, но теряется большая часть ценности данного инструмента.
Например для запуска консольных команд Sf2 и других фреймворков.
опять же. У вас должен быть один образ с приложением, в нем composer (чтобы иметь возможность запускать composer скрипты). А для разных вещей (запуск приложения или запуск тестов или запуск bin/console) мы просто используем разные контейнера. Но образ и
Dockerfileодин и тот же.MaxZN
23.11.2016 08:16То есть продакшена у вас никогда не будет? В целом использовать docker только для локальной разработки можно, но теряется большая часть ценности данного инструмента.
Продакшен у нас есть, дело в другом.
— Не всегда прод с применением докера
— Если с докером, то у нас отдельные версии образов, которые нам наготовил админ. Прод это его ответственность.
Почему то, такое впечатление, будто вы хотите сделать из нашей сборочки «швейцарский нож», который в равной степени успешно, можно было бы использовать и на проде. На что с нашей стороны претензий не было, но если у вас есть на это силы и время, пожалуйста сделайте. Или, хотябы опишите, как вы бы это сделали. Будем признательны за любой вклад.
опять же. У вас должен быть один образ с приложением, в нем composer (чтобы иметь возможность запускать composer скрипты). А для разных вещей (запуск приложения или запуск тестов или запуск bin/console) мы просто используем разные контейнера. Но образ и Dockerfile один и тот же.
У нас образ для прода так и готовится, изначально идея докера в доставке и быстром запуске. По аналогии с контейнерами в порту, вы запаковываете в контейнер нужный вам груз и транспортируете куда вам нужно. Однако, и я наверное повторюсь, но скажу еще раз, stacker для локальной разработки, а не для транспортировки, его задачи в другом, вы просто подсовываете папку с проектами(больше одного) и запускаете их.
Также, мы хотели проявить немного заботы и о новичке, чтоб переход на наше окружение не был чем то сложным и пугающим. Напротив, чтобы все проходило плавно и безболезненно, с возможностью вернуться к прежнему окружению, когда будет нужно. В итоге:
— ему не нужно перемещать файлы и папки это раз
— не нужно сносить старый LEMP или то, что у него там стояло
— не нужно сносить базы(порты смещены на единицу для DB).
Когда нужно транспортировать на прод, то вы можете запаковать надлежащим образом проект в образ, файлы файлами, пакуйте и везите)
alexkunin
О, я для меня Stacker — это все еще нечто другое: https://en.wikipedia.org/wiki/Stac_Electronics. Простите за оффтоп.