Also, тоже имею базовые образа немножко на базе дебиан слим: https://github.com/gorbunov/php-docker-images
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
PHP8 + XDebug
- Автор темы grigori
- Дата начала
wget достаточно
это четыре разных вопроса
1. В общем случае свой образ вообще не нужен, все хорошо работает на голых официальных образах.
Достаточно подмонтировать shared volume для расширений и подменить entrypoint.
Вот шаблон набора конфигов.
docker-patterns/2.nginx-acme-php-mysql at master · grikdotnet/docker-patterns
Patterns of configs for web applications to run in docker - grikdotnet/docker-patterns
github.com
compose:
docker-patterns/2.nginx-acme-php-mysql/docker-compose.yml at master · grikdotnet/docker-patterns
Patterns of configs for web applications to run in docker - grikdotnet/docker-patterns
github.com
docker-patterns/2.nginx-acme-php-mysql/etc/php/php-entrypoint.sh at master · grikdotnet/docker-patterns
Patterns of configs for web applications to run in docker - grikdotnet/docker-patterns
github.com
расширения один раз собираются и лежат в 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 допилят, Дерик константу добавит, и он будет не нужен.
если увидишь - процитируй, исправлю
понял, и это довольно сложный вопрос, как показывает тред на лоре
Какая-то странная реализация memcpy в glibc
Взял мастер, т.е. всё более-менее свежее. Имеем: void * MEMCPY (void *dstpp, const void *srcpp, size_t len) { unsigned long int dstp = (long int) dstpp; unsigned long int srcp = (long int) srcpp; /* Copy from the beginning to the end. */ /...
кстати, @флоппик для event у тебя базовый образ php:7.4-cli-buster, non-zts?
для event-образов лучше zts, чтобы swoole мог спокойно создавать потоки
phpdocker/7.4/events.Dockerfile at master · grikdotnet/phpdocker
Docker, docker-compose and configs files to run PHP stack - grikdotnet/phpdocker
github.com
в php образах curl есть изначально вроде
не очень понятно, в цепочке "ab && cd" до ошибки в "cd", "ab" также будет выполнено.
MiksIr
miksir@home:~$
Как раз много маленьких RUN лучше если отлаживать компиляцию нужно, что бы не перекомпилировать все предыдущее каждую попытку
ну, к php это не относится, в дебиане - идет, в alpine не идет
P.S. проверил, wget тоже не входит в posix стандарт
да оно как-бы не пол-часа занимает, у меня на ноуте за минуту-две все расширения ставятся, и это делается один раз
так, надо объяснить подробнее
я пишу
вместо RUN на каждой строчке не для дебага
когда я создаю новый образ, запускать сборки неудобно - ничего удобнее консоли и vim для make и gcc не существует, команды все-равно надо проверять в консоли shell-скриптом
поэтому, docker run -ti php:ver bash - и вперед,
а потом в скрипте просто дописывается && в начале строки
когда образ уже есть, и выходит новая минорная версия PHP, я захожу на сайт docker hub, и нажимаю там кнопку build,
но иногда сборка ломается - например, переименовали libxml в libxml2
когда много RUN, найти ошибку в логе сборки сложно, а когда && - ошибка всегда в конце лога
А в этом году до меня дошло, что отдельный образ мне нужен так же, как vendors в git-репе, тем же скриптом все за минуту ставится при запуске.
я пишу
Код:
&& 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когда я создаю новый образ, запускать сборки неудобно - ничего удобнее консоли и vim для make и gcc не существует, команды все-равно надо проверять в консоли shell-скриптом
поэтому, docker run -ti php:ver bash - и вперед,
а потом в скрипте просто дописывается && в начале строки
когда образ уже есть, и выходит новая минорная версия PHP, я захожу на сайт docker hub, и нажимаю там кнопку build,
но иногда сборка ломается - например, переименовали libxml в libxml2
когда много RUN, найти ошибку в логе сборки сложно, а когда && - ошибка всегда в конце лога
А в этом году до меня дошло, что отдельный образ мне нужен так же, как vendors в git-репе, тем же скриптом все за минуту ставится при запуске.
Тут нужно понимать несколько вещей: все что вы сложите в один RUN — склеится в один слой. Если вы будете пересобирать нижележащий слой, и он делает что-то, что используется в следующих слоях - они пересоберутся все. Если сделать раздельный образ с xdebug (для разработчиков) на базе обычного образа (для прода) - все слои закешируются, и разница будет только в слое с xdebug. Если вы будете "потом отключать xdebug" - у вас будет слой с хдебугом, на который будет накладываться специальный слой, выключающий xdebug. Таскать это все в продакшн (и перевыкачивать на весь кластер, если вы полагаетесь на эти образа в проде) - такое себе.
Да, есть --squash который клеит мелкие слои в один, но тут возникает отдельная проблема, где любые изменения порождают целиком здоровый новый слой, который замещает здоровый прошлый слой. Короче, группируйте действия в сборке сематически, будет сильно лучше.
Другая вещь, которая касается конкретно пхп-экстеншнов, поставленных тулзами из родных образов: если что, каждый вызов docker-php-ext-install сначала распаковывает сорцы пхп, а потом удаляет их:https://github.com/docker-library/php/blob/master/docker-php-ext-install#L123
Раскидывая это действие на разные слои можно довольно сильно потерять во времени билда, особенно если вы собираете образы приложения прям со всем этим.
Какие-то еще пункты были, но я забыль.
Да, есть --squash который клеит мелкие слои в один, но тут возникает отдельная проблема, где любые изменения порождают целиком здоровый новый слой, который замещает здоровый прошлый слой. Короче, группируйте действия в сборке сематически, будет сильно лучше.
Другая вещь, которая касается конкретно пхп-экстеншнов, поставленных тулзами из родных образов: если что, каждый вызов docker-php-ext-install сначала распаковывает сорцы пхп, а потом удаляет их:https://github.com/docker-library/php/blob/master/docker-php-ext-install#L123
Раскидывая это действие на разные слои можно довольно сильно потерять во времени билда, особенно если вы собираете образы приложения прям со всем этим.
Какие-то еще пункты были, но я забыль.
MiksIr
miksir@home:~$
Ну по-разному, хз. Когда простой набор команд - для меня проще написать сразу докерфайл и отлаживать билдом, а если уже возникает проблема - то собираешь образ без проблемного пакета и уже с ним bash. По крайней мере так меньше вероятность потерять что-то из команд забыв перенести из консоли в докерфайл.
А так то для docker-php-ext-install конечно лучше все пакеты списком как аргумент, хотя
кеширование как раз поможет не потерять во времени билда =)
Ты сейчас путаешь теплое с мягким
xdebug може собираться, лежать, но не подключаться, и в проде он не мешает.
Подключать его можно init-скриптом, который монтируется в docker-compose.override.yml, и выполняет команду docker-php-ext-enable xdebug при запуске через docker-compose, а в проде тот же образ работает без xdebug
ты время-то замерь
и сравни с composer installподольше собирается только image magic, все остальное - единицы минут, один раз при деплое
MiksIr
miksir@home:~$
Ну если мы говорим про сборку приложения, то кеш композера (да и вендор папка) кладется в кеш CI и composer install занимает десяток секунд
да и build всего один раз нужен, далее pull
вот, замерил сборку расширений для 8ки по Dockerfile в начале темы на макбуке в тормознутой виртуалке docker desktop
14 расширений с библиотеками: bcmath gettext mysqli pdo_mysql pdo_pgsql pgsql pspell zip gd ds igbinary xdebug redis memcached
real 2m51.732s
для конкретного проекта нужна половина, экономию скольких спичек вы обсуждаете?
14 расширений с библиотеками: bcmath gettext mysqli pdo_mysql pdo_pgsql pgsql pspell zip gd ds igbinary xdebug redis memcached
real 2m51.732s
для конкретного проекта нужна половина, экономию скольких спичек вы обсуждаете?
а сколько часов в год на настройку, обновление, мониторинг и бекап серверов репозитория, CI и VPN? или сколько денег в месяц за облако?
MiksIr
miksir@home:~$
Да не сильно больше, чем потратили уже болтовней в этой теме =)а сколько часов в год на настройку, обновление, мониторинг и бекап серверов репозитория, CI и VPN? или сколько денег в месяц за облако?
Ну, Github Actions идёт вместе с приватными репами один фиг. Nexus да, ну его несложно поднять, тем более один фиг уже был для maven. Скорее вопрос сколько денег девопсу)а сколько часов в год на настройку, обновление, мониторинг и бекап серверов репозитория, CI и VPN? или сколько денег в месяц за облако?