Архитектура

Исполнителя выбирает не ключ в конфиге, а пара «операция и цель». А сам раннер ничего не делает с базой: он оркестрирует чужие процессы — утилиты платформы 1С и EDT. Ниже по порядку: кто исполняет операции и как он выбирается, слои и процессы внутри раннера, варианты развёртывания 1С и время жизни компонентов.

Исходники

Формат — XML платформы или проект EDT. EDT перед работой с базой экспортируется в XML.
Тип — конфигурация, расширение, внешняя обработка, внешний отчёт. Любой тип бывает в любом формате.

Провайдеры

Проза инструмента никогда не решает — только переносится как улика.

Цели: два адреса

У базы всегда два адреса, и они разные. По одному раннер её администрирует, по другому её открывают клиентом или браузером. Строка подключения вида ws=… относится ко второму и не говорит, чем администрировать: за публикацией может стоять файловая база, кластер или автономный сервер.

Кластер и автономный сервер могут стоять на другой машине, и их файловая система раннеру недоступна. Поэтому workPath всегда локален, пути в командах, адресованных цели, разрешаются на её стороне, а результат с удалённой цели забирается объявленным каналом обмена, а не чтением чужого пути. Режим, где раннер сам поднимает процесс, работает только с локальной точкой входа.

Следствие для диагностики: журнал платформы на стороне цели и технологический журнал сервера раннеру не видны — квитанция их не обещает.

Адрес для клиента живёт в infobase.web.url: у автономного сервера он известен сразу, у остальных появляется после публикации.

Выбор провайдера

1. Умолчания заданы нами и живут в коде — матрица (операция, цель) → цепочка.
2. Раннер берёт первого готового в этом окружении.
3. providers.<операция> в конфиге переопределяет жёстко: неготовый — отказ, без отката.
4. На проводе и в CLI провайдера нет: вызывающий не выбирает исполнителя.
5. Квитанция объясняет выбор: selected, origin, skipped.

Эксперименты: как включить и выключить

Часть строк матрицы помечена экспериментальными: исполнитель реализован и прогнан, но в цепочку умолчаний не входит — раннер сам его не выберет. Включается он только явно, на одну операцию, ключом providers.<операция>; выключается удалением ключа. Другого выключателя нет: ни флага CLI, ни переменной окружения, ни состояния на диске.

Ключ пишется в v8project.yaml или в личный слой v8project.local.yaml — второй удобен, чтобы включить эксперимент у себя и не трогать общий конфиг:

providers:
  build: agent
  dump: agent

Проверить, что включилось, можно по квитанции в ответе любой команды: provider.selected называет исполнителя, provider.origin.kind: override — что его назначил ключ, а не умолчание. Валидация отвергает ключ там, где выбирать не из чего (у автономного сервера исполнитель один — agent через шлюз, ключ ему не нужен и не разрешён) и там, где названный исполнитель операцию не реализует; отказ называет, кто её реализует.

Экспериментальный исполнитель не откатывается: если он не готов (нет платформы для управляемого агента, точка входа не отвечает), команда отказывает, а не берёт следующего по цепочке. Место agent в цепочке умолчаний решится вместе с долгоживущей сессией: пока старт агента на каждую команду съедает выигрыш.

Изменилась ли база

У раннера две независимые проверки. По файлам исходников он считает хеши и хранит их в workPath — это отвечает на вопрос «что изменилось у меня». У платформы он спрашивает идентификатор поколения конфигурации — это отвечает на вопрос «менялась ли база».

Замер: токен основной конфигурации у Конфигуратора и ibcmd совпадает, а токены расширений у них разные — сравнивать нужно значения, полученные одним и тем же инструментом.

Агент: два режима

Правила

Unica вызывает CLI с --json-message. MCP — для хостов, подключающих раннер напрямую; там 8 инструментов.

Слои

flowchart TB
  subgraph adapters["Адаптеры транспорта"]
    CLI["cli
аргументы, текст и JSON"]
    MCP["mcp
8 инструментов, stdio и HTTP"]
  end
  UC["use_cases — оркестрация
замок, пайплайн, дедлайн"]
  subgraph shared["Общее"]
    CFG["config"]
    DOM["domain"]
    CD["change_detection"]
    PARS["parsers"]
  end
  PLAT["platform — вызов утилит"]
  SUP["support — файлы, staging, журналы"]
  CLI --> UC
  MCP --> UC
  UC --> CFG
  UC --> DOM
  UC --> CD
  UC --> PARS
  UC --> PLAT
  PLAT --> SUP

Процессы

flowchart LR
  R["раннер
CLI или MCP-сервер"]
  R -->|"процесс на операцию"| D["1cv8 DESIGNER"]
  R -->|"процесс на операцию"| I["ibcmd"]
  R -->|"сессия SSH"| A["агент: 1cv8 /AgentMode
или шлюз ibsrv"]
  R -->|"одна живая сессия"| E["1cedtcli"]
  R -->|"процесс на запуск"| C["клиент 1С"]
  R -->|"процесс на операцию"| W["webinst"]

Варианты развёртывания 1С

Вид цели решает, какими утилитами раннер работает, по какому каналу отдаёт команду и откуда забирает результат. Видов три — файловая база, кластер 1С, автономный сервер, — а машин под ними бывает сколько угодно. Ниже одиннадцать развёрток, которые встречаются на практике. Последние три отличаются не видом цели, а тем, кто владеет её процессом: служба, ваша консоль или контейнер.

• 1. Файловая база
• 2. Файловая база и веб-сервер
• 3. Кластер на своей машине
• 4. Кластер на другой машине, несколько rphost
• 5. Кластер, RAS поднят удалённо
• 6. Кластер и веб-сервер
• 7. Автономный сервер на своей машине
• 8. Автономный сервер на другой машине
• 9. Кластер поднят из консоли
• 10. Кластер 1С в контейнере
• 11. Автономный сервер в контейнере

Как читать схемы

Схемы нарисованы в нотации ArchiMate, уровень технологий: рамка — машина (node), прямоугольник — процесс (system software), скруглённый блок — точка входа (technology service), «документ» и цилиндр — данные (artifact), синий блок — сам раннер (application component). Подпись на стрелке называет канал и протокол; пунктир — сеть, сплошная — процесс или файл на той же машине. Серое — то, с чем раннер не разговаривает.

flowchart TB
  L1["процесс
утилита платформы"]
  L2(["точка входа
SSH-шлюз, HTTP"])
  L3@{ shape: doc, label: "файл или каталог" }
  L4@{ shape: cyl, label: "база данных СУБД" }
  L5["v8-runner"]
  L6["вне раннера"]
  class L1 sw
  class L2 svc
  class L3 art
  class L4 art
  class L5 run
  class L6 off
  classDef run fill:#cfe4fa,stroke:#3f7ba6,color:#0d2233;
  classDef sw fill:#cde8b9,stroke:#4f7a3c,color:#12210c;
  classDef svc fill:#e7f3dc,stroke:#4f7a3c,color:#12210c;
  classDef art fill:#f6e8c8,stroke:#a4813a,color:#241c0c;
  classDef off fill:#e4e4e7,stroke:#9a9aa2,color:#33333a;

Сам раннер ничего не исполняет. Утилиту он вызывает запуском процесса — аргументы командной строки, код выхода и журнал; с агентом и шлюзом говорит сессией SSH. Поэтому на стрелке от раннера стоит вид вызова, а не имя команды. Где раннер поднимает процесс сам, у стрелки написано «поднимает»: агент Конфигуратора он запускает и только потом к нему подключается, а шлюз автономного сервера поднимаете вы — туда идёт одна сессия.

Общая карта

Раннер запускает утилиты у себя и достаёт цель тремя способами: файлом, сетевым протоколом платформы и SSH. Четвёртого нет — консоль кластера и его RAS остаются вне раннера. Здесь показан только канал администрирования; чем и откуда базу открывает человек, видно в каждом варианте отдельно.

flowchart LR
  subgraph HOST["машина раннера"]
    R["v8-runner
CLI · MCP"]
    EDT["1cedtcli"]
    DES["1cv8 DESIGNER"]
    IBC["ibcmd"]
    WEB["webinst"]
    AGT(["1cv8 /AgentMode
127.0.0.1:1543"])
  end
  SRC@{ shape: doc, label: "исходники
XML, проект EDT" }
  FDB@{ shape: doc, label: "файловая база
каталог с 1Cv8.1CD" }
  CLU["кластер 1С
ragent · rmngr · rphost"]
  DBMS@{ shape: cyl, label: "СУБД" }
  GATE(["автономный сервер
SSH-шлюз ibsrv 1543"])
  WS(["Apache · IIS"])
  R -->|"одна живая сессия"| EDT
  R -->|"процесс на операцию"| DES
  R -->|"процесс на операцию"| IBC
  R -->|"процесс на операцию"| WEB
  R -->|"поднимает"| AGT
  R -->|"SSH 127.0.0.1:1543"| AGT
  R -.->|"SSH · SFTP"| GATE
  EDT --> SRC
  DES --> SRC
  DES -->|"файл"| FDB
  DES -.->|"TCP 1541"| CLU
  IBC -->|"--db-path"| FDB
  IBC -.->|"--dbms: прямо в СУБД"| DBMS
  AGT -->|"файл"| FDB
  AGT -.->|"TCP 1541"| CLU
  WEB -->|"публикация"| WS
  CLU --> DBMS
  class R run
  class DES,IBC,WEB,EDT,CLU sw
  class AGT,GATE,WS svc
  class SRC,FDB,DBMS art
  classDef run fill:#cfe4fa,stroke:#3f7ba6,color:#0d2233;
  classDef sw fill:#cde8b9,stroke:#4f7a3c,color:#12210c;
  classDef svc fill:#e7f3dc,stroke:#4f7a3c,color:#12210c;
  classDef art fill:#f6e8c8,stroke:#a4813a,color:#241c0c;
  style HOST fill:#eef5fb,stroke:#8fb4cf,color:#0d2233

Утилиты EDT к базе не подключаются: 1cedtcli работает только с исходниками, поэтому во всех одиннадцати вариантах он одинаков.

1. Файловая база

Всё на одной машине: и раннер, и платформа, и каталог базы. Самый частый случай для разработчика и для CI, который поднимает базу с нуля.

flowchart LR
  subgraph HOST["машина раннера"]
    R["v8-runner"]
    DES["1cv8 DESIGNER"]
    IBC["ibcmd"]
    AGT(["1cv8 /AgentMode
127.0.0.1:1543"])
    CLI["1cv8c · клиент"]
    IB@{ shape: doc, label: "каталог базы
1Cv8.1CD" }
    WP@{ shape: doc, label: "workPath
журналы, хеши, .cf, .dt" }
  end
  R -->|"процесс на операцию"| DES
  R -->|"процесс на операцию"| IBC
  R -->|"поднимает"| AGT
  R -->|"SSH 127.0.0.1:1543"| AGT
  R -->|"процесс на запуск"| CLI
  DES -->|"файл, монопольно"| IB
  IBC -->|"--db-path"| IB
  AGT -->|"файл"| IB
  CLI -->|"файл"| IB
  DES --> WP
  class R run
  class DES,IBC,CLI sw
  class AGT svc
  class IB,WP art
  classDef run fill:#cfe4fa,stroke:#3f7ba6,color:#0d2233;
  classDef sw fill:#cde8b9,stroke:#4f7a3c,color:#12210c;
  classDef svc fill:#e7f3dc,stroke:#4f7a3c,color:#12210c;
  classDef art fill:#f6e8c8,stroke:#a4813a,color:#241c0c;
  style HOST fill:#eef5fb,stroke:#8fb4cf,color:#0d2233

• Администрирование — infobase.connection: "File=…"; каталог базы обязан быть виден раннеру.
• Исполнители — designer по умолчанию, ibcmd следующим в цепочке там, где матрица его знает, и умолчанием у extensions; agent — по ключу. Точный состав по операциям — в таблице ниже.
• Обмен — общий диск: .cf, .dt и выгрузка XML пишутся прямо туда, куда сказано.
• Клиент и тесты — 1cv8c по той же строке; YAxUnit получает задание через /C RunUnitTests=…, Vanessa — через /Execute и /TESTMANAGER, отчёт возвращается файлом в workPath.
• Условие — платформа на машине раннера; операции Конфигуратора берут базу монопольно, чужой открытый сеанс их сорвёт.

2. Файловая база и веб-сервер

Файловая база и веб-сервер Apache или IIS на одной машине с раннером. У базы два адреса: по файловому пути её администрируют, по HTTP — открывают веб-клиентом.

flowchart LR
  subgraph HOST["машина раннера"]
    R["v8-runner"]
    WEBI["webinst"]
    DES["1cv8 DESIGNER"]
    CLI["1cv8c · клиент"]
    WS(["Apache · IIS
модуль wsap · wsisapi"])
    PUB@{ shape: doc, label: "каталог публикации
default.vrd" }
    IB@{ shape: doc, label: "каталог базы
1Cv8.1CD" }
  end
  BR(["браузер · тонкий клиент"])
  R -->|"процесс на операцию"| WEBI
  R -->|"процесс на операцию"| DES
  R -->|"процесс на запуск"| CLI
  CLI -->|"File=…, файл"| IB
  WEBI -->|"-dir, -wsdir, -connstr File=…"| PUB
  WEBI -->|"-confpath: правка конфига"| WS
  WS -->|"файл"| IB
  WS --> PUB
  DES -->|"файл, монопольно"| IB
  BR -.->|"HTTP · HTTPS, ws=…"| WS
  class R run
  class WEBI,DES,CLI sw
  class WS,BR svc
  class PUB,IB art
  classDef run fill:#cfe4fa,stroke:#3f7ba6,color:#0d2233;
  classDef sw fill:#cde8b9,stroke:#4f7a3c,color:#12210c;
  classDef svc fill:#e7f3dc,stroke:#4f7a3c,color:#12210c;
  classDef art fill:#f6e8c8,stroke:#a4813a,color:#241c0c;
  style HOST fill:#eef5fb,stroke:#8fb4cf,color:#0d2233

• Администрирование — infobase.connection: "File=…". Строка ws=… здесь не принимается: она называет клиентский адрес, а не канал администрирования.
• Публикация — publish собирает webinst из секции infobase.web: server, wsdir, dir, conf, os-auth. default.vrd замещается целиком, поэтому у команды есть превью, а снятие публикации — отдельный publish --delete.
• Где стоит веб-сервер — на машине раннера: webinst запускается локально, и dir обязан существовать на его файловой системе. Модуль веб-сервера открывает ту же файловую базу с диска, значит и ему она должна быть видна.
• Два пути у клиента — тонкий клиент открывает эту базу и по строке подключения File=… прямо с диска, и по веб-адресу через Apache или IIS. Оба пути запускает сам раннер: launch thin — по строке подключения, launch thin --via web — по infobase.web.url ws-соединением, launch web — тем же адресом в браузере. Умолчание здесь первое: вид цели файловый.
• Цена — пока в опубликованной базе есть живой сеанс, он держит её открытой, и монопольные операции Конфигуратора отказывают.

3. Кластер на своей машине

Сервер 1С и раннер стоят на одной машине. Данные базы держит СУБД, а раннер работает с ней через кластер — по строке подключения.

flowchart LR
  subgraph BOX["одна машина"]
    subgraph HOST["раннер и утилиты"]
      R["v8-runner"]
      DES["1cv8 DESIGNER"]
      IBC["ibcmd"]
      AGT(["1cv8 /AgentMode
127.0.0.1:1543"])
      CLI["1cv8c · клиент"]
      WP@{ shape: doc, label: "workPath
.cf, .dt, журналы" }
    end
    subgraph SRV["сервер 1С"]
      RAG["ragent 1540
rmngr 1541"]
      RPH["rphost 1560–1591"]
    end
  end
  DBMS@{ shape: cyl, label: "СУБД" }
  R -->|"процесс на операцию"| DES
  R -->|"процесс на запуск"| CLI
  R -->|"процесс на операцию"| IBC
  R -->|"поднимает"| AGT
  R -->|"SSH 127.0.0.1:1543"| AGT
  DES -->|"Srvr=…;Ref=…, TCP"| RAG
  CLI -->|"TCP"| RAG
  AGT -->|"TCP"| RAG
  IBC -->|"--dbms, --database-server"| DBMS
  RAG --> RPH
  RPH --> DBMS
  DES --> WP
  class R run
  class DES,IBC,CLI,RAG,RPH sw
  class AGT svc
  class WP,DBMS art
  classDef run fill:#cfe4fa,stroke:#3f7ba6,color:#0d2233;
  classDef sw fill:#cde8b9,stroke:#4f7a3c,color:#12210c;
  classDef svc fill:#e7f3dc,stroke:#4f7a3c,color:#12210c;
  classDef art fill:#f6e8c8,stroke:#a4813a,color:#241c0c;
  style BOX fill:#fbfbfc,stroke:#c3c9d0,color:#4b5560
  style HOST fill:#eef5fb,stroke:#8fb4cf,color:#0d2233
  style SRV fill:#f1f8ea,stroke:#8aad76,color:#12210c

• Администрирование — infobase.connection: "Srvr=localhost:1541;Ref=demo": утилиты раннера подключаются к кластеру обычными клиентами.
• Исполнители — designer по умолчанию, ibcmd в цепочке и умолчанием у extensions, agent — по ключу. ibcmd в кластер не ходит вовсе: серверную цель он открывает прямо в СУБД по секции infobase.dbms — она и нужна там, где раннер идёт в СУБД сам, прежде всего чтобы создать базу.
• Обмен — Конфигуратор работает на машине раннера, поэтому .cf, .dt и выгрузка XML остаются у него. Файлов сервера раннер не касается.
• Клиент и тесты — клиент поднимается по строке подключения; отчёт теста возвращается файлом в workPath.
• Что даёт соседство — ничего сверх удобства: канал к кластеру сетевой, файловая система сервера раннеру не принадлежит, журналы сервера ему не видны.

4. Кластер на другой машине, несколько rphost

Рабочая или тестовая база на сервере приложений с пулом рабочих процессов. Раннер дотягивается до неё по сети: файловая система сервера и его журналы ему недоступны.

flowchart LR
  subgraph HOST["машина раннера"]
    R["v8-runner"]
    DES["1cv8 DESIGNER"]
    CLI["1cv8c · клиент"]
    WP@{ shape: doc, label: "workPath
.cf, .dt, отчёты тестов" }
  end
  subgraph SRV["сервер приложений 1С"]
    RAG["ragent 1540 · rmngr 1541"]
    RP1["rphost"]
    RP2["rphost"]
    RP3["rphost"]
    LOG@{ shape: doc, label: "журнал регистрации,
технологический журнал" }
  end
  DBMS@{ shape: cyl, label: "СУБД
5432 · 1433" }
  R -->|"процесс на операцию"| DES
  R -->|"процесс на запуск"| CLI
  DES -.->|"TCP 1541, дальше 1560–1591"| RAG
  CLI -.->|"TCP"| RAG
  RAG --> RP1
  RAG --> RP2
  RAG --> RP3
  RP1 --> DBMS
  RP2 --> DBMS
  RP3 --> DBMS
  RP1 --> LOG
  DES --> WP
  class R run
  class DES,CLI,RAG,RP1,RP2,RP3 sw
  class WP,DBMS art
  class LOG off
  classDef run fill:#cfe4fa,stroke:#3f7ba6,color:#0d2233;
  classDef sw fill:#cde8b9,stroke:#4f7a3c,color:#12210c;
  classDef art fill:#f6e8c8,stroke:#a4813a,color:#241c0c;
  classDef off fill:#e4e4e7,stroke:#9a9aa2,color:#33333a;
  style HOST fill:#eef5fb,stroke:#8fb4cf,color:#0d2233
  style SRV fill:#f1f8ea,stroke:#8aad76,color:#12210c

• Администрирование — infobase.connection: "Srvr=srv:1541;Ref=demo"; раннеру нужен доступ к портам кластера и ничего больше.
• Рабочие процессы — сеанс отдаёт менеджер кластера одному из rphost; какому — раннер не выбирает и не знает. Соединение продолжается на порт из диапазона рабочих процессов, поэтому открытого наружу 1541 недостаточно.
• Обмен — результат остаётся на машине раннера: Конфигуратор здесь клиент, и путь выгрузки — его собственный.
• Чего не видно — журнал регистрации и технологический журнал сервера. Раннер их не читает, и квитанция их не обещает.
• Монопольные операции — чужие сеансы в других rphost сорвут update-db-cfg и снимок базы. Сеансами раннер не управляет: блокировку ставит администратор кластера.
• Агент — Конфигуратор в агентском режиме поднимается на машине раннера и ходит к кластеру тем же TCP, поэтому платформа нужна локально. Исключение одно: конфиг назвал уже поднятого агента ключом tools.designer_agent.attach — такого раннер не запускает, и платформа ему не нужна.

5. Кластер, RAS поднят удалённо

Сервер администрирования вынесен на отдельную машину, консоль и скрипты ходят к кластеру через него. Для раннера это соседний канал: он им не пользуется.

flowchart LR
  subgraph HOST["машина раннера"]
    R["v8-runner"]
    DES["1cv8 DESIGNER"]
  end
  subgraph SRV["сервер 1С"]
    RAG["ragent 1540 · rmngr 1541"]
    RPH["rphost"]
  end
  subgraph ADMIN["машина с RAS"]
    RAS(["RAS 1545"])
    RAC["rac · консоль"]
  end
  R -->|"процесс на операцию"| DES
  DES -.->|"TCP 1541, Srvr=…;Ref=…"| RAG
  RAS -.->|"TCP 1541"| RAG
  RAC --> RAS
  RAG --> RPH
  class R run
  class DES,RAG,RPH sw
  class RAS,RAC off
  classDef run fill:#cfe4fa,stroke:#3f7ba6,color:#0d2233;
  classDef sw fill:#cde8b9,stroke:#4f7a3c,color:#12210c;
  classDef off fill:#e4e4e7,stroke:#9a9aa2,color:#33333a;
  style HOST fill:#eef5fb,stroke:#8fb4cf,color:#0d2233
  style SRV fill:#f1f8ea,stroke:#8aad76,color:#12210c
  style ADMIN fill:#eeeef0,stroke:#a8a8b0,color:#33333a

• Раннер к RAS не обращается — ни ras, ни rac в списке исполнителей нет, и ни одной команды администрирования кластера он не отправляет. К базе он ходит только строкой подключения.
• Что остаётся за RAS — сеансы, соединения, лицензии, блокировка начала сеансов, регламентные задания. Это делается консолью или скриптами, где бы сервер администрирования ни стоял.
• Следствие в обе стороны — недоступный RAS командам раннера не мешает; но и то, что решается только через него — выгнать сеансы перед монопольной операцией, — раннер не сделает.

6. Кластер и веб-сервер

Кластерная база, опубликованная на Apache или IIS. Веб-сервер держит подключение к кластеру по сети; файловый доступ к базе ему не нужен.

flowchart LR
  subgraph HOST["машина раннера"]
    R["v8-runner"]
    WEBI["webinst"]
    CLI["1cv8c · клиент"]
    WS(["Apache · IIS
модуль wsap · wsisapi"])
    PUB@{ shape: doc, label: "каталог публикации
default.vrd" }
  end
  subgraph SRV["сервер 1С"]
    RAG["ragent · rmngr 1541"]
    RPH["rphost"]
  end
  BR(["браузер · тонкий клиент"])
  R -->|"процесс на операцию"| WEBI
  R -->|"процесс на запуск"| CLI
  CLI -.->|"Srvr=…;Ref=…, TCP 1541"| RAG
  WEBI -->|"-dir, -wsdir, -connstr Srvr=…;Ref=…"| PUB
  WEBI -->|"-confpath: правка конфига"| WS
  WS --> PUB
  WS -.->|"TCP 1541"| RAG
  BR -.->|"HTTP · HTTPS, ws=…"| WS
  RAG --> RPH
  class R run
  class WEBI,CLI,RAG,RPH sw
  class WS,BR svc
  class PUB art
  classDef run fill:#cfe4fa,stroke:#3f7ba6,color:#0d2233;
  classDef sw fill:#cde8b9,stroke:#4f7a3c,color:#12210c;
  classDef svc fill:#e7f3dc,stroke:#4f7a3c,color:#12210c;
  classDef art fill:#f6e8c8,stroke:#a4813a,color:#241c0c;
  style HOST fill:#eef5fb,stroke:#8fb4cf,color:#0d2233
  style SRV fill:#f1f8ea,stroke:#8aad76,color:#12210c

• Публикация — publish собирает webinst из секции infobase.web; в -connstr уходит infobase.connection как есть, то есть Srvr=…;Ref=….
• Где стоит веб-сервер — там же, где раннер. Веб-сервер, стоящий рядом с кластером, раннер опубликовать не может: webinst он запускает только у себя, и каталог публикации ищет на своей файловой системе.
• Что нужно веб-серверу — доступ к кластеру по TCP; файловый доступ к базе ему не требуется.
• Два пути у клиента — тонкий клиент идёт в кластер и напрямую по Srvr=…;Ref=…, и по веб-адресу через Apache или IIS. Оба пути запускает раннер: launch thin — по строке подключения, launch thin --via web — по infobase.web.url, launch web — тем же адресом в браузере. Умолчание здесь первое: вид цели кластерный.

7. Автономный сервер на своей машине

ibsrv поднимаете вы, раннер его не запускает и не ищет. Разговор идёт не с утилитой платформы, а с процессом сервера — через его SSH-шлюз.

flowchart LR
  subgraph BOX["одна машина"]
    subgraph HOST["раннер"]
      R["v8-runner"]
      WP@{ shape: doc, label: "workPath
всегда локален" }
    end
    subgraph SRV["автономный сервер"]
      GATE(["SSH-шлюз 1543
ibsrv --enable-ssh-gate"])
      IBSRV["ibsrv
поднят вами"]
      UD@{ shape: doc, label: "каталог пользователя шлюза
users-data и имя пользователя" }
      HTTPS(["HTTP 8314"])
      DB@{ shape: cyl, label: "база данных" }
    end
  end
  BR(["браузер · тонкий клиент"])
  R -->|"SSH: команда строкой, ответ JSON"| GATE
  R -->|"exchange: dir — ссылки и копии"| UD
  R -->|"файл"| WP
  GATE --> IBSRV
  IBSRV --> UD
  IBSRV --> DB
  IBSRV --> HTTPS
  BR -->|"HTTP"| HTTPS
  class R run
  class IBSRV sw
  class GATE,HTTPS,BR svc
  class WP,UD,DB art
  classDef run fill:#cfe4fa,stroke:#3f7ba6,color:#0d2233;
  classDef sw fill:#cde8b9,stroke:#4f7a3c,color:#12210c;
  classDef svc fill:#e7f3dc,stroke:#4f7a3c,color:#12210c;
  classDef art fill:#f6e8c8,stroke:#a4813a,color:#241c0c;
  style BOX fill:#fbfbfc,stroke:#c3c9d0,color:#4b5560
  style HOST fill:#eef5fb,stroke:#8fb4cf,color:#0d2233
  style SRV fill:#f1f8ea,stroke:#8aad76,color:#12210c

• Администрирование — infobase.standalone.gate: "localhost:1543"; infobase.connection при этом пустая, вид цели объявлен один раз.
• Как разговаривает — SSH-сессия встроенного клиента, без псевдотерминала. Первая команда переводит шлюз в машинный режим, дальше идут команды шлюза: config load-config-from-files, config dump-cfg, config update-db-cfg и прочие.
• Обмен — объявляется ключом exchange: sftp по тому же соединению или { dir: … } — каталог пользователя шлюза, видимый раннеру. На одной машине дешевле второй: файлы переносятся ссылками, мимо сети и мимо SFTP. Без объявленного канала команда отказывает на валидации, до всякой сессии.
• Исполнитель один — agent через шлюз; providers.<операция> для этой цели не нужен и не разрешён. Платформа на машине раннера не требуется.
• Клиент — HTTP самого сервера: адрес известен сразу и публикации не требует. Открывают его браузером или тонким клиентом по веб-подключению, и раннер умеет оба: launch web — браузером, launch thin — тонким клиентом. Ключ здесь не нужен: административной строки у этой цели нет, поэтому веб — умолчание. Реквизиты клиенту не передаются — infobase.user и infobase.password у этой цели принадлежат шлюзу, а не базе. test и launch thick · ordinary · designer по-прежнему отказывают типизированно: по ws-соединению ходит только тонкий клиент.

8. Автономный сервер на другой машине

Автономный сервер на отдельной машине. Раннеру не нужна ни платформа, ни доступ к чужому диску — нужен SSH до шлюза и объявленный канал файлов.

flowchart LR
  subgraph HOST["машина раннера"]
    R["v8-runner"]
    WP@{ shape: doc, label: "workPath
остаётся здесь" }
    SRC@{ shape: doc, label: "исходники и артефакты" }
  end
  subgraph SRV["другая машина"]
    GATE(["SSH-шлюз 1543"])
    IBSRV["ibsrv"]
    UD@{ shape: doc, label: "каталог пользователя шлюза
пути разрешаются здесь" }
    HTTPS(["HTTP 8314"])
  end
  DB@{ shape: cyl, label: "база данных" }
  BR(["браузер · тонкий клиент"])
  R -->|"файл"| WP
  R -->|"файл"| SRC
  R -.->|"SSH: команда строкой, ответ JSON"| GATE
  SRC -.->|"SFTP того же соединения"| UD
  GATE --> IBSRV
  IBSRV --> UD
  IBSRV --> DB
  IBSRV --> HTTPS
  BR -.->|"HTTP"| HTTPS
  class R run
  class IBSRV sw
  class GATE,HTTPS,BR svc
  class WP,SRC,UD,DB art
  classDef run fill:#cfe4fa,stroke:#3f7ba6,color:#0d2233;
  classDef sw fill:#cde8b9,stroke:#4f7a3c,color:#12210c;
  classDef svc fill:#e7f3dc,stroke:#4f7a3c,color:#12210c;
  classDef art fill:#f6e8c8,stroke:#a4813a,color:#241c0c;
  style HOST fill:#eef5fb,stroke:#8fb4cf,color:#0d2233
  style SRV fill:#f1f8ea,stroke:#8aad76,color:#12210c

• Администрирование — gate: "srv.example:1543", учётные данные берутся из infobase.user и infobase.password: шлюз пускает по пользователю базы.
• Пути — разрешаются на стороне сервера, относительно каталога пользователя шлюза. workPath остаётся локальным и внутрь exchange.dir не кладётся — валидация это проверяет.
• Канал файлов — sftp; вариант { dir: … } годится, только если этот каталог смонтирован у раннера.
• Замер 15.09.2026 — шлюз ibsrv 8.3.27 отдаёт по SFTP чтение и каталоги, а запись не принимает ни с какими флагами: dump --mode full, make и экспорт .cf работают, build и инкрементальная выгрузка отказывают типизированно, с путём и кодом шлюза.
• Своего агента раннер тут не поднимает — процесс он запускает только у себя, и управляемый агент всегда слушает 127.0.0.1. К автономному серверу он только подключается: ключи tools.designer_agent вместе с ним отвергаются валидацией.
• После update-db-cfg — сервер 15–20 секунд «обновляется» и отвергает SSH-логин; раннер ждёт шлюз до 30 секунд.

9. Кластер поднят из консоли, а не службой

Обычный приём разработки: сервер 1С запускают руками в окне терминала, чтобы служба не висела постоянно. Канал до него тот же, что у службы, — меняется владелец процесса.

flowchart LR
  subgraph BOX["одна машина"]
    subgraph HOST["раннер и утилиты"]
      R["v8-runner"]
      DES["1cv8 DESIGNER"]
      CLI["1cv8c · клиент"]
    end
    subgraph CON["ваша консоль"]
      RAG["ragent, запущенный руками
1540 · 1541"]
      RPH["rphost"]
      LOG@{ shape: doc, label: "журнал сервера
у вас перед глазами" }
    end
  end
  DBMS@{ shape: cyl, label: "СУБД" }
  R -->|"процесс на операцию"| DES
  R -->|"процесс на запуск"| CLI
  DES -->|"Srvr=localhost:1541;Ref=…"| RAG
  CLI -->|"TCP"| RAG
  RAG --> RPH
  RAG --> LOG
  RPH --> DBMS
  class R run
  class DES,CLI,RAG,RPH sw
  class DBMS art
  class LOG off
  classDef run fill:#cfe4fa,stroke:#3f7ba6,color:#0d2233;
  classDef sw fill:#cde8b9,stroke:#4f7a3c,color:#12210c;
  classDef art fill:#f6e8c8,stroke:#a4813a,color:#241c0c;
  classDef off fill:#e4e4e7,stroke:#9a9aa2,color:#33333a;
  style BOX fill:#fbfbfc,stroke:#c3c9d0,color:#4b5560
  style HOST fill:#eef5fb,stroke:#8fb4cf,color:#0d2233
  style CON fill:#f1f8ea,stroke:#8aad76,color:#12210c

• Администрирование — infobase.connection: "Srvr=localhost:1541;Ref=demo". От службы канал не отличается ничем; если ragent поднят на своём порту, он должен стоять в строке подключения.
• Кто владеет процессом — вы. Раннер кластер не поднимает, не останавливает и не перезапускает. Закрытая посреди команды консоль даёт транспортный сбой, а не отказ сценария, — и это разные коды выхода.
• Каталог данных и права — сервер работает под вашей учётной записью и кладёт базы и журналы туда, куда вы ему указали; у службы это другой пользователь и другой каталог.
• Что здесь лучше — журнал сервера виден прямо в окне. Раннер его по-прежнему не читает и в квитанции не обещает, но человеку он доступен сразу.
• Что не меняется — монопольные операции так же спорят с чужими сеансами, а сеансами раннер не управляет.

10. Кластер 1С в контейнере

Сервер 1С и СУБД подняты в контейнерах, раннер работает на хосте. Про Docker раннер не знает ничего: для него это цель на другой машине, к которой ведёт опубликованный порт.

flowchart LR
  subgraph HOST["машина раннера"]
    R["v8-runner"]
    DES["1cv8 DESIGNER"]
    CLI["1cv8c · клиент"]
    WP@{ shape: doc, label: "workPath
.cf, .dt, отчёты" }
  end
  subgraph C1["контейнер сервера 1С"]
    RAG["ragent 1540 · rmngr 1541"]
    RPH["rphost 1560–1591"]
  end
  subgraph C2["контейнер СУБД"]
    DBMS@{ shape: cyl, label: "база данных" }
  end
  R -->|"процесс на операцию"| DES
  R -->|"процесс на запуск"| CLI
  DES -.->|"опубликованные порты"| RAG
  CLI -.->|"TCP"| RAG
  DES --> WP
  RAG --> RPH
  RPH -.-> DBMS
  class R run
  class DES,CLI,RAG,RPH sw
  class WP,DBMS art
  classDef run fill:#cfe4fa,stroke:#3f7ba6,color:#0d2233;
  classDef sw fill:#cde8b9,stroke:#4f7a3c,color:#12210c;
  classDef art fill:#f6e8c8,stroke:#a4813a,color:#241c0c;
  style HOST fill:#eef5fb,stroke:#8fb4cf,color:#0d2233
  style C1 fill:#f1f8ea,stroke:#8aad76,color:#12210c
  style C2 fill:#f1f8ea,stroke:#8aad76,color:#12210c

• Администрирование — прежняя строка Srvr=…;Ref=… на опубликованный порт.
• Публиковать нужно два порта, а не один — менеджер отдаёт клиенту адрес рабочего процесса, поэтому кроме 1541 наружу должен смотреть и диапазон rphost. Иначе соединение обрывается уже после удачного коннекта к менеджеру.
• Имя должно резолвиться — кластер называет клиенту то имя, под которым видит себя сам. На хосте оно обязано указывать в контейнер: имя контейнера в hosts, общая сеть или сеть хоста.
• Платформа нужна на хосте — Конфигуратор и клиент раннер запускает у себя, контейнер их не отдаёт. Версия платформы на хосте и в контейнере должна совпадать.
• Обмен — .cf, .dt и выгрузка остаются у раннера: файловая система контейнера ему не принадлежит, как и любая чужая.

11. Автономный сервер в контейнере

Тот же ibsrv, но поднятый контейнером. Единственный вариант, где на машине раннера не нужно ни одной утилиты 1С.

flowchart LR
  subgraph HOST["машина раннера"]
    R["v8-runner"]
    WP@{ shape: doc, label: "workPath
остаётся здесь" }
  end
  subgraph C["контейнер ibsrv"]
    GATE(["SSH-шлюз 1543"])
    IBSRV["ibsrv"]
    UD@{ shape: doc, label: "каталог пользователя шлюза
смонтирован томом" }
    HTTPS(["HTTP 8314"])
    DB@{ shape: cyl, label: "база данных" }
  end
  BR(["браузер · тонкий клиент"])
  R --> WP
  R -.->|"SSH: команда строкой, ответ JSON"| GATE
  R -.->|"exchange: sftp"| UD
  R -->|"exchange: dir — если том виден раннеру"| UD
  GATE --> IBSRV
  IBSRV --> UD
  IBSRV --> DB
  IBSRV --> HTTPS
  BR -.->|"HTTP"| HTTPS
  class R run
  class IBSRV sw
  class GATE,HTTPS,BR svc
  class WP,UD,DB art
  classDef run fill:#cfe4fa,stroke:#3f7ba6,color:#0d2233;
  classDef sw fill:#cde8b9,stroke:#4f7a3c,color:#12210c;
  classDef svc fill:#e7f3dc,stroke:#4f7a3c,color:#12210c;
  classDef art fill:#f6e8c8,stroke:#a4813a,color:#241c0c;
  style HOST fill:#eef5fb,stroke:#8fb4cf,color:#0d2233
  style C fill:#f1f8ea,stroke:#8aad76,color:#12210c

• Администрирование — infobase.standalone.gate на опубликованный порт шлюза. Контейнер поднимаете вы; раннер его не запускает и о Docker не знает.
• Платформа раннеру не нужна вовсе — команды исполняет сервер внутри контейнера, раннеру хватает SSH.
• Порта два — 1543 для шлюза и 8314 для клиента: без первого не подключится раннер, без второго базу не откроют люди.
• Обмен — здесь есть выбор — sftp через шлюз или { dir: … }, если каталог пользователя шлюза смонтирован томом и виден раннеру. Второй путь снимает ограничение на запись, которое есть у SFTP-шлюза ibsrv 8.3.27.
• Клиент — HTTP контейнера, адрес известен сразу и публикации не требует.

Что доступно по виду цели

Ни местоположение цели, ни владелец её процесса — служба, консоль, контейнер — на этот список не влияют: он зависит только от вида. Первый исполнитель в клетке — умолчание; следующего реализованного раннер пробует, если первый не готов, а экспериментальные включаются только ключом providers.<операция>.

У тонкого клиента два пути, и раннер умеет оба: по строке подключения — прямо в файловую базу или кластер, по веб-адресу — через Apache, IIS или автономный сервер. Какой возьмёт launch thin без ключа, задаёт вид цели: у файловой и кластерной — строка подключения, у автономного сервера — веб, другого адреса у него нет. Ключ --via web|connection умолчание переопределяет и принимается только там, где клиент тонкий; launch web открывает тот же веб-адрес браузером. ibcmd серверную цель открывает прямо в СУБД, мимо кластера, по секции infobase.dbms; у файловой базы ему хватает пути к каталогу, а у автономного сервера секция не принимается вовсе. Какие строки помечены экспериментальными и как их включить — в разделе Эксперименты.

Каналы и протоколы

Сколько живёт

Что из этого следует

• Долгоживущее есть только у MCP-сервера: сессия EDT и HTTP-сессии. У CLI всё умирает вместе с командой.
• Сессия агента привязана к замку: пока команда владеет workPath, живёт один процесс агента, и вложенные шаги идут в нём же.
• Состояние изменений переживает процессы — оно лежит на диске под workPath.
• Параллельные команды на одном workPath не выполняются: второй ждёт замок.

Правила выбора провайдера и режимы агента — в разделе Эксперименты.