Stacker: Nginx, DB(Mysql, Pgsql, Redis), PHP7+xDebug за 5 минут

    Вводная


    Устали от 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, к сожалению не смог выделить больше времени на шлифовку, и запись была с утра), но пока так.

    Видео


    Видео 1: Stacker: Nginx, DB(Mysql, Pgsql, Redis), PHP7+xDebug за 5 минут:


    Видео 2: Stacker: PhpStorm и xDebug настройка за 1 минуту:


    Видео 3. Stacker: Console, Composer, Gulp, Npm, Gem, Bower:

    Поделиться публикацией
    Похожие публикации
    Ой, у вас баннер убежал!

    Ну, и что?
    Реклама
    Комментарии 35
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Лично мне не нравится подход с публикацией портов. Нет возможности запустить несколько разных проектов, не развешивая их на разные порты.

        Я запускаю без публикации портов, при старте контейнера передавая параметр hostname, который привязываю к IP поднятого контейнера.

        XDebug'у в docker-entrypoint устанавливаю параметры xdebug.remote_enable=On, xdebug.remote_autostart=On и xdebug.remote_host=<ip хостовой машины>. Настроек со стороны phpstorm вообще не требуется.
        • 0
          xdebug.remote_autostart=On — так тормозить же будет, на моей железке падение производительности наблюдал в сотни раз
          xdebug.remote_host=<ip хостовой машины> — если вы один работаете в компании или с одного хоста все сидят, а так удобнее ставить xdebug.remote_autostart=0 тогда xdebag будет коннектить к каждому сам
          • 0
            IP хостовой машины определяется в момент запуска контейнера.
            На моей машине параметр xdebug.remote_autostart никак не сказывается на производительности.
          • 0

            Закройте проекты через nginx-proxy какой (я использую dinghy-http-proxy). И тогда форвардить порты на хост не нужно будет.

          • 0

            Как-нибудь удалось решить проблему с тормозами? на работе приходится работать под Windows при монтировании папки в контейнер заметно падает скорость загрузки страниц, немного помогает вынос логов внутрь докер контейнера(аткуально для symfony app)

            • 0
              Сидим под MacOS и Ubuntu, такой проблемы пока не наблюдаем. Возможно вам поможет создание отдельного контейнера под логи с Elastic. Не уверен, что вам это подойдет, просто где-то видел такое решение на github.
              • 0
                Простите, а под чем сидите на MacOS? Пробовал VirtualBox, VMWare, и xhyve(nfs) — производительность ужасная.
                • 0
                  Docker
                  • 0

                    Docker под mac не работает, точнее это опять же либо xhyve (который используется официальным docker for mac) или virtualbox (boot2docker, dinghy).

                  • 0
                    производительность ужасная.

                    В целом все упирается в производительность NFS. Лично я использую dinghy и в целом меня устраивает производительность. Особенно если вынести все кэши внутрь контейнера дабы не сказывалось на производительности.


                    Альтернатива — использовать rsync для синхронизации файлов на хосте и в виртулке:


                    https://github.com/brikis98/docker-osx-dev — там же в списке есть несколько альтернатив. Одной из интересных, которую я увы пока не смог попробовать, является docker-unison.

                    • 0
                      Есть ещё virtio-9p, правда его не пробовал. За Unison спасибо, правда нет тестов, а самому пробовать не охота, уж проще уйти от докера, который, на самом деле, в таком стеке вообще не нужен, только ограничивает.
                      • 0
                        Есть ещё virtio-9p

                        Да, у меня все не доходят руки попробовать. Смущает то, что по уровню стабильности работы до NFS ему далеко (хотя возможно для локального использования в dev стэке этого хватит с головой, но надо пробовать). А так по производительности у него нет конкурентов.


                        правда нет тестов

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


                        уж проще уйти от докера, который, на самом деле, в таком стеке вообще не нужен

                        в каком стэке? Честно, все эти неудобства связанные с платформами быстро окупаются если у вас большое количество проектов и серверов. Например в моем случае докер нереально упрощает процесс разработки и деплоя.

                        • 0
                          в каком стэке? Честно, все эти неудобства связанные с платформами быстро окупаются если у вас большое количество проектов и серверов. Например в моем случае докер нереально упрощает процесс разработки и деплоя.

                          Ну вот какой смысл в docker, если вы разрабатываете монолит на symfony? Да поставить просто vagrant + ansible для деплоя.
                          • 0

                            Сделать docker pull redis как-то проще чем искать роль в ansible galaxy. Или docker pull beanstalkd. Ну то есть если есть официальный или полуофициальный образ — это уже неплохо так экономит расходы на поддержание инфраструктуры.


                            Более того, делать красивые плэйбуки для ансибла, которые гарантируют идемпотентрость действий, это то еще развлечение (хотя удобнее чем через паппеты какие). А с докером — билд сбилдился, залился в docker distribution и потом деплой хоть куда, да и сам деплоймент занимает уже секунды а не минуты.


                            Так же удобно для распаралеливания тестов, вместо 4-х вагрант боксов поднимаем 4 контейнера с приложением и тестим.


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


                            p.s. деплоймент с ансиблом средненького проекта у меня занимал по 5-10 минут на деплой (с провиженингом сервера). Сейчас тот же процесс занимает 30-40 секунд. С учетом того что мне приходится деплоиться по 10-20 раз на дню это неплохо так экономит время.

                • 0
                  Можете показать, как у вас логер настроен? По умолчанию конфигурация идет упоротая. Все подряд пишет, да еще и в один файл.
                  • 0

                    Для всех логов, type: rotating_file плюс для каждого уровня и канала свой файл, еще забыл про вынос файла с кешем так же внутрь контейнера, подозреваю что тоже самое нужно будет проделать и со статикой, на варганте помогает http://www.whitewashing.de/2013/08/19/speedup_symfony2_on_vagrant_boxes.html

                    • 0
                      Печалька с виндузом. К сожалению не смогу помочь. Тут бы пригодилось мнение админа, как вам маунты грамотно в винде настроить или если дело не в них, то ткнуть носом и сказать, что нужно делать.
                • 0
                  где же вы были пол года назад? :)
                  Пришлось самому такое написать под свои нужды
                  • 0
                    Полгода прошло, а чего не поделились с остальными своим решением? )
                    • –2
                      Экономлю нервы, а то ведь у нас и загнобить могут :)
                      • 0

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


                        Если вас кто-то начинает неконструктивно гнобить — экономьте нервы и игнорируйте. А если же вам пишут что не так — это уже повод задуматься, обсудить.

                        • +1
                          Да вы правы, но попрошу обратить внимание, что это проблема не современных разработчиков в целом, а именно данного сообщества в частности. В других более лояльных сообществах новички весьма активно общаются, обучаются, и не бояться быть затравленными.

                          За те 10 лет что читаю хабр, повидал ни раз, как людям отбивают желание писать.
                          Я человек впечатлительный, не люблю агрессию, буду потом переживать…
                          Так что да, все как вы и сказали, я демонстрирую проблему в данном сообществе, ибо ка писал выше, приоритет по нервам выше. Это просто мой выбор.

                          А так в других местах и делимся и обсуждаем и помогаем, как без этого то…
                  • 0
                    Очень интересно =)
                    Для себя проблему решил сборкой нескольких контейнеров с LAMP и парой bash-скриптов для старта. В итоге получается что для старта нового проекта нужно просто скопировать директорию вида default-php-5.x и внутри в www положить проект, в db положить базу. Конфиги также линкуются bash-скриптом при старте сервера.

                    А вообще с docker-compose можно еще веселее конфигурацию замутить.
                    • 0
                      Хм… не заметил что у ТС и так все с docker-composer собирается. Прошу прощения =)

                      Для разработки под Windows еще есть неплохой вариант — http://box.scotch.io/
                    • +2

                      Мне нравится методология "The twelve factor app" https://12factor.net/. Используем продолжительное время http://phundament.com — темплейт, реализующий эту методологию тоже на основе Docker только для Yii2.

                      • 0
                        >> Устали от LAMPов, MAMPов, ручной настройки, конфликтов? Хотите получить полностью настроенное и готовое к работе окружение для web разработки с Nginx, DB(Mysql, Pgsql, Redis), PHP7 на борту и с настроенным xDebug и все это за 5 минут?

                        «docker-compose up»? Или я что-то не правильно понял?
                        • 0
                          Еще Homestead довольно простая и удобная штука.
                          • 0
                            Раз пошла такая пьянка, то вот Docker-Harbor мой скромный велосипед
                            В основном для бекенда там, под любой проект можно настроить достаточно быстро
                            Контейнеры практически все базируются на Alpine, а значит вес их очень мал, что позволяет держать большой зоопарк проектов, даже если место поджимает
                            • 0
                              • различия в окружениях должны разруливаться через 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, вроде как и так не сильно сложно писать.
                              • 0
                                — «различия в окружениях должны разруливаться» — даже, если окружение всегда одно, локальное?
                                — тут несколько с другой стороны заход, докер использовали в качестве альтернативы LAMP и тд. чтобы локальное окружение у всех было одинаковое и чтобы можно было легко перепрыгнуть со своего текущего окружения на наше. А чтоб ничего там не доустанавливать, решили установить максимальный пулл экстенженов для php сразу. Выглядит страшновато и избыточно, обсудим, спасибо за обратную связь.

                                — образ php7console для консольных утилит, вроде composera. Да, Вы правы cli уже есть в другой сущности, но мы решили отделить таким образом xDebug и php от консоли с npm, composer, и тд. чтобы не держать все это на хостовой машине, но php тут тоже нужен. Например для запуска консольных команд Sf2 и других фреймворков.

                                — элиасы, да, нужды в них нет, надо вычистить

                                В целом, нам бы не помешали грамотные контрибьюторы вроде вас, делайте форк, шлите pullrequest. Будем рады.
                                • 0
                                  даже, если окружение всегда одно, локальное?

                                  То есть продакшена у вас никогда не будет? В целом использовать docker только для локальной разработки можно, но теряется большая часть ценности данного инструмента.


                                  Например для запуска консольных команд Sf2 и других фреймворков.

                                  опять же. У вас должен быть один образ с приложением, в нем composer (чтобы иметь возможность запускать composer скрипты). А для разных вещей (запуск приложения или запуск тестов или запуск bin/console) мы просто используем разные контейнера. Но образ и Dockerfile один и тот же.

                                  • 0
                                    То есть продакшена у вас никогда не будет? В целом использовать docker только для локальной разработки можно, но теряется большая часть ценности данного инструмента.

                                    Продакшен у нас есть, дело в другом.
                                    — Не всегда прод с применением докера
                                    — Если с докером, то у нас отдельные версии образов, которые нам наготовил админ. Прод это его ответственность.
                                    Почему то, такое впечатление, будто вы хотите сделать из нашей сборочки «швейцарский нож», который в равной степени успешно, можно было бы использовать и на проде. На что с нашей стороны претензий не было, но если у вас есть на это силы и время, пожалуйста сделайте. Или, хотябы опишите, как вы бы это сделали. Будем признательны за любой вклад.

                                    опять же. У вас должен быть один образ с приложением, в нем composer (чтобы иметь возможность запускать composer скрипты). А для разных вещей (запуск приложения или запуск тестов или запуск bin/console) мы просто используем разные контейнера. Но образ и Dockerfile один и тот же.


                                    У нас образ для прода так и готовится, изначально идея докера в доставке и быстром запуске. По аналогии с контейнерами в порту, вы запаковываете в контейнер нужный вам груз и транспортируете куда вам нужно. Однако, и я наверное повторюсь, но скажу еще раз, stacker для локальной разработки, а не для транспортировки, его задачи в другом, вы просто подсовываете папку с проектами(больше одного) и запускаете их.
                                    Также, мы хотели проявить немного заботы и о новичке, чтоб переход на наше окружение не был чем то сложным и пугающим. Напротив, чтобы все проходило плавно и безболезненно, с возможностью вернуться к прежнему окружению, когда будет нужно. В итоге:
                                    — ему не нужно перемещать файлы и папки это раз
                                    — не нужно сносить старый LEMP или то, что у него там стояло
                                    — не нужно сносить базы(порты смещены на единицу для DB).

                                    Когда нужно транспортировать на прод, то вы можете запаковать надлежащим образом проект в образ, файлы файлами, пакуйте и везите)
                              • +1
                                Советую еще laradock посмотреть. Тоже очень удобная штука.
                                • 0
                                  Плюсую. Очень интересная штука, напоминает нашу сборку, только не в бете) Ознакомлюсь подробнее на досуге, есть что почерпнуть.

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое