#Docker

Захотілося, щоб після невдалого інтеграційного тесту я бачив журнал сервісів з Docker Compose. Бо в мене на CI вже й так журнал друкується наприкінці збірки, але за тим загальним журналом складно знайти потрібне місце.

Перше питання стало — як взагалі в Go викликати код після тесту? Рішення в стандартній бібліотеці не знайшов, але ті тести виконуються пакетом testify/suite, а в нього є метод TearDownTest(), проміж інших. Тож тут проблем немає.

…Далі, як дізнатися, що тест був невдалий? Я очікував якогось аргументу в колбеці, але ні. Насправді той обʼєкт *testing.T, навколо якого обертаються тести, має метод t.Failed(). (Взагалі раджу його вивчити детальніше, бо там багато чого цікавого, наприклад, можливість отримати тимчасову директорію для одного тесту - t.TempDir().) А в testify/suite, до речі, через s.T() отримуємо той самий обʼєкт.

(PS: а ще в testify/suite знайшов suite.HandleStats - якщо його оголосити, то цей метод буде викликаний наприкінці всього пакету зі статистикою про час виконання та результати тестів.)

Окей, тепер, як отримати логи? Спробував через програмний клієнт Docker… надто низькорівневий, бо він повертає для логи конкретного контейнера, та ще й потоком. А мені потрібні зведені логи всіх контейнерів в проєкті. Тому просто викликаю консольну команду docker compose. Для того є зручний високорівневий тип exec.Cmd. Йому можна прямо сказати “спрямуй вивід команди в мій вивід” і все, готово.

Для продовження моїх експериментів з нейронними мережами доведеться запускати багато всього на компʼютері з Windows. Згадав, що в Docker є “віддалений контекст” роботи, та розібрався з ним.

В мене так склалося, що Docker або на локальній машині, або десь в хмарі прихований за абстракцією. Ну або як мінімум десь на віддаленій машині, куди я заходжу по SSH. А віддалений контекст — то коли локальна команда docker керує рушієм, що запущений на іншій машині.

Якщо нічого не боятися, то можна просто відкрити підключення до Docker мережею. Але в такого рішення немає ніякої авторизації взагалі. Для автентифікації можна нагенерувати сертифікатів TLS. Проте то нудно.

Найпростішим буде тунелювати до Docker через SSH. У Windows є сервер OpenSSH - як додатковий компонент, який потрібно встановити, а потім увімкнути його сервіс. Далі можна підʼєднуватися до компʼютера за паролем — або додати SSH-ключ - майже як вдома!

Вдома, але не зовсім… З оболонкою Windows не хочеться мати справи. На щастя, для віддаленого контексту Docker це не перешкода, та працює він чудово. Спочатку створюємо конфігурацію командою docker context create, обираємо командою docker context use, та всі команди Docker будуть передані із локального середовища на виконання віддаленій машині. Для мене це просто магія! 🧙‍♂️

Єдиний нюанс — монтувати теки можна тільки ті, що на віддаленій машині. Що логічно, але трохи незручно. А контекст збірки береться з локальної машини (тобто можна копіювати потрібні файли в образ.)

Docker це чудово, питань нема. Сервіси ізольовані, запускай хоч один хоч десять. Можна без простою запустити нову копію, а потім моментально на неї перемкнутись. Але є ситуація, в якій модель контейнеризації трохи розвалюється. Це коли контейнер має приєднану директорію, яка ще й зберігає стан.

Як яскравий приклад: в Docker недоцільно запускати базу даних. Якщо воно у вас локально та не страшно все зупинити та запустити наново — то най буде. Але в живому використанні, а то ще й на хмарному сервісі чи в Kubernetes - відразу виявиться проблемка: директорії зі станом зазвичай не розраховані на одночасне використання двома копіями сервісу. В кращому випадку отримаємо помилку на кшталт “сервіс вже запущений”, а в гіршому — вони тихо потроху псуватимуть стан.

Якщо вже сервіс розрахований на зберігання стану в файлах, я просто не знаю гарного рішення для запуску його в Docker. Окрім баз даних, це стосується, наприклад, WordPress, який погано почувається без можливості редагування власних файлів. Стан у файлах не є частиною застосунку 12 факторів. (Звісно, реальність така, що десь на файлах сидить база даних.)

Це не те щоб провина Docker - очевидно, що дві копії PostgreSQL в принципі не можна запустити одночасно з однієї директорії. Але з традиційною моделлю розгортування такої потреби й не виникає. (Щоправда, способу оновити PostgreSQL без простою я теж не знаю.)