Перейти до основного вмісту

​
openclaw fleet

openclaw fleet керує повноцінними екземплярами OpenClaw, які називаються комірками. Кожна комірка має власні Gateway, стан, облікові дані, облікові записи каналів, контейнер і доступний лише через loopback порт хоста. Використовуйте окрему комірку для кожної межі довіри орендаря; не використовуйте один спільний Gateway як межу між недовіреними орендарями. Fleet є експериментальною функцією. Назви команд, прапорці, формати виводу та профіль контейнера можуть змінюватися між випусками без періоду застарівання. Fleet підтримує Docker і Podman. Типовий образ — ghcr.io/openclaw/openclaw:latest. Fleet протестовано на хостах Linux і macOS. Хости Windows наразі не протестовано.

​
Швидкий початок

fleet create одноразово виводить згенерований токен Gateway разом з URL-адресою комірки. Негайно збережіть токен, а потім налаштуйте облікові записи каналів кожного орендаря в комірці цього орендаря.

​
Ідентифікатори орендарів

Ідентифікатори орендарів мають відповідати:
Дозволено від 1 до 40 малих літер, цифр і внутрішніх дефісів. Ідентифікатор має починатися й закінчуватися літерою або цифрою. Великі літери, символи підкреслення, скісні риски, крапки, пробільні символи та рядки обходу шляхів, як-от ../acme, відхиляються. Ідентифікатор стає частиною назви контейнера: openclaw-cell-<tenant>.

​
fleet create

Створіть комірку та запустіть її:
Створіть комірку Podman із фіксованим портом без її запуску:
Передавайте змінні середовища для конкретного орендаря, повторюючи --env:
Ключі середовища можуть містити літери, цифри та символи підкреслення й не можуть починатися із цифри. Значення мають бути однорядковими, оскільки Fleet передає їх через захищений файл середовища виконання. Fleet відхиляє спроби перевизначити керовані змінні шляхів контейнера й токена Gateway, перелічені в розділі Сховище та структура контейнера.

​
Параметри створення

Під час автоматичного виділення вибирається перший невикористаний порт реєстру, що дорівнює або перевищує 19100. Fleet відхиляє дублікати ідентифікаторів орендарів і явно задані порти, уже призначені іншій комірці. Посилання на образ передається як один аргумент середовища виконання контейнерів. Порожні посилання та значення, що починаються з -, відхиляються, щоб образ не можна було інтерпретувати як параметр Docker або Podman. Вибрана кінцева точка Docker або Podman має бути локальною. Fleet відхиляє віддалені контексти Docker, кінцеві точки DOCKER_HOST і віддалені служби Podman до резервування порту або створення локального стану. Віддалені хости комірок не підтримуються. Коли Fleet запускає нову комірку, команда створення очікує приблизно до хвилини, доки її Gateway відповість на /healthz. Якщо комірка не переходить у справний стан, Fleet залишає її контейнер і рядок реєстру недоторканими для fleet status, fleet logs або явного видалення. --no-start пропускає цю перевірку справності. Згенерований токен Gateway несправної нової комірки не втрачається — він залишається в середовищі контейнера (docker|podman inspect), а оскільки комірка ще не обслуговувала трафік, fleet rm --force із подальшим повторним створенням завжди є безпечною альтернативою.

​
Закріплення за дайджестом

Команди створення й оновлення приймають посилання на образи, закріплені за дайджестом, як-от --image ghcr.io/openclaw/openclaw@sha256:<digest>. Fleet дослівно передає посилання на образ до Docker або Podman, що дає оператору змогу утримувати комірку на незмінних байтах образу замість рухомого тегу. Результат створення містить ідентифікатор орендаря, назву контейнера, порт хоста, токен Gateway і локальну URL-адресу. Навіть у виводі JSON вважайте результат таким, що містить секретні дані, оскільки він містить токен.

​
Обмеження диска

--disk обмежує лише доступний для запису шар контейнера. Підключені через bind mount каталоги стану й автентифікації кожного орендаря залишаються сховищем хоста; якщо для цих каталогів також потрібне жорстке обмеження, використовуйте проєктні квоти файлової системи хоста.

​
Політика вихідного трафіку

Для Docker зберігайте режим мосту та застосовуйте політику вихідного трафіку за допомогою правил брандмауера хоста, як-от ланцюжок DOCKER-USER.

​
fleet list

Виведіть список комірок у порядку ідентифікаторів орендарів:
Таблиця містить: Рядки реєстру залишаються видимими, коли Docker або Podman недоступні; лише поточний стан змінюється на unknown.

​
fleet status

Перевірте одну комірку:
Статус поєднує рядок реєстру Fleet, поточну перевірку контейнера та короткий запит із докладанням усіх можливих зусиль до:
Результат перевірки справності — ok, failed або skipped. /healthz підтверджує працездатність Gateway, а не повну готовність кожного налаштованого каналу чи плагіна. Перевірка пропускається, якщо немає придатної локальної кінцевої точки.

​
fleet logs

Передавайте потік журналів контейнера комірки безпосередньо до термінала:
Перед читанням журналів Fleet перевіряє мітки належності зареєстрованого контейнера, тому відмовляється працювати зі стороннім контейнером, який використовує очікувану назву комірки. Потік закріплюється за ідентифікатором перевіреного контейнера, тому паралельна заміна не може перенаправити його до новішого покоління. Натисніть Ctrl-C, щоб завершити --follow, не вважаючи зупинку оператором помилкою команди. Вивід журналу проходить через фільтр редагування, який замінює поточний токен Gateway комірки на <redacted>, перш ніж будь-які дані потраплять до термінала. fleet logs не має режиму --json, оскільки журнали контейнера є необробленим потоком stdout/stderr. У сценаріях обмежуйте вивід за допомогою --tail і використовуйте звичайне перенаправлення оболонки або конвеєри.

​
fleet start, fleet stop та fleet restart

Керуйте наявною коміркою за допомогою записаного для неї середовища виконання:
Ці команди працюють із зареєстрованою назвою контейнера. Вони завершуються помилкою, якщо орендар невідомий або записане середовище виконання не може виконати операцію.

​
fleet upgrade

Повторно завантажте записаний образ і замініть контейнер комірки:
Перенесіть комірку на інший образ:
Під час оновлення Fleet завантажує цільовий образ, перевіряє наявний контейнер і мережу окремої комірки, зупиняє та видаляє контейнер, а потім повторно створює і запускає його. Замінений контейнер зберігає той самий порт хоста, каталоги даних, мостову мережу окремої комірки, профіль середовища виконання, обмеження ресурсів, політику перезапуску, кероване Fleet середовище та значення, початково передані через --env. Змонтований стан зберігається після заміни контейнера; стандартне середовище образу може змінитися відповідно до цільового образу. Заміна фіксується лише після того, як її Gateway відповість на /healthz через loopback-порт комірки відповідно до контракту перевірки працездатності, який використовує офіційний файл Compose. Замінений контейнер, який завершує роботу, циклічно аварійно перезапускається або не стає працездатним приблизно протягом хвилини, видаляється, а попередній контейнер відновлюється, тому несправний образ не виведе з ладу робочу комірку. Токен Gateway навмисно не зберігається в реєстрі Fleet. Перед видаленням старого контейнера Fleet зчитує його середовище й переносить OPENCLAW_GATEWAY_TOKEN до заміненого контейнера. Не видаляйте старий контейнер вручну перед оновленням, якщо токен більше ніде під вашим контролем не зберігається.

​
fleet backup та fleet restore

Створіть резервну копію однієї зупиненої комірки:
Відновіть цей архів у зареєстрованій комірці:
Ці команди потребують привілеїв оператора хоста. Архіви містять стан орендаря та секрети автентифікації, створюються з режимом 0600 і мають зберігатися як облікові дані. Резервне копіювання відмовляється працювати із запущеною коміркою, щоб стан SQLite було збережено узгоджено. Відновлення відмовляється працювати із запущеною коміркою, якщо не передано --force, замінює лише стан цього орендаря, змінює токен Gateway і одноразово виводить новий токен. Fleet створює резервну копію одного орендаря за раз; резервне копіювання всіх орендарів є окремою дією оператора. Для відновлення потрібен наявний зупинений контейнер, оскільки його перевірений профіль середовища виконання надає обмеження, зіставлення користувача, походження середовища та образ для заміни. Якщо зареєстрований контейнер було видалено поза Fleet, спочатку виконайте fleet rm <tenant> --force без --purge-data, повторно створіть комірку з потрібним образом і --no-start, а потім повторіть відновлення. Перше видалення збереже обидва каталоги даних орендаря. Обидві команди приймають --max-bytes <bytes> для обмеження обсягу архівованих або видобутих файлових даних і застосовують однаковий фіксований ліміт у мільйон сегментів шляхів архіву, щоб архівні бомби, які містять лише метадані, не могли вичерпати inode хоста, а кожна прийнята резервна копія залишалася придатною до відновлення. Команда резервного копіювання приймає --out <path>, а обидві команди підтримують --json. Архіви містять лише звичайні файли й каталоги. Резервне копіювання ніколи не переходить за символічними посиланнями й не зберігає символічні та жорсткі посилання, сокети або вузли пристроїв; кількість пропущених об’єктів зазначається в результаті. Відновлення відхиляє архіви, що містять записи будь-якого іншого типу. Відтворювані дерева символічних посилань, як-от node_modules робочого простору, потрібно повторно встановити всередині комірки після відновлення.

​
fleet doctor

Перевірте всі комірки або одного орендаря без зміни стану середовища виконання чи файлової системи:
Doctor перевіряє локальність середовища виконання, мітки власності, працездатність, захисні налаштування, обмеження ресурсів, прив’язку loopback-порту, наявність токена, власність мережі та режим вихідного трафіку, а також дозволи приватних каталогів стану. Попередження описують зупинені комірки або відмінності у власності; будь-яка невдала перевірка встановлює ненульовий код завершення процесу.

​
fleet rm

Видаліть зупинену комірку із середовища виконання та реєстру, зберігши дані орендаря:
Для запущеного контейнера потрібен --force:
Також остаточно видаліть дані комірки:
Fleet видаляє контейнер комірки перед видаленням її виділеної мостової мережі. --purge-data потребує --force. Перед рекурсивним видаленням Fleet визначає обидва кореневі каталоги, що належать Fleet, і обидва каталоги окремого орендаря. Кожна ціль має бути саме очікуваним кінцевим каталогом орендаря, розташованим строго всередині свого кореневого каталогу, і не бути символічним посиланням. Ці перевірки меж запобігають перенаправленню видалення в інше місце через пошкоджений шлях реєстру або міжорендарське символічне посилання. Очищення можна повторити, якщо точно очікуваний каталог орендаря вже відсутній. Завдяки цьому наступний виклик може завершити очищення після часткового збою файлової системи, не послаблюючи перевірки шляхів для каталогів, які ще існують.

​
Сховище та структура контейнера

Стан комірки й ключі шифрування профілю автентифікації використовують окремі шляхи окремого орендаря на хості в активному каталозі стану OpenClaw:
Перший каталог монтується в /home/node/.openclaw. Другий монтується в /home/node/.config/openclaw відповідно до монтування ключа шифрування в офіційній конфігурації Docker. Тому ключ шифрування не розкривається в межах звичайного монтування стану й не додається до резервної копії або спільного ресурсу, якщо копіюється чи надається лише каталог стану комірки. Обидва каталоги зберігаються після звичайного видалення й оновлення; fleet rm --purge-data --force видаляє обидва після окремих перевірок меж. Перед першим запуском Fleet ініціалізує конфігурацію комірки з gateway.mode=local, автентифікацією за токеном, прив’язкою контейнера до LAN та джерелами Control UI для виділеного порту хоста. Значення токена не записується до цієї конфігурації; воно залишається в середовищі контейнера. Fleet закріплює шляхи контейнера офіційного образу за допомогою таких значень середовища: Офіційний образ стандартно використовує непривілейованого користувача node з UID 1000. Fleet зберігає приватні монтування 0700 доступними для запису, не роблячи їх загальнодоступними. Docker із правами root запускає комірку з UID і GID непривілейованого користувача, який викликав команду; Docker без прав root використовує UID 0 контейнера, що зіставляється з непривілейованим користувачем хоста, який викликав команду, у просторі імен користувачів демона. Podman використовує keep-id з UID і GID користувача, який викликав команду. Коли сам Fleet працює від імені root із середовищем виконання з правами root, він зберігає користувача образу й призначає початкові файли монтування UID/GID 1000. На хостах із SELinux монтування Docker і Podman отримують приватне перемаркування :Z. Якщо ви відновлюєте або переміщуєте дані комірки, забезпечте доступ до змонтованих шляхів для запису фактичному користувачеві контейнера. Профіль сумісний із режимом без прав root, але Docker або Podman уже має бути налаштовано для роботи без прав root на хості; Fleet не перетворює демон із правами root на демон без прав root.

​
Профіль безпеки

Fleet застосовує до кожної комірки такий профіль: Fleet ніколи не монтує /var/run/docker.sock, не використовує --privileged чи мережу хоста й не додає можливостей. Міст окремої комірки є межею розділення між комірками, а не міжмережевим екраном для вихідного трафіку: комірки зберігають мережевий вихід, необхідний для провайдерів і каналів. Розмістіть перед loopback-портом проксі, тунель SSH або конфігурацію tailnet, що відповідає вашому розгортанню. http://127.0.0.1:<port> безпосередньо доступний лише з хоста Fleet. Цей профіль розділяє контейнери орендарів, але не захищає орендарів від оператора Fleet, адміністратора середовища виконання контейнерів або скомпрометованого хоста. Повну модель довіри та варіанти посиленої ізоляції див. у розділі Багатоорендарський хостинг.

​
Обробка токенів

За замовчуванням fleet create генерує криптографічно випадковий 32-символьний шістнадцятковий токен Gateway і одноразово виводить його в результаті створення. Збережіть його у схваленому менеджері секретів і не допускайте потрапляння результату створення до журналів. --gateway-token розміщує власний токен в аргументах локального процесу, які можуть зберігатися в історії оболонки або бути видимими у списках процесів. Віддавайте перевагу згенерованому токену, якщо лише наявний процес керування секретами не потребує наданого значення. Токен і кожне значення, передане через --env, зберігаються в середовищі контейнера. Fleet записує їх у короткочасний файл середовища з режимом 0600, передає Docker або Podman лише шлях до цього файлу й видаляє його після завершення команди середовища виконання. Значення, явно введені в openclaw fleet create --gateway-token ... або --env KEY=VALUE, усе одно можуть бути видимими в аргументах зовнішнього процесу openclaw та історії оболонки. Значення середовища контейнера не приховані від довіреного оператора хоста: адміністратори Docker або Podman можуть прочитати їх за допомогою перевірки контейнера. Примітка Fleet «показується один раз» описує звичайний вивід CLI, а не захист від адміністратора хоста.

​
Пов’язані матеріали