iii v0.21.0 Worker 全生命周期管理从iii worker add到iii.lock可复现部署【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iii本文基于 iii 官方文档库中 0.21.0 版本的 Workers 指南编写系统讲解 iii 中 Worker 的接入模型、RBAC 访问控制以及iii worker子命令族add / list / start / stop / status / logs / exec / update / remove / clear / sync / verify的完整用法与iii.lock锁文件机制并结合开源仓库中iii-workerCLI crate 的锁文件实现与引擎侧配置样例帮助你掌握 iii 项目级 Worker 的安装、运维与可复现部署方案。Worker 生命周期连接、可见与断连Worker 通过 WebSocket 连接 iii 引擎。一个 Worker 一旦连接成功它对整个 iii 系统以及系统内所有其他 Worker 可见当它断开连接时它注册的函数和触发器将停止被调用直到重新连接为止。这一注册随连接存在、断连即失效的模型意味着Worker 的可用性直接取决于其进程与引擎之间的 WebSocket 连接状态。对运行 Worker 代码一侧、负责建立连接的 SDK 调用参见 Creating Workers / Workers。非可信 Worker 与访问控制RBAC默认情况下iii 引擎的监听器信任任何连接到它的客户端——这对你自己运行的 Worker 没有问题。但一个你并不控制的 Worker、浏览器客户端或第三方 Worker绝不应该获得同样的无限制访问权。这类客户端应当通过iii-worker-manager这个 Worker 接入它暴露了一个独立的基于角色的访问控制RBAC监听器iii worker add iii-worker-managerRBAC 监听器会在每一次连接上执行你编写的一个认证函数据此准入或拒绝该连接并决定这个连接可以使用哪些函数和触发器类型——这样非可信 Worker 只能看到你授权给它的那部分能力面。其完整配置项、认证与中间件函数的形状以及连接流程记录在 iii-worker-manager 的 Worker 文档页registry 站点 workers.iii.dev 上原文档以外链给出此处不重复粘贴。管理 Workeriii worker命令族iii workerCLI 覆盖项目中每个 Worker 的完整生命周期在 registry 中查找新的 Worker、将其安装进config.yaml与iii.lock、控制其运行状态、查看日志、以及在不再需要时移除它。查找 WorkerRegistryiii 维护了一个 Worker registry收录了大量封装常见服务的 Worker。更多 registry 相关信息见 Worker Registry。添加 Worker三种来源前提添加 Worker 之前需要先 安装 iii 并且引擎已 运行。如果要为一个临时测试环境快速拉起一个 iii 实例可以在一个空白目录里直接运行iii当目录中还没有config.yaml时它会创建一个 workers 列表为空的配置文件之后即可执行iii worker add参见 Default configuration 一节。Worker 可以从三种不同来源添加到 iii 实例iii worker registryDocker / OCI 兼容镜像仓库本地开发的 Worker见 Creating Workers / Scaffold a new Worker。iii worker add name将 Worker 安装到你的项目中iii worker add state # Downloads and adds a worker from iii registry iii worker add ./workers/my_worker # Adds a local worker created with iii worker init iii worker add ghcr.io/org/worker:tag # Pulls and adds a worker from a Docker or OCI image registryWorker 被写入config.yaml后自动启动。若要强制重新下载一个已存在的 Worker使用iii worker reinstall name等价于add --force。几个关键行为细节0.21.0 文档明确说明实操时务必注意iii worker add只写裸- name:条目不带config:块。Worker 以内置默认值启动运行时设置由 configuration worker 管理其条目是./config/目录下可编辑的本地文件。手动写进config.yaml的config:块仍然有效作为一次性首启种子重新添加 Worker 时会保留它。iii-sandbox是例外add 时会写入 sandbox 的config:块因为镜像白名单直接从该文件强制执行。默认编辑当前目录的配置文件因此请在与目标引擎相同的文件夹里执行。要安装到运行在别处的引擎不同目录、不同机器或非默认端口传--hostiii worker add pdfkit --host localhost:49134带--host时 CLI 调用引擎的worker::add触发器由引擎在它自己的项目目录中应用安装你当前目录里的文件完全不被触碰。在没有配置文件的目录执行iii worker add不会就地创建配置文件命令会回退到--host localhost通过本机正在运行的引擎完成安装并打印一条说明。只有已经持有配置文件或显式传了--host的目录才决定安装落点。镜像解析范围iii worker add从远程仓库iii registry 或 OCI registry或本地文件夹下载 Worker 镜像然后在 microVM 中运行。像caller-worker:latest这样的裸引用只会去这些远程仓库查找iii不会读取本地 Docker daemon 中的镜像所以你用docker build构建的本地镜像无法按名字被找到。本地构建的 Docker 镜像可以像其他任何 Docker 镜像那样直接运行测试docker run -it caller-worker:latest。版本固定PinningRegistry Worker 以 semver 版本发布。不带版本说明符安装时选择最新 release在 registry 名后追加version可固定到特定 release 而不是追踪最新iii worker add state1.2.0固定值会被记录在iii.lock中并在之后的每次安装中重放。列出 Workeriii worker list显示项目config.yaml中声明的所有 Worker 及其当前状态这是查看运行中/已停止 Worker 列表的手段iii worker list启动与停止已添加的 Worker 随引擎自动启动。手动控制使用start、stop、restartiii worker start name # start one worker iii worker stop -y name # stop one worker (-y skips the confirmation prompt) iii worker restart name # stop then start两条补充说明原文 Note实践中容易踩坑这些命令管理的是iii 为你在内置虚拟化中运行的 Worker。但 iii 并非必须亲自运行 Worker任何使用 iii SDK、调用registerWorker()并连接到 iii 实例的进程都是一个 Worker。这一点在创建 Worker或部署 iii 系统时会变得更加重要。若要调用运行中 Worker 内部的函数直接用worker.trigger/iii trigger或把它们绑定到事件并可选地加上条件门见 Triggers。检查 Worker查看某个 Worker 的状态、跟随其日志、或在其沙箱内执行命令iii worker status name # config, sandbox state, recent logs iii worker logs name # stream the workers logs iii worker exec name -- command # run a command inside the worker更新 Workeriii worker update重新解析已锁定的 Worker并把新的版本固定写回iii.lock。传 Worker 名更新单个省略则更新所有已锁定的 Workeriii worker update worker-name # one worker iii worker update # every locked worker移除 Workeriii worker remove把 Worker 从config.yaml中删掉引擎随即拆除运行中的 Worker 进程iii worker remove -y worker-name # -y skips the confirmation when the worker is running移除后已下载的文件产物仍保留在磁盘上。要连同删除产物使用iii worker clear -y worker-name省略名字则清除所有 Worker 的产物。Worker Skills面向 Agentic 场景的能力每个 Worker 同时附带面向 Agentic 工作的 skills。Skills 由skillsWorker 管理——它是一个持续开发中的内容注册表 Worker像其他 Worker 一样添加到项目中。关键机制是懒加载顶层条目保持轻量agent 只有在函数引用解析到某个 section 时才通过iii://worker/leaf形式的 section URI 拉取更深层内容。iii 也附带发布高层 skills使任意 agent 能够立即使用 iii 及其 Worker。Worker 提供的可用函数与触发器函数和触发器来自已连接的 Worker。要使用某一类型的触发器提供该类型的 Worker 必须处于连接状态。例如通过 http Worker 添加http触发器后你就可以像 Express 或 FastAPI 这样的 Web 框架一样为你的函数暴露端点。版本管理与iii.lock锁文件iii Worker 遵循 semver。项目把每个受管 Worker 的解析版本记录在iii.lock中使安装在不同机器与平台之间可复现。iii.lock的结构iii.lock是项目根目录下的 YAML 文件把每个受管 Worker 固定到特定版本和来源保证同一组 Worker 在任何机器、任何平台上都以相同方式安装二进制 Worker 还可以在同一个锁文件中固定各平台macOS、Linux、Windows的产物。请把iii.lock与config.yaml一起提交到版本库以获得可复现安装。仓库自带的 engine/iii.lock 就是一个真实样例version: 1 workers: iii-http: version: 0.13.0-next.1 type: engine dependencies: {}从源码结构看锁文件的完整 schema 定义在 crates/iii-worker/src/cli/lockfile.rs顶层WorkerLockfile含version、可选的manifest_hash形如sha256:v1:64-hexv1 段是哈希算法版本而非锁文件格式版本、可选的declared_dependencies写锁时项目iii.worker.yaml声明的依赖用于精确报告漂移中新增/移除/变更的依赖以及workers映射。每个LockedWorker含version、type四种取值binary/image/engine/bundle、dependencies与可选sourcesource区分三类binary按平台映射到urlsha256的产物列表、image镜像引用、bundlearchive_urlsha256。这套结构正是上文二进制 Worker 可按平台固定产物说法的实现依据。直接操作锁文件的命令iii worker sync # install workers exactly from iii.lock iii worker sync --frozen # CI form: verify the lockfile without mutating local files iii worker verify # report drift between config.yaml and iii.lockiii worker update是第三个与锁文件相关的命令它把版本固定重新解析到允许范围内的最新版本并写回iii.lock。仓库中 crates/iii-worker/tests/ 目录下的 sync_drift_adversarial.rs、worker_integration.rs、local_add_manifest_validation_integration.rs 等测试用例分别覆盖 sync 漂移检测、Worker 集成与本地添加的清单校验可作为上述命令行为的验证依据。引擎侧配置的对照config.yaml里的 Worker 条目0.21.0 文档描述的config.yamlWorker 声明方式在仓库引擎配置中仍能看到对应形态。engine/config.yaml 声明了引擎生命周期内的 Worker 条目及其config:块例如configurationWorker 使用fs适配器、目录为./config/ttl_seconds: 0被注释的iii-sandbox示例则展示了文档中提到的那个例外——add 时写入的 sandboxconfig:块含auto_install、image_allowlist、default_idle_timeout_secs、max_concurrent_sandboxes、default_cpus、default_memory_mb等字段印证了镜像白名单从文件强制执行的说法。编写 WorkerOut of scope 说明创建新 Worker、在 Worker 代码中注册函数与触发器、构建或发布 Worker 镜像均不在本页范围内参见 Creating Workers / Workers。版本适用性说明上文全部命令与行为以v0.21.0 文档为准。需要注意在当前仓库主干代码中iii worker已不再是公共命令——engine/src/main.rs 中的测试worker_is_no_longer_a_public_command明确断言iii worker add http会被根 CLI 拒绝且 docs/next/using-iii/workers.mdx 记载 v0.23 起项目 Worker 的声明与启动改由worker-compose.yamliii compose承担registry 包写作package://api.workers.iii.dev/name 显式version运行命令为iii compose --namespace dev --up --file worker-compose.yaml等。如果你使用的是 v0.23 及以上版本请改以 Compose 方式管理项目 Worker本文中的锁文件与 registry 机制概念仍然适用。【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iii创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 iii v0.21.0 Worker 全生命周期管理：从 `iii worker add` 到 `iii.lock` 可复现部署
iii v0.21.0 Worker 全生命周期管理从iii worker add到iii.lock可复现部署【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iii本文基于 iii 官方文档库中 0.21.0 版本的 Workers 指南编写系统讲解 iii 中 Worker 的接入模型、RBAC 访问控制以及iii worker子命令族add / list / start / stop / status / logs / exec / update / remove / clear / sync / verify的完整用法与iii.lock锁文件机制并结合开源仓库中iii-workerCLI crate 的锁文件实现与引擎侧配置样例帮助你掌握 iii 项目级 Worker 的安装、运维与可复现部署方案。Worker 生命周期连接、可见与断连Worker 通过 WebSocket 连接 iii 引擎。一个 Worker 一旦连接成功它对整个 iii 系统以及系统内所有其他 Worker 可见当它断开连接时它注册的函数和触发器将停止被调用直到重新连接为止。这一注册随连接存在、断连即失效的模型意味着Worker 的可用性直接取决于其进程与引擎之间的 WebSocket 连接状态。对运行 Worker 代码一侧、负责建立连接的 SDK 调用参见 Creating Workers / Workers。非可信 Worker 与访问控制RBAC默认情况下iii 引擎的监听器信任任何连接到它的客户端——这对你自己运行的 Worker 没有问题。但一个你并不控制的 Worker、浏览器客户端或第三方 Worker绝不应该获得同样的无限制访问权。这类客户端应当通过iii-worker-manager这个 Worker 接入它暴露了一个独立的基于角色的访问控制RBAC监听器iii worker add iii-worker-managerRBAC 监听器会在每一次连接上执行你编写的一个认证函数据此准入或拒绝该连接并决定这个连接可以使用哪些函数和触发器类型——这样非可信 Worker 只能看到你授权给它的那部分能力面。其完整配置项、认证与中间件函数的形状以及连接流程记录在 iii-worker-manager 的 Worker 文档页registry 站点 workers.iii.dev 上原文档以外链给出此处不重复粘贴。管理 Workeriii worker命令族iii workerCLI 覆盖项目中每个 Worker 的完整生命周期在 registry 中查找新的 Worker、将其安装进config.yaml与iii.lock、控制其运行状态、查看日志、以及在不再需要时移除它。查找 WorkerRegistryiii 维护了一个 Worker registry收录了大量封装常见服务的 Worker。更多 registry 相关信息见 Worker Registry。添加 Worker三种来源前提添加 Worker 之前需要先 安装 iii 并且引擎已 运行。如果要为一个临时测试环境快速拉起一个 iii 实例可以在一个空白目录里直接运行iii当目录中还没有config.yaml时它会创建一个 workers 列表为空的配置文件之后即可执行iii worker add参见 Default configuration 一节。Worker 可以从三种不同来源添加到 iii 实例iii worker registryDocker / OCI 兼容镜像仓库本地开发的 Worker见 Creating Workers / Scaffold a new Worker。iii worker add name将 Worker 安装到你的项目中iii worker add state # Downloads and adds a worker from iii registry iii worker add ./workers/my_worker # Adds a local worker created with iii worker init iii worker add ghcr.io/org/worker:tag # Pulls and adds a worker from a Docker or OCI image registryWorker 被写入config.yaml后自动启动。若要强制重新下载一个已存在的 Worker使用iii worker reinstall name等价于add --force。几个关键行为细节0.21.0 文档明确说明实操时务必注意iii worker add只写裸- name:条目不带config:块。Worker 以内置默认值启动运行时设置由 configuration worker 管理其条目是./config/目录下可编辑的本地文件。手动写进config.yaml的config:块仍然有效作为一次性首启种子重新添加 Worker 时会保留它。iii-sandbox是例外add 时会写入 sandbox 的config:块因为镜像白名单直接从该文件强制执行。默认编辑当前目录的配置文件因此请在与目标引擎相同的文件夹里执行。要安装到运行在别处的引擎不同目录、不同机器或非默认端口传--hostiii worker add pdfkit --host localhost:49134带--host时 CLI 调用引擎的worker::add触发器由引擎在它自己的项目目录中应用安装你当前目录里的文件完全不被触碰。在没有配置文件的目录执行iii worker add不会就地创建配置文件命令会回退到--host localhost通过本机正在运行的引擎完成安装并打印一条说明。只有已经持有配置文件或显式传了--host的目录才决定安装落点。镜像解析范围iii worker add从远程仓库iii registry 或 OCI registry或本地文件夹下载 Worker 镜像然后在 microVM 中运行。像caller-worker:latest这样的裸引用只会去这些远程仓库查找iii不会读取本地 Docker daemon 中的镜像所以你用docker build构建的本地镜像无法按名字被找到。本地构建的 Docker 镜像可以像其他任何 Docker 镜像那样直接运行测试docker run -it caller-worker:latest。版本固定PinningRegistry Worker 以 semver 版本发布。不带版本说明符安装时选择最新 release在 registry 名后追加version可固定到特定 release 而不是追踪最新iii worker add state1.2.0固定值会被记录在iii.lock中并在之后的每次安装中重放。列出 Workeriii worker list显示项目config.yaml中声明的所有 Worker 及其当前状态这是查看运行中/已停止 Worker 列表的手段iii worker list启动与停止已添加的 Worker 随引擎自动启动。手动控制使用start、stop、restartiii worker start name # start one worker iii worker stop -y name # stop one worker (-y skips the confirmation prompt) iii worker restart name # stop then start两条补充说明原文 Note实践中容易踩坑这些命令管理的是iii 为你在内置虚拟化中运行的 Worker。但 iii 并非必须亲自运行 Worker任何使用 iii SDK、调用registerWorker()并连接到 iii 实例的进程都是一个 Worker。这一点在创建 Worker或部署 iii 系统时会变得更加重要。若要调用运行中 Worker 内部的函数直接用worker.trigger/iii trigger或把它们绑定到事件并可选地加上条件门见 Triggers。检查 Worker查看某个 Worker 的状态、跟随其日志、或在其沙箱内执行命令iii worker status name # config, sandbox state, recent logs iii worker logs name # stream the workers logs iii worker exec name -- command # run a command inside the worker更新 Workeriii worker update重新解析已锁定的 Worker并把新的版本固定写回iii.lock。传 Worker 名更新单个省略则更新所有已锁定的 Workeriii worker update worker-name # one worker iii worker update # every locked worker移除 Workeriii worker remove把 Worker 从config.yaml中删掉引擎随即拆除运行中的 Worker 进程iii worker remove -y worker-name # -y skips the confirmation when the worker is running移除后已下载的文件产物仍保留在磁盘上。要连同删除产物使用iii worker clear -y worker-name省略名字则清除所有 Worker 的产物。Worker Skills面向 Agentic 场景的能力每个 Worker 同时附带面向 Agentic 工作的 skills。Skills 由skillsWorker 管理——它是一个持续开发中的内容注册表 Worker像其他 Worker 一样添加到项目中。关键机制是懒加载顶层条目保持轻量agent 只有在函数引用解析到某个 section 时才通过iii://worker/leaf形式的 section URI 拉取更深层内容。iii 也附带发布高层 skills使任意 agent 能够立即使用 iii 及其 Worker。Worker 提供的可用函数与触发器函数和触发器来自已连接的 Worker。要使用某一类型的触发器提供该类型的 Worker 必须处于连接状态。例如通过 http Worker 添加http触发器后你就可以像 Express 或 FastAPI 这样的 Web 框架一样为你的函数暴露端点。版本管理与iii.lock锁文件iii Worker 遵循 semver。项目把每个受管 Worker 的解析版本记录在iii.lock中使安装在不同机器与平台之间可复现。iii.lock的结构iii.lock是项目根目录下的 YAML 文件把每个受管 Worker 固定到特定版本和来源保证同一组 Worker 在任何机器、任何平台上都以相同方式安装二进制 Worker 还可以在同一个锁文件中固定各平台macOS、Linux、Windows的产物。请把iii.lock与config.yaml一起提交到版本库以获得可复现安装。仓库自带的 engine/iii.lock 就是一个真实样例version: 1 workers: iii-http: version: 0.13.0-next.1 type: engine dependencies: {}从源码结构看锁文件的完整 schema 定义在 crates/iii-worker/src/cli/lockfile.rs顶层WorkerLockfile含version、可选的manifest_hash形如sha256:v1:64-hexv1 段是哈希算法版本而非锁文件格式版本、可选的declared_dependencies写锁时项目iii.worker.yaml声明的依赖用于精确报告漂移中新增/移除/变更的依赖以及workers映射。每个LockedWorker含version、type四种取值binary/image/engine/bundle、dependencies与可选sourcesource区分三类binary按平台映射到urlsha256的产物列表、image镜像引用、bundlearchive_urlsha256。这套结构正是上文二进制 Worker 可按平台固定产物说法的实现依据。直接操作锁文件的命令iii worker sync # install workers exactly from iii.lock iii worker sync --frozen # CI form: verify the lockfile without mutating local files iii worker verify # report drift between config.yaml and iii.lockiii worker update是第三个与锁文件相关的命令它把版本固定重新解析到允许范围内的最新版本并写回iii.lock。仓库中 crates/iii-worker/tests/ 目录下的 sync_drift_adversarial.rs、worker_integration.rs、local_add_manifest_validation_integration.rs 等测试用例分别覆盖 sync 漂移检测、Worker 集成与本地添加的清单校验可作为上述命令行为的验证依据。引擎侧配置的对照config.yaml里的 Worker 条目0.21.0 文档描述的config.yamlWorker 声明方式在仓库引擎配置中仍能看到对应形态。engine/config.yaml 声明了引擎生命周期内的 Worker 条目及其config:块例如configurationWorker 使用fs适配器、目录为./config/ttl_seconds: 0被注释的iii-sandbox示例则展示了文档中提到的那个例外——add 时写入的 sandboxconfig:块含auto_install、image_allowlist、default_idle_timeout_secs、max_concurrent_sandboxes、default_cpus、default_memory_mb等字段印证了镜像白名单从文件强制执行的说法。编写 WorkerOut of scope 说明创建新 Worker、在 Worker 代码中注册函数与触发器、构建或发布 Worker 镜像均不在本页范围内参见 Creating Workers / Workers。版本适用性说明上文全部命令与行为以v0.21.0 文档为准。需要注意在当前仓库主干代码中iii worker已不再是公共命令——engine/src/main.rs 中的测试worker_is_no_longer_a_public_command明确断言iii worker add http会被根 CLI 拒绝且 docs/next/using-iii/workers.mdx 记载 v0.23 起项目 Worker 的声明与启动改由worker-compose.yamliii compose承担registry 包写作package://api.workers.iii.dev/name 显式version运行命令为iii compose --namespace dev --up --file worker-compose.yaml等。如果你使用的是 v0.23 及以上版本请改以 Compose 方式管理项目 Worker本文中的锁文件与 registry 机制概念仍然适用。【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iii创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考