PHP8 + XDebug

grigori

( ͡° ͜ʖ ͡°)
Команда форума
с редисом это curl на phpredis распаковка... и уже в конце docker-php-ext-install redis
wget достаточно
есть конкретная аппликация, с конкретными зависимостями. ты же не лепишь везде xdebug
это четыре разных вопроса

1. В общем случае свой образ вообще не нужен, все хорошо работает на голых официальных образах.
Достаточно подмонтировать shared volume для расширений и подменить entrypoint.
Вот шаблон набора конфигов.

compose:
entrypoint:

расширения один раз собираются и лежат в shared volume, когда надо пересобрать (не бывает такого) - чищу volume
docker-compose rm -v или docker volume rm

Чувствую, надо додебажить и написать статью об этом.

2. Если в проекте политика not invented here, и есть devops все поддерживать - можно поднять registry, настроить CI, и иметь свой baseline - общий образ для dev и prod.
Собрать-то - не вопрос, вопрос - поддерживать это годами. Уж на каждый сайт отдельный образ годами никто не поддерживает точно.
А sh-скриптик для установки расширений не устаревает.

3. xdebug подключается командой docker-php-ext-enable xdebug, отдельный образ - это "в гамаке и стоя"

4. отдельный RUN на каждое ресширение плох тем, что сборка не вылетает на первой ошибке компиляции,
а вообще, забей уже и на свои образы, и на RUN

5. эта тема конкретно про 8ку, без танцев с бубном на официальный образ xdebug не поставить, поэтому я вон вверху показал dockerfile как это сделать, если хочется начать ее иметь. Через 3 месяца pickle допилят, Дерик константу добавит, и он будет не нужен.

если увидишь - процитируй, исправлю
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
понял, и это довольно сложный вопрос, как показывает тред на лоре
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
event, прикольно, возьму себе
кстати, @флоппик для event у тебя базовый образ php:7.4-cli-buster, non-zts?
для event-образов лучше zts, чтобы swoole мог спокойно создавать потоки
 

WMix

герр M:)ller
Партнер клуба
в php образах curl есть изначально вроде
отдельный RUN на каждое ресширение плохо тем, что сборка не вылетает на первой ошибке компиляции
не очень понятно, в цепочке "ab && cd" до ошибки в "cd", "ab" также будет выполнено.
 

MiksIr

miksir@home:~$
отдельный RUN на каждое ресширение плох тем, что сборка не вылетает на первой ошибке компиляции,
Как раз много маленьких RUN лучше если отлаживать компиляцию нужно, что бы не перекомпилировать все предыдущее каждую попытку
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
не очень понятно, в цепочке "ab && cd" до ошибки в "cd", "ab" также будет выполнено.
да оно как-бы не пол-часа занимает, у меня на ноуте за минуту-две все расширения ставятся, и это делается один раз
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
так, надо объяснить подробнее

я пишу
Код:
    && docker-php-ext-install -j$(nproc) bcmath gettext mysqli pdo_mysql pdo_pgsql pgsql pspell zip \
    && docker-php-ext-configure gd --with-freetype --with-jpeg --with-webp \
    && docker-php-ext-install -j$(nproc) gd
вместо RUN на каждой строчке не для дебага

когда я создаю новый образ, запускать сборки неудобно - ничего удобнее консоли и vim для make и gcc не существует, команды все-равно надо проверять в консоли shell-скриптом
поэтому, docker run -ti php:ver bash - и вперед,
а потом в скрипте просто дописывается && в начале строки

когда образ уже есть, и выходит новая минорная версия PHP, я захожу на сайт docker hub, и нажимаю там кнопку build,
но иногда сборка ломается - например, переименовали libxml в libxml2
когда много RUN, найти ошибку в логе сборки сложно, а когда && - ошибка всегда в конце лога

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

флоппик

promotor fidei
Команда форума
Партнер клуба
Тут нужно понимать несколько вещей: все что вы сложите в один RUN — склеится в один слой. Если вы будете пересобирать нижележащий слой, и он делает что-то, что используется в следующих слоях - они пересоберутся все. Если сделать раздельный образ с xdebug (для разработчиков) на базе обычного образа (для прода) - все слои закешируются, и разница будет только в слое с xdebug. Если вы будете "потом отключать xdebug" - у вас будет слой с хдебугом, на который будет накладываться специальный слой, выключающий xdebug. Таскать это все в продакшн (и перевыкачивать на весь кластер, если вы полагаетесь на эти образа в проде) - такое себе.
Да, есть --squash который клеит мелкие слои в один, но тут возникает отдельная проблема, где любые изменения порождают целиком здоровый новый слой, который замещает здоровый прошлый слой. Короче, группируйте действия в сборке сематически, будет сильно лучше.
Другая вещь, которая касается конкретно пхп-экстеншнов, поставленных тулзами из родных образов: если что, каждый вызов docker-php-ext-install сначала распаковывает сорцы пхп, а потом удаляет их:https://github.com/docker-library/php/blob/master/docker-php-ext-install#L123
Раскидывая это действие на разные слои можно довольно сильно потерять во времени билда, особенно если вы собираете образы приложения прям со всем этим.

Какие-то еще пункты были, но я забыль.
 

MiksIr

miksir@home:~$
поэтому, docker run -ti php:ver bash - и вперед
Ну по-разному, хз. Когда простой набор команд - для меня проще написать сразу докерфайл и отлаживать билдом, а если уже возникает проблема - то собираешь образ без проблемного пакета и уже с ним bash. По крайней мере так меньше вероятность потерять что-то из команд забыв перенести из консоли в докерфайл.

А так то для docker-php-ext-install конечно лучше все пакеты списком как аргумент, хотя
Раскидывая это действие на разные слои можно довольно сильно потерять во времени билда, особенно если вы собираете образы приложения прям со всем этим.
кеширование как раз поможет не потерять во времени билда =)
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Если вы будете "потом отключать xdebug" - у вас будет слой с хдебугом, на который будет накладываться специальный слой, выключающий xdebug. Таскать
Ты сейчас путаешь теплое с мягким :)
xdebug може собираться, лежать, но не подключаться, и в проде он не мешает.
Подключать его можно init-скриптом, который монтируется в docker-compose.override.yml, и выполняет команду docker-php-ext-enable xdebug при запуске через docker-compose, а в проде тот же образ работает без xdebug
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
каждый вызов docker-php-ext-install сначала распаковывает сорцы пхп, а потом удаляет их:https://github.com/docker-library/php/blob/master/docker-php-ext-install#L123
Раскидывая это действие на разные слои можно довольно сильно потерять во времени билда, особенно если вы собираете образы приложения прям со всем этим.
ты время-то замерь :) и сравни с composer install
подольше собирается только image magic, все остальное - единицы минут, один раз при деплое
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
вот, замерил сборку расширений для 8ки по Dockerfile в начале темы на макбуке в тормознутой виртуалке docker desktop
14 расширений с библиотеками: bcmath gettext mysqli pdo_mysql pdo_pgsql pgsql pspell zip gd ds igbinary xdebug redis memcached

real 2m51.732s

для конкретного проекта нужна половина, экономию скольких спичек вы обсуждаете? :)
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Ну если мы говорим про сборку приложения, то кеш композера (да и вендор папка) кладется в кеш CI и composer install занимает десяток секунд
а сколько часов в год на настройку, обновление, мониторинг и бекап серверов репозитория, CI и VPN? или сколько денег в месяц за облако? :)
 

fixxxer

К.О.
Партнер клуба
а сколько часов в год на настройку, обновление, мониторинг и бекап серверов репозитория, CI и VPN? или сколько денег в месяц за облако? :)
Ну, Github Actions идёт вместе с приватными репами один фиг. Nexus да, ну его несложно поднять, тем более один фиг уже был для maven. Скорее вопрос сколько денег девопсу)
 
Сверху