Аудит Docker-инфраструктуры: 74 контейнера, патчи для 12 проектов и 13 успешных сборок
Мною подготовлен пакет PHP security-изменений для нескольких проектов на общем Docker-сервере. Критичным условием было сохранить работающие сервисы и получить проверяемые кандидатные сборки до решения о rollout.
Инвентаризация перед изменениями
Проверены фактические runtime, используемые образы и расширения. Разные приложения, workers, scheduler и отдельный phpMyAdmin требовали разных проверок. Подготовленные изменения отделены от исходных production Dockerfiles и конфигурации.
Кандидатные образы и совместимость
Для 12 проектов подготовлены security patches, phpMyAdmin вынесен в отдельную цель сборки. Все 13 runtime/image targets собраны. В девяти Laravel-копиях проверены platform requirements, lint, CLI boot и строгий HTTP health.
PHP и приложение
Проверены версии runtime, сохранение модулей и загрузка приложения; HTTP 200 не считался достаточным без ожидаемого ответа.
Данные и фоновые процессы
SQLite, отдельные MariaDB/MySQL, Redis по применимости, синтетические задачи worker и scheduler.
Специальные проверки
WebSocket handshake для применимого сервиса и HTTP/DB-проверка отдельного phpMyAdmin.
Изоляция
Отдельные контексты и тестовые данные; production volumes, секреты и реальные бизнес-задания не подключались.
Что было сохранено
Идентификаторы всех 74 исходных контейнеров и образов остались прежними; исходные Dockerfiles не изменены. Commit, push и production deploy в рамках этого пакета не выполнялись. Ручных перезапусков не было.
У трёх workers наблюдался штатно ожидаемый часовой lifecycle. Это отражено в отчёте, а не скрыто формулировкой «ни одного перезапуска». Нагрузка была ограничена; отсутствие влияния на latency отдельно не измерялось.
Ограничения и остаточные риски
Тестовый пакет не проверял полные бизнес-сценарии, production routing, реальные внешние сервисы и обработку существующих очередей. PHP-патчи не устраняют автоматически все advisories зависимостей и системных пакетов. Устаревшие неподдерживаемые стеки требуют отдельного решения.
Результат: пакет для review
Подготовлены кандидатные патчи, образы и результаты перечисленных smoke/integration проверок. Это готовность изменений к review, а не завершённый production deploy.
Перед rollout нужны backup/rollback readiness, согласованное окно, бизнес-проверки и отдельное разрешение на управляемое обновление приложений и фоновых сервисов.
Частые вопросы
Почему патчи не выложены сразу?
Исходный объём включал подготовку и проверки, а production deploy требовал отдельного разрешения. Это граница работы, а не завершённая выкладка.
Что проверять перед обновлением workers?
Совместимость приложения, обработку очереди, завершение текущих задач, конфигурацию запуска и условия возврата. Реальные рабочие задания в этом тестовом пакете не использовались.