Mirror Manager — Help

Оглавление

Что это

Mirror Manager — источник правды по зеркалам riobet.com: какие домены есть, доступны ли они, заблокированы ли РКН, и когда нужно поднять новое зеркало вместо заблокированного.

status/weight заводятся и меняются вручную операторами прямо здесь. is_blocked ставится либо вручную через кнопку RKN-BAN, либо автоматически через uwuaff check — но только в сторону блокировки: снять is_blocked может исключительно оператор кнопкой Un-ban, автоматика этого никогда не делает.

На основе is_blocked сервис сам решает, нужно ли выпускать новое зеркало (см. Groups), и запускает для этого пайплайн automirrors-crypt в GitLab.

Дальше по цепочке: отдельный проект seo-frontend-nginx раз в час опрашивает mirrors-service (GET /api/v1/get-mirrors) и сам переключает is_active/redirect_to в своём inventory.yml, разворачивая nginx-конфиги на реальных серверах. Mirror Manager ничего не деплоит сам — он только решает и хранит статус.

Статусы зеркала (таблица Mirrors)

Как вручную вывести зеркало из ротации

1. Найти зеркало в таблице → кнопка Disable (или Edit → Status = unavailable → Save).
2. У статуса появится 📌 — это просто фиксирует, что статус выставлен оператором вручную. Снимается кнопкой Un-pin.
3. Дождаться следующего часового прогона seo-frontend-nginx (или запустить его пайплайн вручную) — он увидит status=unavailable, выберет живого соседа по группе (riobet40x/riobet_1000) как redirect_to и задеплоит редирект.

Weight

Ручной приоритет (меньше — важнее). Заводится и меняется вручную, ничем автоматически не перезаписывается.

⛓ Groups — пулы и цепочки

Group — это политика, по которой mirrors-service сам решает, когда запускать пайплайн automirrors-crypt и выпускать новый домен. Оценивается сразу после каждого RKN-BAN.

pool — держать N доступных одновременно

Пример: группа riobet40x, target_pool_size = 8. Если из доменов с тегом riobet40x доступно (available, не заблокировано, не disabled) меньше 8 — заказывается разница (deficit), с учётом уже выпускаемых (provisioning, чтобы не заказать дважды). Новые домены берут следующий свободный номер после максимального когда-либо использованного в диапазоне number_min–number_max — номера не переиспользуются.

chain — одно текущее зеркало, замена при блокировке

Пример: цепочка riobet2000. "Головой" считается домен с максимальным номером среди немаркированных как provisioning. Пока голова не заблокирована — ничего не происходит. Как только голову блокируют — заказывается следующий по номеру домен, а голова становится predecessor (на неё ставится redirect_to в inventory.yml при онбординге).

range_exhausted — если number_max исчерпан, а зеркало всё ещё нужно, автоматика останавливается и шлёт алерт в Slack; поднимите number_max в Groups.

Кнопка Preview plan в Groups показывает точно то же решение, что приняла бы автоматика прямо сейчас — без побочных эффектов (ничего не создаёт, пайплайн не запускает). Полезно проверить перед тем, как включать enabled или прописывать GitLab-токен.

Выпуск строго по одному — и как разгружается очередь

Зеркала выпускаются по одному на всю систему, а не по одному на группу: два одновременных пайплайна automirrors-crypt будут драться за один и тот же свободный IP при выборе (pick_free_ip()), поэтому пока хоть одно зеркало в статусе provisioning — ни одна другая группа ничего не заказывает. В Preview plan это видно как причина вида "another mirror is currently provisioning in a different group".

Соответственно, если блокировки пришли пачкой (например, uwuaff нашёл сразу пять), то преемник закажется только для первой группы, а остальные отложатся. Дальше отложенная очередь разгружается сама, по одному, тремя способами:

• Реактивно — в момент, когда зеркало покидает provisioning: seo-frontend-nginx пометил его available после своей health-проверки, оператор удалил зависшую запись, или зафиксировал её через Set Active. Это основной путь: следующее зеркало уходит в выпуск сразу же, без ожидания.
• Плановый sweep — раз в pool_sweep_interval_seconds (по умолчанию 300с = 5 минут). Это сейф-нет для случаев, которые реактивный хук увидеть не может: пайплайн умер на середине и зеркало так и не стало available, или запрос в GitLab вообще не ушёл. Без него очередь встала бы до следующего бана.
• Вручную — кнопка Evaluate now в Settings (POST /api/v1/groups/evaluate), если нужно слить очередь немедленно.

Любой из трёх запускает максимум один пайплайн за раз — сколько бы групп ни ждало. Зеркало, зависшее в provisioning дольше часа, подсвечивается на главной оранжевым и счётчиком в шапке: это как раз тот случай, когда очередь стоит из-за него и запись нужно поправить или удалить руками.

🚫 RKN-BAN — форсировать пересборку цепочки/пула вручную

Кнопка в таблице Mirrors (напротив каждого зеркала). В отличие от Disable/Enable, она трогает не status, а is_blocked — а редирект на стороне seo-frontend-nginx ориентируется только на status. Поэтому зеркало продолжает отдаваться в выдаче как обычно, а Groups оцениваются немедленно — если зеркало было головой цепочки, преемник закажется прямо сейчас.

Тот же самый эффект (is_blocked=true + немедленная оценка Groups) может сработать автоматически — см. uwuaff check ниже, который жмёт эту кнопку сам, когда находит новую блокировку. Разница видна только в block_type (manual vs uwuaff) и в колонке Trigger на странице Runs (manual vs scheduled).

• В колонке Blocked это будет видно как Yes.
• Кнопка сразу показывает тостом, что было заказано (issued: riobet1003.com), и пишет запись в job rkn_ban на странице Runs.
• Если в этот момент уже выпускается другое зеркало (любой группы), заказ отложится — в тосте будет issued: none. Это нормально: очередь разгрузится сама, как только текущее зеркало встанет (см. "Выпуск строго по одному").
• Кнопка Un-ban снимает бан всегда, независимо от того, кто его поставил (оператор или uwuaff check). Но если сам uwuaff всё ещё считает домен заблокированным, следующий плановый чек снова поставит бан — см. предупреждение в uwuaff check.

Требования те же, что и для автовыпуска: зеркало должно быть протегировано mirror_tag нужной Group, а сама Group — существовать и быть enabled. Если группы нет или тега нет — кнопка отработает, но в Runs будет issued: none.

uwuaff check — статус блокировки от api.uwuaff.com + авто-RKN-BAN

Раз в uwuaff_check_interval_seconds (по умолчанию 900с = 15 минут) сервис опрашивает GET api.uwuaff.com/v1/domains — это тот же uwuaff, куда seo-frontend-nginx регистрирует каждый домен (register-mirror-domain.yml/trigger-frontend-deploy.yml) и который сам гоняет собственные проверки на блокировку (RKN, прокси и т.д.). Результат по каждому известному домену сохраняется в колонку uwuaff.

Затем, если uwuaff нашёл новую блокировку (is_active: false) у зеркала, чьи теги пересекаются с mirror_tag какой-либо включённой Group, и которое ещё не is_blocked здесь — сервис сам жмёт RKN-BAN за оператора (block_type = 'uwuaff'): выставляет is_blocked=true и сразу оценивает Groups, заказывая преемника, если нужно. Зеркала вне какой-либо включённой Group авто-баном не трогаются — это касается и зеркал вообще без тегов, и зеркал с тегами, не связанными ни с одной Group (например, тег api у API/LB-хостов) — им просто некому заказать преемника, колонка uwuaff у них остаётся чисто информационной.

Важно про направление: это одностороннее действие — только на блокировку, никогда обратно. Ничего в uwuaff-чеке само не снимает is_blocked; это по-прежнему делает только оператор кнопкой Un-ban. Так сделано намеренно: раньше в проекте уже был похожий автоматический чек (по другому сервису, dump.allury.tech), который писал is_blocked в обе стороны — и молча снимал ручные RKN-BAN'ы, если сам не находил блокировку. Именно эта реверсия и была проблемой, от неё отказались; новый uwuaff-чек её не повторяет — он может только поставить блок, никогда не снять.

Побочный эффект одностороннего дизайна: если оператор нажмёт Un-ban на зеркале, которое uwuaff всё ещё считает заблокированным, следующий плановый чек (до 15 минут) снова поставит is_blocked=true. Чтобы бан не возвращался — либо дождитесь, пока uwuaff сам перестанет считать домен заблокированным, либо временно выключите чек в Settings.

• Yes — uwuaff считает домен заблокированным (is_active: false в его ответе). Наведите курсор — во всплывающей подсказке будет время проверки и текст причины от uwuaff (например, номер решения РКН).
• No — uwuaff считает домен активным.
• n/a — домен не зарегистрирован в uwuaff (не найден в его списке доменов).
• — — ещё ни разу не проверялся.

Каждый авто-бан пишет отдельную запись в job rkn_ban (trigger = scheduled) на странице Runs — как и ручной RKN-BAN, только с другим trigger. Сам опрос api.uwuaff.com пишется в job uwuaff_check.

Включается/выключается и настраивается интервал в Settings, там же кнопка Check now для ручного запуска и статус последнего прогона. Учётные данные (UWUAFF_TOKEN_URL/UWUAFF_CLIENT_ID/UWUAFF_CLIENT_SECRET/UWUAFF_API/UWUAFF_API_TOKEN) задаются переменными окружения контейнера — теми же GitLab CI/CD переменными, что уже использует seo-frontend-nginx, в UI не вводятся.

Kuma check — уборка мониторов Uptime Kuma

Когда automirrors-crypt поднимает новое зеркало, его собственная стадия kuma_monitor заводит HTTP-монитор в Uptime Kuma (https://{домен}/health). mirrors-service сам мониторы никогда не создаёт — только удаляет, и только когда зеркало становится неактивным.

Как срабатывает удаление: реактивно, сразу в момент, когда у зеркала is_active становится false — неважно из-за чего: ручной Disable, RKN-BAN (включая авто-бан от uwuaff), деактивация соседей при Set Active в chain, webhook /webhook/blocked. Плюс раз в kuma_check_interval_seconds (по умолчанию 900с = 15 минут) — плановая сверка: обновляет колонку Kuma для всех зеркал и подчищает мониторы, которые реактивная проверка могла пропустить (например, зеркала, ставшие неактивными ещё до появления этой функции).

Одностороннее действие, как и uwuaff-чек: только удаление, никогда не создаёт монитор обратно, даже если зеркало снова становится активным (Un-ban, повторный Enable). Если нужен монитор обратно — заводится вручную в самой Kuma или через новый прогон automirrors-crypt.

• Yes — у домена сейчас есть монитор в Kuma.
• No — монитора нет (удалён нами, либо никогда не заводился).
• — — ещё ни разу не проверялся.

Включается/выключается и настраивается интервал в Settings, там же кнопка Check now. Учётные данные (KUMA_URL/KUMA_USER/KUMA_PASS) — переменные окружения контейнера, в UI не вводятся.

Set Active — отдельно от Enable/Disable

Enable/Disable и Set Active — два разных, независимых переключателя, специально разделены:

• Enable/Disable — статус конкретного домена (грубо говоря, "должен ли этот домен вообще участвовать в ротации"), не знает про цепочки.
• Set Active — появляется только у зеркал, протегированных под chain-группу (⛓ Groups, mode=chain). Жёстко фиксирует: это зеркало — available, а все остальные зеркала с тем же тегом (та же цепочка) — unavailable. Гарантирует инвариант "ровно один активный на цепочку" — все затронутые зеркала получают 📌 (manual override).

Дальше это конвертируется в реальный редирект как обычно: sync_mirrors.py в seo-frontend-nginx видит, что "неактивные" зеркала группы теперь unavailable, и сам подставляет им redirect_to на активное — никаких изменений в seo-frontend-nginx для этого не потребовалось.

⚙ Settings — что где включается

Как всё это запускается

• Основной триггер для выпуска новых зеркал — кнопка RKN-BAN: сразу после того, как оператор ставит is_blocked=true, немедленно оцениваются все включённые Groups — если что-то нужно, тут же уходит запрос в GitLab на запуск automirrors-crypt.
• Отдельно от этого есть фоновый планировщик — раз в uwuaff_check_interval_seconds он опрашивает uwuaff check, обновляет колонку uwuaff, и при новой блокировке сам жмёт RKN-BAN (см. выше) — но только в сторону блокировки, никогда не снимает её.
• Тот же планировщик раз в kuma_check_interval_seconds подчищает мониторы в Kuma, а раз в pool_sweep_interval_seconds переоценивает Groups заново — чтобы отложенная очередь выпуска (см. "Выпуск строго по одному") не стояла в ожидании следующего бана.
• Плюс переоценка происходит в момент, когда любое зеркало покидает статус provisioning — именно так следующее зеркало из очереди уходит в выпуск сразу же, а не по таймеру.
• Раз в seo_sync_interval_seconds (по умолчанию раз в сутки) планировщик отдельно дёргает sync_mirrors-джобу в seo-frontend-nginx — она сверяет is_active/redirect_to в inventory.yml с текущими статусами здесь и передеплоивает всё, что разошлось. Не связана с выпуском новых зеркал — это отдельный, более медленный контур на редиректы уже существующих доменов.

Webhook — мгновенная блокировка

Если внешняя система узнала о блокировке, можно дёрнуть эндпоинт напрямую — статус обновится сразу, не дожидаясь ручного RKN-BAN:

curl -X POST https://mirrors-service.rioorg.com/webhook/blocked \
  -H "Content-Type: application/json" \
  -d '{"domain": "riobet403.com"}'

Это не ставит 📌 manual override.

▤ Runs — статус выполнения

Полная история запусков — не только "последний раз", а каждый прогон отдельной строкой:

Для каждой строки: время старта, длительность, ok/error, деталь (для automirrors_trigger — какой домен/группа), колонка Pipeline (ссылка на пайплайн в GitLab + его статус сразу после создания — created/pending) и полный текст ошибки по наведению.

Важно про статус пайплайна: Pipeline Trigger Token в GitLab умеет только запускать пайплайн, но не может потом прочитать его финальный результат (success/failed) — для этого нужен отдельный токен с правом чтения API, которого здесь нет. Поэтому колонка Pipeline показывает только начальный статус создания; реальный результат (прошёл ли деплой) смотрите по ссылке в самом GitLab.

▶ Trigger seo-frontend-nginx sync — только GitLab, без sync/check здесь

Кнопка на странице Runs запускает исключительно джобу sync_mirrors в проекте seo-frontend-nginx через её собственный Pipeline Trigger Token. Данные берутся ровно те, что прямо сейчас лежат в mirrors-service (наш status/is_active — источник правды), включая любые ручные 📌-изменения.

Что делает эта джоба на стороне seo-frontend-nginx: читает GET /api/v1/get-mirrors отсюда, для каждого известного хоста сравнивает с текущим inventory.yml, и если статус разошёлся — проставляет is_active: true/false (и redirect_to для заблокированных, подбирая живого соседа по группе riobet40x/riobet_1000 — только среди хостов, которые сам знает, см. ниже), коммитит и деплоит nginx-конфиги на изменившихся хостах.

На странице Runs — две отдельные кнопки, специально разделённые, чтобы не катить вслепую:

• 🔍 Preview (check mode) — запускает пайплайн с SYNC_MIRRORS_CHECK=true: джоба посчитает изменения и выведет их в лог + артефакт inventory.diff, но ничего не закоммитит/не запушит/не задеплоит. Диф смотрите по ссылке на пайплайн, в логе джобы sync_mirrors или в артефактах.
• 🚀 Deploy for real — тот же расчёт, но уже коммитит inventory.yml, пушит и деплоит nginx-конфиги на изменившихся хостах.

Чтобы кнопки заработали, нужно:

1. В Settings → seo-frontend-nginx указать Project ID и Pipeline trigger token (GitLab → тот проект → Settings → CI/CD → Pipeline trigger tokens).
2. В seo-frontend-nginx/.gitlab-ci.yml у джобы sync_mirrors должно быть правило if: '$CI_PIPELINE_SOURCE == "trigger"' — без него пайплайн от Trigger Token запустится, но выполнит ноль джоб.

Важно про выбор redirect_to: цель для редиректа выбирается только среди хостов группы (riobet40x/riobet_1000), которые реально зарегистрированы в mirrors-service и сейчас доступны. Хост, которого mirrors-service вообще не знает (например, добавлен в inventory.yml вручную и никогда не заводился здесь), никогда не будет выбран как цель — раньше это было не так, и именно из-за этого редиректы иногда улетали на несуществующее/неотслеживаемое зеркало вместо реально живого соседа.

Частые проблемы