92 lines
7.3 KiB
Markdown
92 lines
7.3 KiB
Markdown
---
|
||
title: sched-pipelines-local-stack — ранбук локального стенда (sched + воркеры @apilki)
|
||
type: concept
|
||
tags: [runbook, sched, apilki, worker, deadline, cancel, local-stand]
|
||
related: [concepts/runbooks-index.md]
|
||
updated: 2026-08-26
|
||
---
|
||
|
||
# sched-pipelines-local-stack — локальный стенд пайплайнов клиентов
|
||
|
||
> **⚙️ СЛУЖЕБНЫЙ РАНБУК — только для администратора проекта `.admin`.**
|
||
> Применять/выполнять шаги может только **`.admin`** (оператор проекта admin). Другим проектам/агентам — читать по запросу, не выполнять.
|
||
> Из проекта не выносить: не копировать в другие вики, не пересказывать, не публиковать.
|
||
> Нужен деплой или прод-операция по этому ранбуку — **поставить задачу админу (`.admin`) и написать письмо**. Админ выполняет, остальные верифицируют.
|
||
|
||
Локальный стенд: sched daemon + HTTP-воркеры (yandex-market-partner-api-client, ozon-seller-api-client)
|
||
+ CDP-browser + локальный ntfy + alert-bridge. Цель — обкатка пайплайнов клиентов `@apilki`
|
||
против моков (verdaccio + Gitea) перед миграцией на VDS.
|
||
|
||
## Локация и команды
|
||
|
||
```bash
|
||
cd ~/projects/.admin/host-stacks/local/sched-pipelines
|
||
node render-tasks.cjs # рендер tasks.generated.json из tasks.json + .env
|
||
docker compose up -d --build # сборка + запуск
|
||
docker compose up -d --force-recreate schedd # применить НОВЫЙ tasks.json (см. gotcha 2)
|
||
docker compose logs -f schedd
|
||
```
|
||
|
||
- Admin API sched: `127.0.0.1:18080`, ключ `SCHED_ADMIN_KEY` (pass `sched-pipelines/local/*`).
|
||
- Триггер рана: `POST /api/tasks/<name>/run` (Bearer admin key).
|
||
- Секреты: `.env` (gitignored) ← `pass sched-pipelines/local/*`.
|
||
|
||
## Компоненты
|
||
|
||
| Сервис | Хост-порт | Образ |
|
||
|---|---|---|
|
||
| schedd | 127.0.0.1:18080 | `sched-pipelines/schedd:local` (daemon с verdaccio) |
|
||
| ym-client-builder | 127.0.0.1:18090 | `sched-pipelines/ym-client-builder:local` (из репо yandex) |
|
||
| ozon-seller-builder | 127.0.0.1:18091 | `sched-pipelines/ozon-seller-builder:local` (из репо ozon) |
|
||
| browser-cdp, ntfy, alert-bridge, unisender-mock | — | локальные |
|
||
|
||
Воркеры собираются из dev-репо: `../../../../yandex-market-partner-api-client` (Dockerfile),
|
||
`../../../../ozon-seller-api-client` (service/Dockerfile). **Свежие фичи на стенд = pull репо + `docker compose build ym-client-builder ozon-seller-builder` + up -d.**
|
||
|
||
## Таймаут-сценарий (deadline-stop, ратифицирован 2026-08-26)
|
||
|
||
Инцидент: sched при poll-timeout помечал ран failed, но НЕ слал воркеру cancel — воркер доделывал
|
||
пайплайн с реальным publish. Вердикт расходился с реальностью. Закрыт двумя слоями:
|
||
|
||
1. **Воркер** (yandex #1276, ozon #1278, паттерн C): `data.timeoutMs` (relative) / `data.deadlineMs`
|
||
(absolute epoch) / env `WORKER_TIMEOUT_MS` → локальный таймер ставит флаг, пайплайн стопается
|
||
на границе стадий ДО мутаций (publish/githubDistro). Вердикт: `failed`, `error: deadline exceeded`,
|
||
`result {verdict: 'timeout', timedOut: true, failedStage}`. Операторский cancel остаётся `cancelled`.
|
||
2. **sched** (#1277, core 0.53.0): при task-ceiling (`task.timeoutMs`) сам шлёт `POST /cancel` воркеру
|
||
перед записью вердикта failed (`run timeout after Nms`).
|
||
|
||
Проверено на стенде 2026-08-26:
|
||
- воркер: `[deadline] fired ... stop before mutations` → `[cancel] stop before stage fix` → failed, verdaccio чист;
|
||
- sched: `[cancel] received/flag set runId=<id>` в логах воркера → failed, verdaccio чист.
|
||
|
||
## Gotchas (2026-08-26)
|
||
|
||
1. **`task.timeoutMs` ≠ `config.timeoutMs`.** `task.timeoutMs` — task-level ceiling (run-deadline,
|
||
при срабатывании sched шлёт cancel + failed «run timeout after Nms»). `config.timeoutMs` —
|
||
транспортный таймаут ОДНОГО poll-запроса (дефолт 30s). Если транспортный < ceiling — ран упадёт
|
||
по транспортному (в ветке poll-ошибки cancel НЕ шлётся!) раньше, чем сработает ceiling.
|
||
Настройка: `task.timeoutMs: 120000` (ceiling) + `config.timeoutMs: 300000` (транспортный > ceiling).
|
||
2. **`applyTask` при upsert существующей таски НЕ обновляет `data` и `config.timeoutMs`** (переносит
|
||
только task.timeoutMs). Изменение `data` в tasks.json требует `docker compose up -d --force-recreate schedd`
|
||
(просто `up -d` не пересоздаёт контейнер, таска в БД остаётся старой). Диагностика: `GET /api/tasks`
|
||
— сверить, что новое поле реально в API.
|
||
3. **Состояние воркеров** — bind-mount `data-ym/state.json`, `data-ozon/state.json` (не в слое образа).
|
||
Перед форс-тестом полного пайплайна — сбросить state (`{"verdictHistory": []}`) с бэкапом.
|
||
После теста — восстановить из бэкапа, иначе следующий ран пойдёт по-старому.
|
||
4. **Логи ранов двух воркеров перемешиваются** в одном stdout — различать по `runId` в строках
|
||
`[deadline]/[cancel]` и по таймштампам (`docker logs -t`).
|
||
5. **schedd молчит в stdout** — диагностика ранов через admin API (`/api/runs`, error-поле),
|
||
события cancel — только в логах ВОРКЕРА (`[cancel] received/flag set`).
|
||
6. **`classify: таблица рецептов не прочитана (/app/recipes.json)`** — рецепты не смонтированы в
|
||
образ ym-client-builder, все изменения классифицируются как auto. Некритично для мок-стенда,
|
||
при миграции на VDS смонтировать.
|
||
7. **Локальный дедлайн теста**: deadlineMs/таймер проверяются на границе стадий — если стадия долгая
|
||
(generate ~15 мин), стоп случится ПОСЛЕ неё (лог `[cancel] stop before stage <next>`), это ок.
|
||
|
||
## Связи
|
||
|
||
- `runbooks-index.md` — индекс ранбуков.
|
||
- Таска-источник: `.tasks/done/2026-08-20-00746-sched-pipelines-local-stack.md` (мок-кампания 2026-08-20/21).
|
||
- `publish-model` (yandex-market-partner-api-client) — модель пайплайна клиентов.
|
||
- `worker-deadline-contract.md` (yandex wiki:3254) — конвенция deadline-stop паттерна C.
|