Коли потрібно оновити PHP через критичну вразливість, легко звести задачу до php -v, нового образу і перезапуску контейнера. У Laradock цього недостатньо.
Один локальний проєкт може працювати через PHP-FPM 8.3, інший через 8.4 або 8.5, а окремі workspace можуть бути зупинені. Додатково phpMyAdmin має власний PHP runtime.
Тому перед змінами я спочатку збираю інвентаризацію: які PHP runtime існують, що запущено, що зупинено, які images використовують контейнери і що фактично описує Docker Compose.
Чому одного php -v недостатньо
php -v у звичайному Ubuntu-терміналі показує PHP на хості. Він не показує версію всередині PHP-FPM, workspace або phpMyAdmin.
У моєму локальному Laradock потрібно було окремо врахувати PHP 8.3, 8.4 і 8.5. Тому перша перевірка фіксує хостовий PHP, але не робить з нього висновок про Docker.
php -vcommand -v php for binary in php8.2 php8.3 php8.4 php8.5; do if command -v "$binary" >/dev/null 2>&1; then echo "===== $binary =====" "$binary" -r 'echo PHP_VERSION, PHP_EOL;' fidoneПеревіряємо фактичну Docker Compose конфігурацію
У Laradock може бути кілька Compose-файлів та override. Тому важливо перевіряти саме ту комбінацію, з якою середовище реально запускається.
Для першого проходу я не виводжу весь resolved config, бо він може містити розгорнуті environment values. Замість цього перевіряю валідність, список сервісів і список images.
cd ~/Projects/laradock || exit 1 docker compose config -q echo "===== SERVICES ====="docker compose config --services echoecho "===== IMAGES ====="docker compose config --imagesДивимося не лише запущені, а й зупинені контейнери
docker ps показує тільки активні контейнери. Для security-оновлення цього замало, тому що старий зупинений workspace може повернутися під час наступного запуску.
Я фіксую назву контейнера, image reference, image ID і стан. Image ID важливий, бо tag пізніше може вказувати вже на інший образ.
cd ~/Projects/laradock || exit 1 docker compose ps -a echoecho "===== ALL CONTAINERS =====" docker ps -a \ --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'ids="$(docker ps -aq)" if [ -n "$ids" ]; then docker inspect \ --format '{{.Name}} | image={{.Config.Image}} | image_id={{.Image}} | state={{.State.Status}}' \ $idsfiОкремо перевіряємо PHP-FPM 8.3, 8.4 і 8.5
Назва сервісу або image tag не є достатнім доказом patch version. Для вже запущених PHP-FPM я читаю PHP_VERSION безпосередньо з контейнера.
docker compose exec -T не запускає зупинений сервіс, тому перевірка не змінює його стан.
cd ~/Projects/laradock || exit 1 for service in php-fpm-83 php-fpm-84 php-fpm-85; do echo "===== $service =====" docker compose exec -T "$service" \ php -r 'echo PHP_VERSION, PHP_EOL;' \ || echo "$service is not running"doneWorkspace важливий навіть тоді, коли він зупинений
У моєму Laradock окремі workspace для PHP 8.3, 8.4 і 8.5 мали різні стани. Зупинений workspace не потрібно запускати тільки заради інвентаризації.
Спочатку достатньо побачити його стан та image. Якщо workspace уже працює, тоді можна окремо прочитати його PHP_VERSION.
cd ~/Projects/laradock || exit 1 docker compose ps -a \ workspace-83 \ workspace-84 \ workspace-85 for service in workspace-83 workspace-84 workspace-85; do echo "===== $service =====" docker compose exec -T "$service" \ php -r 'echo PHP_VERSION, PHP_EOL;' \ || echo "$service is not running"doneНе забуваємо про phpMyAdmin
phpMyAdmin не є runtime Laravel-застосунку, але він теж виконує PHP у локальному Docker-середовищі. Через це його версію потрібно включити в security-інвентаризацію.
cd ~/Projects/laradock || exit 1 docker compose ps -a phpmyadmin docker compose exec -T phpmyadmin \ php -r 'echo PHP_VERSION, PHP_EOL;' \ || echo "phpmyadmin is not running"Перевіряємо локальні Docker images
Контейнер показує поточне використання, а список images показує, що вже лежить локально і може повернутися під час наступного запуску або rebuild.
Я фіксую repository, tag, image ID і приблизний вік образу.
docker image ls \ --format 'table {{.Repository}}\t{{.Tag}}\t{{.ID}}\t{{.CreatedSince}}' \ | grep -Ei 'php|workspace|phpmyadmin|laradock'Перевіряємо базові образи та PHP build arguments
Локальний image tag не пояснює, з чого образ був зібраний. Тому я також перевіряю релевантні FROM та ARG PHP_VERSION у Dockerfile.
Це допомагає відрізнити старий контейнер від ситуації, коли сам build усе ще спирається на застарілу PHP-базу.
cd ~/Projects/laradock || exit 1 grep -RInE \ '^(ARG PHP_VERSION|FROM .*php|FROM laradock/)' \ php-fpm \ workspace \ 2>/dev/nullЩо потрібно зафіксувати перед оновленням
Після інвентаризації я маю базову карту локального середовища:
- версії PHP на Ubuntu-хості;
- стан і версії PHP-FPM 8.3, 8.4 і 8.5;
- стан workspace 8.3, 8.4 і 8.5;
- PHP у phpMyAdmin;
- image references та image IDs контейнерів;
- локальні PHP-пов’язані images;
- сервіси та images з фактичної Compose-конфігурації;
- базові образи й PHP build arguments.
Тільки після цього можна вирішувати, що саме потрібно rebuild, recreate або замінити.
Чого не робити під час першої інвентаризації
На першому етапі я не запускаю зупинені workspace лише для перевірки, не виконую звичайний docker compose up, не роблю rebuild і не видаляю старі images.
Спочатку потрібно зафіксувати стан. У великому Laradock одна команда може вплинути одразу на кілька локальних проєктів.
Перед security-оновленням важливо знати не лише яку версію PHP ви плануєте встановити, а які PHP runtime ваше середовище використовує прямо зараз.
Підсумок
Оновити один PHP image і вважати задачу завершеною було б помилкою. PHP-FPM, workspace, phpMyAdmin, зупинені контейнери, локальні images і Compose можуть мати різний стан.
Тому перед security-оновленням Laradock я спочатку збираю доказову інвентаризацію без змін. Наступний крок - перевірити, чи оновлений Docker image справді залишиться тим образом, який Compose використає під час наступного запуску.
