Как мною проверены 74 Docker-контейнера и подготовлены патчи PHP без остановки production
Задача состояла в снижении риска устаревших PHP runtime сразу в нескольких проектах. Мой подход — сначала зафиксировать работающую систему, затем подготовить кандидатные изменения и проверить их отдельно. Подготовка патча и разрешение на его выкладку — разные решения.
Что именно было сделано
Мною составлена инвентаризация фактических runtime, образов, расширений и способов запуска приложений. Подготовлены security patches для 12 проектов; phpMyAdmin рассматривался как отдельный образ. Результат этого этапа — изменения для review и кандидатные образы, а не обновлённый production.
У каждой ветки PHP свой путь совместимости. Выбор целевой версии связывался с применимостью исправлений и требованиями приложения; сам факт наличия нового тега не считался проверкой.
Почему сначала read-only
До исправлений важно знать, что именно работает: версии внутри контейнеров могут отличаться от ожидаемых по Dockerfile. Отдельно нужны зависимости, фоновые процессы и конфигурация запуска. Иначе успешная локальная сборка может не иметь отношения к реальному сервису.
Read-only инвентаризация отделена от модификаций. Для тестового этапа использовались отдельные копии и контексты сборок, без подключения production volumes, рабочих секретов и существующих данных.
Как были изолированы сборки и тесты
Собственные кандидатные образы
Новые сборки получили отдельные теги. Исходные production Dockerfiles и рабочие Compose-конфигурации не менялись.
Синтетические данные
Проверки БД, Redis, очередей и scheduler выполнялись в отдельной среде. Реальные задания и внешние отправки не запускались.
Ограниченные ресурсы
Основные сборки выполнялись последовательно с лимитами CPU и памяти, чтобы контролировать нагрузку на общий сервер.
Явная применимость
Неприменимый или непроверенный сценарий не записывался как успешный тест.
Что подтверждают 13 успешных сборок
13 из 13 целевых runtime/image сборок завершились успешно. Для девяти Laravel-копий отдельно проверены Composer platform requirements, PHP lint, CLI boot и HTTP health. HTTP-проверка учитывала не только статус 200, но и ожидаемое содержимое без fatal error.
- SQLite, отдельные MariaDB и MySQL 8.4 проверены на тестовых данных.
- Redis проверялся там, где он используется, с соответствующим клиентским драйвером.
- Worker обработал синтетическую задачу; scheduler выполнил безопасный тестовый callback.
- WebSocket проверен в применимом проекте по handshake и событию установления соединения.
- Для phpMyAdmin проверены HTTP и запрос к отдельной тестовой БД.
Что означает «без остановки production»
В рамках этого этапа production не обновлялся: не выполнялись commit, push, deploy, ручной restart или замена рабочих контейнеров. Идентификаторы всех 74 исходных контейнеров и образов, а также исходные Dockerfiles сохранены.
У трёх workers за время наблюдения зафиксирован штатно ожидаемый часовой lifecycle, согласующийся с их настройкой максимального времени работы. Поэтому корректная формулировка — отсутствие ручных перезапусков и выкладки; утверждать, что ни один процесс вообще не перезапускался, было бы неверно.
Это не измерение отсутствия влияния на latency: нагрузка ограничивалась, но отдельный нагрузочный эксперимент не проводился.
Что осталось за границами проверки
- Полные бизнес-сценарии и реальная production-маршрутизация не проверялись.
- Почта, Telegram, внешние RPC и очереди с существующими рабочими данными не использовались.
- Обновление PHP не закрывает автоматически advisories Composer-пакетов и системных библиотек.
- Для устаревших неподдерживаемых стеков нужен отдельный миграционный или backport-план.
- Восстановление production из резервной копии не репетировалось этим тестовым пакетом.
Мой следующий шаг перед rollout
Нужны подтверждённые резервные копии, критерии rollback, согласованное окно и план обновления всех компонентов, включая workers и scheduler. После проверки этих условий можно отдельно разрешать production deploy. Успешная сборка сама по себе таким разрешением не является.
Частые вопросы
13 успешных сборок означают готовность к выкладке?
Они подтверждают сборку и перечисленные проверки. Для deploy ещё нужны backup/rollback readiness, бизнес-проверки и отдельное разрешение.
Почему не обновить PHP прямо в рабочем контейнере?
Изменение без воспроизводимого образа и проверок усложняет оценку совместимости и возврат. Мой подход — кандидатная сборка, проверка и управляемая выкладка.