Comments 35
Я запускаю без публикации портов, при старте контейнера передавая параметр hostname, который привязываю к IP поднятого контейнера.
XDebug'у в docker-entrypoint устанавливаю параметры xdebug.remote_enable=On, xdebug.remote_autostart=On и xdebug.remote_host=<ip хостовой машины>. Настроек со стороны phpstorm вообще не требуется.
xdebug.remote_host=<ip хостовой машины> — если вы один работаете в компании или с одного хоста все сидят, а так удобнее ставить xdebug.remote_autostart=0 тогда xdebag будет коннектить к каждому сам
Закройте проекты через nginx-proxy какой (я использую dinghy-http-proxy). И тогда форвардить порты на хост не нужно будет.
Как-нибудь удалось решить проблему с тормозами? на работе приходится работать под Windows при монтировании папки в контейнер заметно падает скорость загрузки страниц, немного помогает вынос логов внутрь докер контейнера(аткуально для symfony app)
производительность ужасная.
В целом все упирается в производительность NFS. Лично я использую dinghy и в целом меня устраивает производительность. Особенно если вынести все кэши внутрь контейнера дабы не сказывалось на производительности.
Альтернатива — использовать rsync для синхронизации файлов на хосте и в виртулке:
https://github.com/brikis98/docker-osx-dev — там же в списке есть несколько альтернатив. Одной из интересных, которую я увы пока не смог попробовать, является docker-unison.
Есть ещё virtio-9p
Да, у меня все не доходят руки попробовать. Смущает то, что по уровню стабильности работы до NFS ему далеко (хотя возможно для локального использования в dev стэке этого хватит с головой, но надо пробовать). А так по производительности у него нет конкурентов.
правда нет тестов
это rsync в обе стороны. Ну то есть скорость работы будет как на нативной файловой системе, вопрос только в том, что синхронизация между хостом и гостем будет не такой шустрой, но… по опыту могу сказать что этого хватает.
уж проще уйти от докера, который, на самом деле, в таком стеке вообще не нужен
в каком стэке? Честно, все эти неудобства связанные с платформами быстро окупаются если у вас большое количество проектов и серверов. Например в моем случае докер нереально упрощает процесс разработки и деплоя.
Сделать docker pull redis как-то проще чем искать роль в ansible galaxy. Или docker pull beanstalkd. Ну то есть если есть официальный или полуофициальный образ — это уже неплохо так экономит расходы на поддержание инфраструктуры.
Более того, делать красивые плэйбуки для ансибла, которые гарантируют идемпотентрость действий, это то еще развлечение (хотя удобнее чем через паппеты какие). А с докером — билд сбилдился, залился в docker distribution и потом деплой хоть куда, да и сам деплоймент занимает уже секунды а не минуты.
Так же удобно для распаралеливания тестов, вместо 4-х вагрант боксов поднимаем 4 контейнера с приложением и тестим.
Не говоря о том, что если вдруг нам нужно какие-то фоновые задачи быстро перекинуть на другой сервак мы можем сделать это безумно быстро.
p.s. деплоймент с ансиблом средненького проекта у меня занимал по 5-10 минут на деплой (с провиженингом сервера). Сейчас тот же процесс занимает 30-40 секунд. С учетом того что мне приходится деплоиться по 10-20 раз на дню это неплохо так экономит время.
Для всех логов, type: rotating_file плюс для каждого уровня и канала свой файл, еще забыл про вынос файла с кешем так же внутрь контейнера, подозреваю что тоже самое нужно будет проделать и со статикой, на варганте помогает http://www.whitewashing.de/2013/08/19/speedup_symfony2_on_vagrant_boxes.html
Пришлось самому такое написать под свои нужды
Вы сейчас прям демонстрируете основную проблему процесса обучения современных разработчиков. Могут загнобить, потому лишний раз не показываю как я это понимаю. Не задаю вопросов, лучше тихо продолжу использовать как придется и не буду выяснять у сообщества норм я сделал или нет.
Если вас кто-то начинает неконструктивно гнобить — экономьте нервы и игнорируйте. А если же вам пишут что не так — это уже повод задуматься, обсудить.
За те 10 лет что читаю хабр, повидал ни раз, как людям отбивают желание писать.
Я человек впечатлительный, не люблю агрессию, буду потом переживать…
Так что да, все как вы и сказали, я демонстрирую проблему в данном сообществе, ибо ка писал выше, приоритет по нервам выше. Это просто мой выбор.
А так в других местах и делимся и обсуждаем и помогаем, как без этого то…
Для себя проблему решил сборкой нескольких контейнеров с LAMP и парой bash-скриптов для старта. В итоге получается что для старта нового проекта нужно просто скопировать директорию вида default-php-5.x и внутри в www положить проект, в db положить базу. Конфиги также линкуются bash-скриптом при старте сервера.
А вообще с docker-compose можно еще веселее конфигурацию замутить.
Мне нравится методология "The twelve factor app" https://12factor.net/. Используем продолжительное время http://phundament.com — темплейт, реализующий эту методологию тоже на основе Docker только для Yii2.
«docker-compose up»? Или я что-то не правильно понял?
В основном для бекенда там, под любой проект можно настроить достаточно быстро
Контейнеры практически все базируются на Alpine, а значит вес их очень мал, что позволяет держать большой зоопарк проектов, даже если место поджимает
- различия в окружениях должны разруливаться через 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, вроде как и так не сильно сложно писать.
— тут несколько с другой стороны заход, докер использовали в качестве альтернативы LAMP и тд. чтобы локальное окружение у всех было одинаковое и чтобы можно было легко перепрыгнуть со своего текущего окружения на наше. А чтоб ничего там не доустанавливать, решили установить максимальный пулл экстенженов для php сразу. Выглядит страшновато и избыточно, обсудим, спасибо за обратную связь.
— образ php7console для консольных утилит, вроде composera. Да, Вы правы cli уже есть в другой сущности, но мы решили отделить таким образом xDebug и php от консоли с npm, composer, и тд. чтобы не держать все это на хостовой машине, но php тут тоже нужен. Например для запуска консольных команд Sf2 и других фреймворков.
— элиасы, да, нужды в них нет, надо вычистить
В целом, нам бы не помешали грамотные контрибьюторы вроде вас, делайте форк, шлите pullrequest. Будем рады.
даже, если окружение всегда одно, локальное?
То есть продакшена у вас никогда не будет? В целом использовать docker только для локальной разработки можно, но теряется большая часть ценности данного инструмента.
Например для запуска консольных команд Sf2 и других фреймворков.
опять же. У вас должен быть один образ с приложением, в нем composer (чтобы иметь возможность запускать composer скрипты). А для разных вещей (запуск приложения или запуск тестов или запуск bin/console) мы просто используем разные контейнера. Но образ и Dockerfile один и тот же.
То есть продакшена у вас никогда не будет? В целом использовать docker только для локальной разработки можно, но теряется большая часть ценности данного инструмента.
Продакшен у нас есть, дело в другом.
— Не всегда прод с применением докера
— Если с докером, то у нас отдельные версии образов, которые нам наготовил админ. Прод это его ответственность.
Почему то, такое впечатление, будто вы хотите сделать из нашей сборочки «швейцарский нож», который в равной степени успешно, можно было бы использовать и на проде. На что с нашей стороны претензий не было, но если у вас есть на это силы и время, пожалуйста сделайте. Или, хотябы опишите, как вы бы это сделали. Будем признательны за любой вклад.
опять же. У вас должен быть один образ с приложением, в нем composer (чтобы иметь возможность запускать composer скрипты). А для разных вещей (запуск приложения или запуск тестов или запуск bin/console) мы просто используем разные контейнера. Но образ и Dockerfile один и тот же.
У нас образ для прода так и готовится, изначально идея докера в доставке и быстром запуске. По аналогии с контейнерами в порту, вы запаковываете в контейнер нужный вам груз и транспортируете куда вам нужно. Однако, и я наверное повторюсь, но скажу еще раз, stacker для локальной разработки, а не для транспортировки, его задачи в другом, вы просто подсовываете папку с проектами(больше одного) и запускаете их.
Также, мы хотели проявить немного заботы и о новичке, чтоб переход на наше окружение не был чем то сложным и пугающим. Напротив, чтобы все проходило плавно и безболезненно, с возможностью вернуться к прежнему окружению, когда будет нужно. В итоге:
— ему не нужно перемещать файлы и папки это раз
— не нужно сносить старый LEMP или то, что у него там стояло
— не нужно сносить базы(порты смещены на единицу для DB).
Когда нужно транспортировать на прод, то вы можете запаковать надлежащим образом проект в образ, файлы файлами, пакуйте и везите)
Stacker: Nginx, DB(Mysql, Pgsql, Redis), PHP7+xDebug за 5 минут