Ryuk и уборка мусора

Связка «testcontainers ryuk» всплывает в багтрекерах не зря: без понимания механики половина поведения уборщика выглядит мистикой. При первом же контейнере библиотека заводит sidecar — контейнер из образа testcontainers/ryuk с именем reaper_<sessionID>, где sessionID — случайный идентификатор сессии. Ему монтируют docker.sock — без него убирать чужие ресурсы нечем, — ставят AutoRemove, чтобы он вычистил и сам себя, и ждут старта по журналу и порту: комбинированная стратегия ждёт строчку Started в логах и открытый порт 8080/tcp, который при желании сдвигается переменной RYUK_PORT. Дальше рукопожатие: тестовый процесс подключается к уборщику по TCP и передаёт набор фильтров по меткам сессии, тот отвечает ACK, и соединение считается рабочим. Уборщик — синглтон: второй контейнер не плодит второго уборщика, библиотека находит живого по меткам и имени и переиспользует. Старт не мгновенный: если уборщика нет, его находят или создают с ретраями и растущими паузами — на всё про всё около двадцати секунд, поэтому первый тест в прогоне просыпается чуть медленнее остальных. Пока тесты идут, создание каждого ресурса держит собственное соединение с уборщиком. Стоит процессу умереть — обрываются все разом. Рукопожатие — не формальность: ошибка подключения не глотается тихо, а после исчерпания попыток всплывает из создания контейнера на руки тесту, так что сломанный уборщик невозможно перепутать с медленным демоном.

Уборщик не гадает, что удалять: он сверяется с метками, а библиотека снабжает ими всё, что создаёт. Служебный набор скромен: org.testcontainers=true, язык go, версия библиотеки, идентификатор сессии и — главный — org.testcontainers.reap, разрешение на зачистку. Разрешение ставится только при включённом уборщике: выключите Ryuk — меток reap на ресурсах не будет вовсе, и автозачистка теряет право голоса. Маркировка достаётся и сетям: при создании библиотека дописывает тот же набор, поэтому сеть-сирота не переживёт сессию. Меченым оказывается вообще всё, что выходит из провайдера, — включая вспомогательные контейнеры вроде sshd-проброса портов, который библиотека заводит для доступа к локальным службам изнутри контейнера. Пространство имён org.testcontainers — служебное: метку с таким префиксом библиотека отклонит с ошибкой, для своих пометок выбирайте собственный префикс. Что стирается по меткам: контейнеры, сети, тома. С томами тонкость: force-remove при Terminate сносит анонимные тома контейнера, а именованные переживают удаление — их перечисляют опцией RemoveVolumes или подметают prune'ом с фильтром по меткам. Наконец, уборщик прибирает и себя: AutoRemove срабатывает, когда зачищать больше нечего, — от sidecar не остаётся даже имени.

Выключатель один, сценариев два. Первый — переменная TESTCONTAINERS_RYUK_DISABLED=true: окружение сильнее файла, поэтому в CI дёргают именно её, и сравнение здесь строгое — выключит только литеральное true, единица или tRuE уборщика не остановят. Второй — свойство ryuk.disabled=true в ~/.testcontainers.properties: удобно включать флаг локально и надолго. Что происходит после: reaper-контейнер не стартует вообще, рукопожатий нет, метки reap не раздаются, автозачистки нет, старт первого теста чуть ускоряется — минус один контейнер в пачке. Оправданий ровно два. Первое — CI, где окружение одноразовое и уборку ведёт сам раннер: гонять уборщика в среде, которую снесут через минуту, — работа без клиента. Второе — отладка: выключенный уборщик оставляет контейнер живым после упавшего теста, и docker logs показывает всё, что нужно. Отдельная история — окружения, где уборщику не дают подняться: если демон отказывает в запуске, сначала проверьте флаг TESTCONTAINERS_RYUK_CONTAINER_PRIVILEGED=true и только потом думайте о глушении. Тонкие настройки живут в соседних переменных: RYUK_CONNECTION_TIMEOUT — таймаут на подключение, минута по умолчанию; RYUK_RECONNECTION_TIMEOUT — сколько ждать пропавшего клиента, десять секунд; RYUK_VERBOSE — болтливые логи уборщика.

Утечка после падения — не только контейнер. За один упавший прогон остаются контейнеры со своими лимитами памяти, занятые маппнутые порты, сети-сироты, на которые больше никто не ссылается, и тома, переживают удаление контейнера. При включённом уборщике всё это сходит за десятки секунд; при выключенном — копится до ручной зачистки, и на длинном CI-дне копится быстро: порты кончаются раньше места. Диагностика начинается с фильтра по меткам: docker ps -a --filter label=org.testcontainers показывает всё, что создала библиотека, — по меткам видно и язык, и сессию. Дальше точечная зачистка тем же фильтром: удалить контейнеры, подметать сети и тома. Тома отдельная глава: анонимные уходят вместе с контейнером, а именованные — например, pgdata-it из уроков про базы — остаются на диске после любого удаления и ждут либо RemoveVolumes в Terminate, либо volume prune по меткам. Сколько места съедено, говорит docker system df: его стоит смотреть и до, и после уборки. Вслепую пущенный docker system prune -a на общем демоне — оружие массового поражения: с ним уходят и чужие образы, поэтому фильтр по меткам — не паранойя, а вежливость. Для локального docker правило одно: чистка по меткам безопасна, чистка по вдохновению — нет.

Единой политики не существует: уборка — решение окружения, и таблица ниже собирает типовые конфигурации в одну карту. Между строк таблицы живёт и настройка сессии. По умолчанию каждый процесс тестов получает собственный случайный sessionID и собственный уборщика — для go test ./... с параллельными пакетами это целая пачка reaper'ов, каждый со своими метками. Переменная TESTCONTAINERS_SESSION_ID фиксирует идентификатор: все процессы пользуются одним уборщиком, где бы ни стартовали. Значение проверяется на допустимые символы — буквы, цифры, точки, дефисы, подчёркивания; слэш в нём уронит прогон паникой ещё до первого теста, и это правильно: лучше громкий старт, чем тихая путаница меток в середине. Оборотная сторона фиксации — общие метки: на общем демоне один sessionID означает, что kill одного воркера вынесет ресурсы всех, кто делит ту же сессию, поэтому на командном демоне у каждого своя сессия. Какая бы политика ни выпала окружению, рассуждать о разделяемых ресурсах и жизненных циклах процессов качает продвинутый курс по Go: там контексты и смерть процесса разбираются глубже, чем позволяет формат урока.