chore(i18n): refresh uk translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
c5e25fb55a
commit
7e983dc3cc
100
docs/uk/ci.md
100
docs/uk/ci.md
@ -1,89 +1,89 @@
|
||||
---
|
||||
read_when:
|
||||
- Вам потрібно зрозуміти, чому завдання CI запустилося або не запустилося
|
||||
- Вам потрібно зрозуміти, чому завдання CI було або не було запущено
|
||||
- Ви налагоджуєте збої перевірок GitHub Actions
|
||||
summary: Граф завдань CI, шлюзи області дії та локальні еквіваленти команд
|
||||
summary: Граф завдань CI, шлюзи області змін і локальні еквіваленти команд
|
||||
title: Конвеєр CI
|
||||
x-i18n:
|
||||
generated_at: "2026-04-21T02:32:23Z"
|
||||
generated_at: "2026-04-21T18:05:48Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 88a98d777fd61be1603417b71779aaf42a24d602b2437ad549f0075f22494cec
|
||||
source_hash: 4d01a178402976cdf7c3c864695e8a12d3f7d1d069a77ea1b02a8aef2a3497f7
|
||||
source_path: ci.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Конвеєр CI
|
||||
|
||||
CI запускається при кожному push у `main` і для кожного pull request. Він використовує розумне визначення області, щоб пропускати дорогі завдання, коли змінено лише не пов’язані частини.
|
||||
CI запускається для кожного push у `main` і для кожного pull request. Він використовує розумне визначення області змін, щоб пропускати дорогі завдання, коли змінено лише нерелевантні частини.
|
||||
|
||||
## Огляд завдань
|
||||
|
||||
| Завдання | Призначення | Коли запускається |
|
||||
| -------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------- |
|
||||
| `preflight` | Визначає зміни лише в документації, змінені області, змінені extensions і будує маніфест CI | Завжди для push і PR без чернетки |
|
||||
| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для push і PR без чернетки |
|
||||
| `security-dependency-audit` | Аудит production lockfile без залежностей щодо рекомендацій npm | Завжди для push і PR без чернетки |
|
||||
| `security-fast` | Обов’язковий агрегований результат для швидких завдань безпеки | Завжди для push і PR без чернетки |
|
||||
| `build-artifacts` | Один раз збирає `dist/` і Control UI, завантажує повторно використовувані артефакти для залежних завдань | Зміни, релевантні для Node |
|
||||
| `checks-fast-core` | Швидкі Linux-лінії коректності, як-от bundled/plugin-contract/protocol перевірки | Зміни, релевантні для Node |
|
||||
| `checks-fast-contracts-channels` | Розшардовані перевірки контрактів каналів зі стабільним агрегованим результатом перевірки | Зміни, релевантні для Node |
|
||||
| `checks-node-extensions` | Повні шардовані тести bundled-plugin для всього набору extensions | Зміни, релевантні для Node |
|
||||
| `checks-node-core-test` | Шардовані тести core Node, без ліній каналів, bundled, контрактів і extensions | Зміни, релевантні для Node |
|
||||
| `extension-fast` | Цільові тести лише для змінених bundled plugins | Коли виявлено зміни extensions |
|
||||
| `check` | Розшардований еквівалент основного локального шлюзу: production types, lint, guards, test types і strict smoke | Зміни, релевантні для Node |
|
||||
| `check-additional` | Шарди архітектури, меж, guard-перевірок extension-surface, package-boundary і gateway-watch | Зміни, релевантні для Node |
|
||||
| `build-smoke` | Smoke-тести зібраного CLI і smoke-тест пам’яті під час запуску | Зміни, релевантні для Node |
|
||||
| `checks` | Решта Linux Node-ліній: тести каналів і лише для push сумісність Node 22 | Зміни, релевантні для Node |
|
||||
| `check-docs` | Форматування документації, lint і перевірки битих посилань | Документацію змінено |
|
||||
| `skills-python` | Ruff + pytest для Skills на Python | Зміни, релевантні для Python Skills |
|
||||
| `checks-windows` | Специфічні для Windows тестові лінії | Зміни, релевантні для Windows |
|
||||
| `macos-node` | Лінія тестів TypeScript на macOS з використанням спільних зібраних артефактів | Зміни, релевантні для macOS |
|
||||
| `macos-swift` | Лінтинг, збірка і тести Swift для застосунку macOS | Зміни, релевантні для macOS |
|
||||
| `android` | Матриця збірки й тестів Android | Зміни, релевантні для Android |
|
||||
| Завдання | Призначення | Коли запускається |
|
||||
| -------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------- |
|
||||
| `preflight` | Виявляє зміни лише в документації, області змін, змінені розширення та будує маніфест CI | Завжди для push і PR не в чернетці |
|
||||
| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для push і PR не в чернетці |
|
||||
| `security-dependency-audit` | Аудит production lockfile без залежностей на основі advisories npm | Завжди для push і PR не в чернетці |
|
||||
| `security-fast` | Обов’язковий агрегат для швидких завдань безпеки | Завжди для push і PR не в чернетці |
|
||||
| `build-artifacts` | Один раз збирає `dist/` і Control UI, завантажує повторно використовувані артефакти для downstream-завдань | Зміни, релевантні для Node |
|
||||
| `checks-fast-core` | Швидкі Linux-етапи перевірки коректності, як-от bundled/plugin-contract/protocol checks | Зміни, релевантні для Node |
|
||||
| `checks-fast-contracts-channels` | Розшардовані перевірки контрактів каналів зі стабільним агрегованим результатом | Зміни, релевантні для Node |
|
||||
| `checks-node-extensions` | Повні шарди тестів bundled-plugin для всього набору розширень | Зміни, релевантні для Node |
|
||||
| `checks-node-core-test` | Шарди тестів core Node, за винятком каналів, bundled, контрактних і extension-етапів | Зміни, релевантні для Node |
|
||||
| `extension-fast` | Цільові тести лише для змінених bundled plugins | Коли виявлено зміни в розширеннях |
|
||||
| `check` | Розшардований еквівалент основного локального шлюзу: production types, lint, guards, test types і strict smoke | Зміни, релевантні для Node |
|
||||
| `check-additional` | Шарди архітектурних, boundary, extension-surface guards, package-boundary і gateway-watch перевірок | Зміни, релевантні для Node |
|
||||
| `build-smoke` | Smoke-тести зібраного CLI і smoke-перевірка пам’яті під час запуску | Зміни, релевантні для Node |
|
||||
| `checks` | Решта Linux Node-етапів: тести каналів і сумісність Node 22 лише для push | Зміни, релевантні для Node |
|
||||
| `check-docs` | Форматування документації, lint і перевірка на биті посилання | Документацію змінено |
|
||||
| `skills-python` | Ruff + pytest для Skills на базі Python | Зміни, релевантні для Python Skills |
|
||||
| `checks-windows` | Windows-специфічні тестові етапи | Зміни, релевантні для Windows |
|
||||
| `macos-node` | Етап тестів TypeScript на macOS із використанням спільних зібраних артефактів | Зміни, релевантні для macOS |
|
||||
| `macos-swift` | Swift lint, build і тести для застосунку macOS | Зміни, релевантні для macOS |
|
||||
| `android` | Матриця збірки та тестів Android | Зміни, релевантні для Android |
|
||||
|
||||
## Порядок fail-fast
|
||||
## Порядок Fail-Fast
|
||||
|
||||
Завдання впорядковано так, щоб дешеві перевірки завершувалися з помилкою раніше, ніж запустяться дорогі:
|
||||
Завдання впорядковано так, щоб дешеві перевірки завершувалися з помилкою раніше, ніж запускаються дорогі:
|
||||
|
||||
1. `preflight` вирішує, які лінії взагалі існують. Логіка `docs-scope` і `changed-scope` — це кроки всередині цього завдання, а не окремі завдання.
|
||||
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко завершуються з помилкою без очікування важчих завдань зі створення артефактів і платформних матриць.
|
||||
3. `build-artifacts` виконується паралельно зі швидкими Linux-лініями, щоб залежні споживачі могли стартувати, щойно спільна збірка буде готова.
|
||||
4. Після цього розгалужуються важчі платформні й runtime-лінії: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
|
||||
1. `preflight` вирішує, які етапи взагалі існують. Логіка `docs-scope` і `changed-scope` — це кроки всередині цього завдання, а не окремі завдання.
|
||||
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` завершуються швидко, не чекаючи важчих матричних завдань артефактів і платформ.
|
||||
3. `build-artifacts` виконується паралельно зі швидкими Linux-етапами, щоб downstream-споживачі могли почати роботу, щойно спільна збірка буде готова.
|
||||
4. Після цього розгалужуються важчі платформні та runtime-етапи: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
|
||||
|
||||
Логіка області дії міститься в `scripts/ci-changed-scope.mjs` і покривається unit-тестами в `src/scripts/ci-changed-scope.test.ts`.
|
||||
Окремий workflow `install-smoke` повторно використовує той самий скрипт області дії через власне завдання `preflight`. Він обчислює `run_install_smoke` на основі вужчого сигналу changed-smoke, тому Docker/install smoke запускається лише для змін, пов’язаних з install, packaging і контейнерами.
|
||||
Логіка області змін розміщена в `scripts/ci-changed-scope.mjs` і покрита unit-тестами в `src/scripts/ci-changed-scope.test.ts`.
|
||||
Окремий workflow `install-smoke` повторно використовує той самий скрипт області змін через власне завдання `preflight`. Він обчислює `run_install_smoke` із вужчого сигналу changed-smoke, тому Docker/install smoke запускається лише для змін, релевантних до встановлення, пакування та контейнерів.
|
||||
|
||||
Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний шлюз суворіший щодо архітектурних меж, ніж широка платформна область CI: зміни в core production запускають typecheck core prod плюс тести core, зміни лише в core tests запускають лише typecheck/tests для core tests, зміни в extension production запускають typecheck extension prod плюс тести extensions, а зміни лише в extension tests запускають лише typecheck/tests для extension tests. Зміни в публічному Plugin SDK або plugin-contract розширюють перевірку на extensions, оскільки extensions залежать від цих контрактів core. Невідомі зміни в root/config безпечно розширюються до всіх ліній.
|
||||
Логіка локальних changed-lanes розміщена в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний шлюз суворіший щодо архітектурних меж, ніж широка область платформ у CI: зміни core production запускають typecheck core prod плюс тести core, зміни лише в core tests запускають лише typecheck/tests для core tests, зміни extension production запускають typecheck extension prod плюс тести розширень, а зміни лише в extension tests запускають лише typecheck/tests для extension tests. Зміни в public Plugin SDK або plugin-contract розширюють перевірку до validation розширень, тому що розширення залежать від цих core-контрактів. Невідомі зміни в корені/config безпечно переводять виконання на всі етапи.
|
||||
|
||||
Для push матриця `checks` додає лінію `compat-node22`, яка запускається лише для push. Для pull request цю лінію пропускають, і матриця зосереджується на звичайних тестових/channel-лініях.
|
||||
Для push матриця `checks` додає етап `compat-node22`, який запускається лише для push. Для pull request цей етап пропускається, і матриця залишається зосередженою на звичайних test/channel-етапах.
|
||||
|
||||
Найповільніші сімейства тестів Node розділено на include-file шарди, щоб кожне завдання залишалося невеликим: channel contracts розділяють покриття registry і core на вісім зважених шардів кожне, тести команд відповіді auto-reply розділяються на чотири шарди за include-pattern, а інші великі групи префіксів відповідей auto-reply — на два шарди кожна. `check-additional` також відокремлює роботу package-boundary compile/canary від runtime topology gateway/architecture.
|
||||
Найповільніші сімейства тестів Node розбиті на include-file шарди, щоб кожне завдання залишалося невеликим: channel contracts розділяють покриття registry і core на вісім зважених шардів кожне, тести auto-reply reply command поділено на чотири шарди за include-pattern, а інші великі групи auto-reply reply prefix — на два шарди кожна. `check-additional` також відокремлює compile/canary-роботи package-boundary від runtime topology gateway/architecture-робіт.
|
||||
|
||||
GitHub може позначати замінені новішими завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це шумом CI, якщо лише найновіший запуск для того самого ref також не завершується з помилкою. Агреговані шардовані перевірки явно вказують на цей випадок скасування, щоб його було легше відрізнити від збою тесту.
|
||||
GitHub може позначати замінені новішими завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Сприймайте це як шум CI, якщо лише найновіший запуск для того самого ref також не завершується з помилкою. Агреговані shard-перевірки явно вказують на цей випадок скасування, щоб його було легше відрізнити від помилки тесту.
|
||||
|
||||
## Runners
|
||||
|
||||
| Runner | Завдання |
|
||||
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `blacksmith-16vcpu-ubuntu-2404` | `preflight`, `security-scm-fast`, `security-dependency-audit`, `security-fast`, `build-artifacts`, Linux-перевірки, перевірки документації, Python Skills, `android` |
|
||||
| `blacksmith-32vcpu-windows-2025` | `checks-windows` |
|
||||
| `macos-latest` | `macos-node`, `macos-swift` |
|
||||
| Runner | Завдання |
|
||||
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `blacksmith-16vcpu-ubuntu-2404` | `preflight`, `security-scm-fast`, `security-dependency-audit`, `security-fast`, `build-artifacts`, Linux checks, docs checks, Python Skills, `android` |
|
||||
| `blacksmith-32vcpu-windows-2025` | `checks-windows` |
|
||||
| `blacksmith-12vcpu-macos-latest` | `macos-node`, `macos-swift` у `openclaw/openclaw`; для forks використовується fallback на `macos-latest` |
|
||||
|
||||
## Локальні еквіваленти
|
||||
|
||||
```bash
|
||||
pnpm changed:lanes # переглянути локальний класифікатор changed-lane для origin/main...HEAD
|
||||
pnpm check:changed # розумний локальний шлюз: changed typecheck/lint/tests за граничною лінією
|
||||
pnpm check # швидкий локальний шлюз: production tsgo + шардований lint + паралельні швидкі guards
|
||||
pnpm changed:lanes # переглянути локальний класифікатор changed-lanes для origin/main...HEAD
|
||||
pnpm check:changed # розумний локальний шлюз: змінені typecheck/lint/tests за boundary-етапом
|
||||
pnpm check # швидкий локальний шлюз: production tsgo + розшардований lint + паралельні швидкі guards
|
||||
pnpm check:test-types
|
||||
pnpm check:timed # той самий шлюз із таймінгами для кожного етапу
|
||||
pnpm check:timed # той самий шлюз із вимірюванням часу для кожного етапу
|
||||
pnpm build:strict-smoke
|
||||
pnpm check:architecture
|
||||
pnpm test:gateway:watch-regression
|
||||
pnpm test # тести vitest
|
||||
pnpm test:channels
|
||||
pnpm test:contracts:channels
|
||||
pnpm check:docs # форматування документації + lint + перевірка битих посилань
|
||||
pnpm build # зібрати dist, коли важливі лінії CI artifact/build-smoke
|
||||
pnpm check:docs # форматування docs + lint + перевірка битих посилань
|
||||
pnpm build # збірка dist, коли важливі етапи CI artifact/build-smoke
|
||||
```
|
||||
|
||||
@ -1,136 +1,116 @@
|
||||
---
|
||||
read_when:
|
||||
- Запуск більш ніж одного Gateway на одній машині
|
||||
- Для кожного Gateway потрібні ізольовані конфігурація/стан/порти
|
||||
summary: Запуск кількох Gateway OpenClaw на одному хості (ізоляція, порти та профілі)
|
||||
- Запуск кількох Gateway на одній машині
|
||||
- Для кожного Gateway потрібні ізольовані конфігурація, стан і порти
|
||||
summary: Запускайте кілька Gateway OpenClaw на одному хості (ізоляція, порти та профілі)
|
||||
title: Кілька Gateway
|
||||
x-i18n:
|
||||
generated_at: "2026-04-21T17:32:11Z"
|
||||
generated_at: "2026-04-21T18:05:47Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 8c3fcb921bc6596040e9249467964bd9dcd40ea7c16e958bb378247b0f994a7b
|
||||
source_hash: 7a0bae1fbb088d1c1b7a90bb1de8f33471a19c5fbeafd8e2a0556d8eeadf8c15
|
||||
source_path: gateway/multiple-gateways.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Кілька Gateway (один хост)
|
||||
# Кілька Gateway (на одному хості)
|
||||
|
||||
У більшості конфігурацій слід використовувати один Gateway, оскільки один Gateway може обробляти кілька підключень месенджерів і агентів. Якщо вам потрібна сильніша ізоляція або резервування (наприклад, аварійний бот), запускайте окремі Gateway з ізольованими профілями/портами.
|
||||
У більшості конфігурацій слід використовувати один Gateway, оскільки один Gateway може обробляти кілька підключень до месенджерів і агентів. Якщо вам потрібна сильніша ізоляція або резервування (наприклад, rescue bot), запускайте окремі Gateway з ізольованими профілями/портами.
|
||||
|
||||
## Контрольний список ізоляції (обов’язково)
|
||||
## Найкраща рекомендована конфігурація
|
||||
|
||||
- `OPENCLAW_CONFIG_PATH` — окремий файл конфігурації для кожного екземпляра
|
||||
- `OPENCLAW_STATE_DIR` — окремі сесії, облікові дані, кеші для кожного екземпляра
|
||||
- `agents.defaults.workspace` — окремий корінь робочого простору для кожного екземпляра
|
||||
- `gateway.port` (або `--port`) — унікальний для кожного екземпляра
|
||||
- Похідні порти (browser/canvas) не повинні перетинатися
|
||||
Для більшості користувачів найпростіша конфігурація rescue bot така:
|
||||
|
||||
Якщо вони спільні, ви зіткнетеся з конфліктами конфігурації та портів.
|
||||
- залиште основний bot на профілі за замовчуванням
|
||||
- запустіть rescue bot з `--profile rescue`
|
||||
- використовуйте повністю окремий Telegram bot для облікового запису rescue
|
||||
- тримайте rescue bot на іншому базовому порту, наприклад `19789`
|
||||
|
||||
## Рекомендовано: використовуйте типовий профіль для основного, іменований профіль — для аварійного
|
||||
Це зберігає ізоляцію rescue bot від основного bot, тож він може налагоджувати або застосовувати зміни конфігурації, якщо основний bot недоступний. Залишайте щонайменше 20 портів між базовими портами, щоб похідні порти browser/canvas/CDP ніколи не конфліктували.
|
||||
|
||||
Профілі автоматично ізолюють `OPENCLAW_STATE_DIR` + `OPENCLAW_CONFIG_PATH` і додають суфікси до назв сервісів. Для більшості конфігурацій з аварійним ботом залиште основного бота на типовому профілі, а аварійному боту призначте іменований профіль, наприклад `rescue`.
|
||||
## Швидкий старт для rescue bot
|
||||
|
||||
Використовуйте це як типовий шлях, якщо у вас немає вагомої причини робити інакше:
|
||||
|
||||
```bash
|
||||
# main (default profile)
|
||||
openclaw setup
|
||||
openclaw gateway --port 18789
|
||||
|
||||
# rescue
|
||||
openclaw --profile rescue setup
|
||||
openclaw --profile rescue gateway --port 19001
|
||||
```
|
||||
|
||||
Сервіси:
|
||||
|
||||
```bash
|
||||
openclaw gateway install
|
||||
openclaw --profile rescue gateway install
|
||||
```
|
||||
|
||||
Якщо ви хочете, щоб обидва Gateway використовували іменовані профілі, це теж працює, але не є обов’язковим.
|
||||
|
||||
## Посібник для аварійного бота
|
||||
|
||||
Рекомендована конфігурація:
|
||||
|
||||
- залиште основного бота на типовому профілі
|
||||
- запускайте аварійного бота з `--profile rescue`
|
||||
- використовуйте повністю окремого Telegram-бота для аварійного облікового запису
|
||||
- тримайте аварійного бота на іншому базовому порту, наприклад `19001`
|
||||
|
||||
Це ізолює аварійного бота від основного, щоб він міг налагоджувати або застосовувати зміни конфігурації, якщо основний бот недоступний. Залишайте щонайменше 20 портів між базовими портами, щоб похідні порти browser/canvas/CDP ніколи не конфліктували.
|
||||
|
||||
### Рекомендований канал/обліковий запис для аварійного доступу
|
||||
|
||||
Для більшості конфігурацій використовуйте повністю окремого Telegram-бота для профілю аварійного доступу.
|
||||
|
||||
Чому Telegram:
|
||||
|
||||
- легко обмежити доступ лише для операторів
|
||||
- окремий токен і ідентичність бота
|
||||
- незалежність від каналу/встановлення застосунку основного бота
|
||||
- простий шлях відновлення через DM, коли основний бот зламаний
|
||||
|
||||
Важлива саме повна незалежність: окремий обліковий запис бота, окремі
|
||||
облікові дані, окремий профіль OpenClaw, окремий робочий простір і окремий порт.
|
||||
|
||||
### Рекомендований процес встановлення
|
||||
|
||||
Використовуйте це як типову конфігурацію, якщо у вас немає вагомої причини робити інакше:
|
||||
|
||||
```bash
|
||||
# Main bot (default profile, port 18789)
|
||||
openclaw onboard
|
||||
openclaw gateway install
|
||||
|
||||
# Rescue bot (separate Telegram bot, separate profile, port 19001)
|
||||
# Rescue bot (окремий Telegram bot, окремий профіль, порт 19789)
|
||||
openclaw --profile rescue onboard
|
||||
openclaw --profile rescue gateway install
|
||||
openclaw --profile rescue gateway install --port 19789
|
||||
```
|
||||
|
||||
Якщо ваш основний bot уже працює, зазвичай цього достатньо.
|
||||
|
||||
Під час `openclaw --profile rescue onboard`:
|
||||
|
||||
- використовуйте окремий токен Telegram-бота
|
||||
- залишайте профіль `rescue`
|
||||
- використовуйте базовий порт щонайменше на 20 вищий за порт основного бота
|
||||
- прийміть типовий робочий простір аварійного бота, якщо ви вже не керуєте власним
|
||||
- використовуйте окремий токен Telegram bot
|
||||
- залиште профіль `rescue`
|
||||
- використовуйте базовий порт щонайменше на 20 вищий, ніж у основного bot
|
||||
- прийміть робочий простір rescue за замовчуванням, якщо ви вже не керуєте власним
|
||||
|
||||
Якщо онбординг уже встановив для вас аварійний сервіс, фінальний
|
||||
Якщо onboarding уже встановив для вас службу rescue, фінальний
|
||||
`gateway install` не потрібен.
|
||||
|
||||
### Що змінює онбординг
|
||||
## Чому це працює
|
||||
|
||||
`openclaw --profile rescue onboard` використовує звичайний процес онбордингу, але
|
||||
Rescue bot залишається незалежним, оскільки має власні:
|
||||
|
||||
- профіль/конфігурацію
|
||||
- каталог стану
|
||||
- робочий простір
|
||||
- базовий порт (і похідні порти)
|
||||
- токен Telegram bot
|
||||
|
||||
Для більшості конфігурацій використовуйте повністю окремий Telegram bot для профілю rescue:
|
||||
|
||||
- його легко залишити лише для операторів
|
||||
- окремий токен bot і окрема ідентичність
|
||||
- незалежність від установлення каналу/застосунку основного bot
|
||||
- простий шлях відновлення через DM, коли основний bot зламаний
|
||||
|
||||
## Що змінює `--profile rescue onboard`
|
||||
|
||||
`openclaw --profile rescue onboard` використовує звичайний процес onboarding, але
|
||||
записує все в окремий профіль.
|
||||
|
||||
На практиці це означає, що аварійний бот отримує власні:
|
||||
На практиці це означає, що rescue bot отримує власні:
|
||||
|
||||
- файл конфігурації
|
||||
- каталог стану
|
||||
- робочий простір (типово `~/.openclaw/workspace-rescue`)
|
||||
- ім’я керованого сервісу
|
||||
- ім’я керованої служби
|
||||
|
||||
В іншому запити такі самі, як і під час звичайного онбордингу.
|
||||
В іншому запити такі самі, як і під час звичайного onboarding.
|
||||
|
||||
## Контрольний список ізоляції
|
||||
|
||||
Зберігайте унікальність цих параметрів для кожного екземпляра Gateway:
|
||||
|
||||
- `OPENCLAW_CONFIG_PATH` — окремий файл конфігурації для кожного екземпляра
|
||||
- `OPENCLAW_STATE_DIR` — окремі сеанси, облікові дані, кеші для кожного екземпляра
|
||||
- `agents.defaults.workspace` — окремий корінь робочого простору для кожного екземпляра
|
||||
- `gateway.port` (або `--port`) — унікальний для кожного екземпляра
|
||||
- похідні порти browser/canvas/CDP
|
||||
|
||||
Якщо вони спільні, ви зіткнетеся з гонками конфігурації та конфліктами портів.
|
||||
|
||||
## Відображення портів (похідні)
|
||||
|
||||
Базовий порт = `gateway.port` (або `OPENCLAW_GATEWAY_PORT` / `--port`).
|
||||
|
||||
- порт сервісу керування browser = базовий + 2 (лише loopback)
|
||||
- порт служби керування browser = базовий + 2 (лише local loopback)
|
||||
- canvas host обслуговується на HTTP-сервері Gateway (той самий порт, що й `gateway.port`)
|
||||
- порти CDP профілю Browser автоматично виділяються з діапазону `browser.controlPort + 9 .. + 108`
|
||||
- порти CDP профілю browser автоматично виділяються з діапазону `browser.controlPort + 9 .. + 108`
|
||||
|
||||
Якщо ви перевизначаєте будь-який із них у конфігурації або env, ви повинні зберігати їх унікальними для кожного екземпляра.
|
||||
Якщо ви перевизначаєте будь-що з цього в конфігурації або env, ви повинні зберегти унікальність для кожного екземпляра.
|
||||
|
||||
## Нотатки щодо Browser/CDP (поширена пастка)
|
||||
## Нотатки про browser/CDP (типова пастка)
|
||||
|
||||
- **Не** фіксуйте `browser.cdpUrl` на однакові значення для кількох екземплярів.
|
||||
- **Не** фіксуйте `browser.cdpUrl` на однакові значення в кількох екземплярах.
|
||||
- Кожному екземпляру потрібен власний порт керування browser і власний діапазон CDP (похідний від його порту gateway).
|
||||
- Якщо вам потрібні явні порти CDP, задайте `browser.profiles.<name>.cdpPort` для кожного екземпляра.
|
||||
- Якщо вам потрібні явні порти CDP, задавайте `browser.profiles.<name>.cdpPort` для кожного екземпляра.
|
||||
- Віддалений Chrome: використовуйте `browser.profiles.<name>.cdpUrl` (для кожного профілю, для кожного екземпляра).
|
||||
|
||||
## Приклад ручного env
|
||||
## Приклад manual env
|
||||
|
||||
```bash
|
||||
OPENCLAW_CONFIG_PATH=~/.openclaw/main.json \
|
||||
@ -139,7 +119,7 @@ openclaw gateway --port 18789
|
||||
|
||||
OPENCLAW_CONFIG_PATH=~/.openclaw/rescue.json \
|
||||
OPENCLAW_STATE_DIR=~/.openclaw-rescue \
|
||||
openclaw gateway --port 19001
|
||||
openclaw gateway --port 19789
|
||||
```
|
||||
|
||||
## Швидкі перевірки
|
||||
@ -155,5 +135,5 @@ openclaw --profile rescue browser status
|
||||
|
||||
Тлумачення:
|
||||
|
||||
- `gateway status --deep` допомагає виявити застарілі сервіси launchd/systemd/schtasks зі старіших встановлень.
|
||||
- Попереджувальний текст `gateway probe`, наприклад `multiple reachable gateways detected`, очікуваний лише тоді, коли ви навмисно запускаєте більше ніж один ізольований gateway.
|
||||
- `gateway status --deep` допомагає виявити застарілі служби launchd/systemd/schtasks від старіших установлень.
|
||||
- Попереджувальний текст `gateway probe`, наприклад `multiple reachable gateways detected`, є очікуваним лише тоді, коли ви навмисно запускаєте більше ніж один ізольований gateway.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user