尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

youki 的 liboci-cli:用 Rust 与 clap 构建 OCI 规范兼容的容器运行时命令行解析层

youki 的 liboci-cli:用 Rust 与 clap 构建 OCI 规范兼容的容器运行时命令行解析层 容器运行时云原生【免费下载链接】youkiA container runtime written in Rust项目地址https://gitcode.com/gh_mirrors/yo/youki点击查看免费下载导读liboci-cli是从 youki 主 crate 中拆分出来的独立 Rust crate它用 clap v4 实现了 OCI 规范兼容运行时OCI runtime-spec所需的一整套命令行参数结构体供 youki 解析youki create/start/state/kill/delete等子命令及全局参数使用。阅读本文后你将掌握该 crate 的模块划分、全部子命令与参数定义、与 youki 主程序入口的对接方式以及如何在自己的 Rust 项目中复用这套 OCI 命令行解析实现。从 youki 主 crate 分离为什么需要独立的 CLI 解析库在 youki 的历史版本中命令行解析代码直接内嵌在 youki 主 crate 内部。随着运行时功能不断扩展这部分代码被抽取为独立的liboci-clicrate当前版本 0.7.0见 crates/liboci-cli/Cargo.toml其定位在 crates/liboci-cli/README.md 中写得很明确这是一个用于解析 OCI 容器运行时命令行参数的 crate遵循 OCI Runtime Command Line Interface 规范。该 crate 包含一套独立的、用于解析 OCI 规范兼容运行时命令行参数的结构体实现主要服务于两个目标供 youki 自身使用youki 直接导入该 crate 中的结构体来解析用户传入的 CLI 参数可被任意第三方项目复用任何需要解析 OCI 规范命令行参数的项目都可以像使用普通库一样引入liboci-cli不必关心 youki 的其他实现细节。其解析引擎完全建立在 clap v4 之上Cargo.toml 中声明依赖clap并启用了derive、suggestions、help、usage、error-context等特性通过 derive 宏把结构体直接映射为命令行参数这是整个 crate 实现的基础。顶层结构三种命令类型与全局选项打开 crates/liboci-cli/src/lib.rs 可以看到crate 把命令划分成三大块并通过pub use统一导出1. 标准子命令StandardCmdOCI CLI 规范的强制要求依据 OCI Command Line Interface 规范符合规范的运行时必须实现以下五个子命令它们被封装在StandardCmd枚举中子命令结构体源码位置createCreatecreate.rsstartStartstart.rsstateStatestate.rskillKillkill.rsdeleteDeletedelete.rs2. 通用子命令CommonCmd规范未强制、但社区广泛接受的扩展OCI CLI 规范本身没有定义这些子命令但它们出现在 runc、crun 等其他运行时中已成为事实上的通用接口。CommonCmd枚举目前包含Checkpointtcheckpoint、Eventsevents、Execexec、Featuresfeatures、Listlist、Pausepause、Psps、Resumeresume、Runrun、Updateupdate、Specspec共 11 个。3. 全局选项GlobalOpts跨子命令共享的参数OCI CLI 规范没有定义任何全局标志但各运行时普遍接受以下参数lib.rs 中的GlobalOpts参数说明-l, --log PATH日志输出文件路径默认/dev/stderr--debug将日志级别改为 debug注意--log-level优先级更高--log-format FORMAT日志格式text默认或json-r, --root PATH存储容器状态数据的根目录--systemd-cgroup使用 systemd cgroup 管理器而不是直接操作 cgroupfs此外youki 还在GlobalOpts之外扩展了自己的YoukiExtendOpts--systemd-log启用 systemd-journald 日志、--log-level设置日志级别见 crates/youki/src/main.rs体现了标准库 运行时自有扩展的分层设计。标准子命令详解Create / Start / State / Kill / Deletecreate创建容器Create结构体create.rs参数如下参数类型/默认值说明-b, --bundle PATH默认.bundle 目录路径内含config.json与根文件系统--console-socket PATH可选Unix socket 文件路径用于接收伪终端pseudoterminal写端的文件描述符-p, --pid-file PATH可选容器 PID 写入的文件路径注释里提醒容器本质上也只是另一个进程--no-pivotbool不使用 pivot_root 将进程限制在 rootfs 内--no-new-keyringbool不为容器创建新的会话 keyring--preserve-fds N默认0额外传递给容器的文件描述符数量总数 stdio $LISTEN_FDS Ncontainer_id位置参数必填非空容器实例名称其中container_id使用clap::builder::NonEmptyStringValueParser保证非空required true强制必填——这是所有需要容器 ID 的子命令的统一写法。start启动已创建的容器Startstart.rs仅接受一个必填的container_id位置参数语义是启动一个此前通过 create 创建的容器。state查询容器状态Statestate.rs同样只有一个必填的container_id用于输出容器的当前状态created / running / stopped 等。kill向容器发送信号Killkill.rs除必填的container_id外signal位置参数必填要发送的信号支持KILL、TERM、9这类名称或数字表示-a, --all把信号发送给容器内的所有进程。delete释放容器资源Deletedelete.rscontainer_id必填-f, --force强制删除仍在运行的容器内部使用 SIGKILL。通用子命令详解Exec / Run / Update 等扩展能力run创建并立即启动Runrun.rs可视为createstart的合并参数与Create高度重合另有--no-subreaper禁用用于收养被 reparent 进程的 subreaper--keep容器退出后保留状态目录与 cgroup-d, --detach与容器进程分离。exec在已有容器内执行新进程Execexec.rs是参数最丰富的子命令之一参数说明--console-socket PATH接收伪终端写端 fd 的 socket--cwd PATH容器内工作目录-e, --env KEYVALUE注入环境变量可多次指定由自定义解析器解析-t, --tty为进程分配伪终端-u, --user UID[:GID]以指定用户及可选组运行支持UID或UID:GID两种写法-g, --additional-gids GID附加组 ID可多次指定-p, --process PATH指向 process.json 的路径-d, --detach与容器进程分离--pid-file PATH将容器进程 PID 写入的文件--process-label LABEL进程标签常用于 SELinux--apparmor PROFILE进程的 AppArmor 配置文件--no-new-privs阻止进程获得额外权限--cap CAP为进程 bounding set 增加 capability可多次指定--preserve-fds N额外传递的 fd 数量默认 0--ignore-paused允许在暂停的容器中执行 exec--cgroup PATH在子 cgroup 中执行进程container_id必填容器标识commandtrailing var arg容器内执行的命令及其参数events采集容器资源统计Eventsevents.rs支持--interval 秒默认 5 秒设置统计采集间隔、--stats只显示一次统计与必填的container_id。ps列出容器内进程Psps.rs支持-f, --formattable默认或json以及透传给 ps 工具的ps_options使用trailing_var_argallow_hyphen_values允许-ef这类以连字符开头的参数原样传入。list / pause / resume / features / specListlist.rs--format默认table、-q, --quiet只显示容器 IDPausepause.rs与Resumeresume.rs仅接受必填的container_id分别挂起/恢复容器内进程Featuresfeatures.rs空参数结构体输出容器的特性列表features该子命令参考 runc 的 features 实现与 OCI runtime-spec 的 features-linux 文档Specspec.rs-b, --bundle PATH设置 bundle 根目录、--rootless生成 rootless 容器配置用于生成config.json。update在线调整资源约束Updateupdate.rs对应 runc 的runc update可在线修改运行中容器的资源限制参数覆盖 CPU、内存、cpuset、PIDs 与 Intel RDT参数说明-r, --resources FILE从 JSON 文件读取新资源限制-表示从 stdin 读取使用后其他选项全部忽略--blkio-weight N新的 I/O 权重--cpu-period us/--cpu-quota usCPU CFS 周期/配额微秒--cpu-rt-period us/--cpu-rt-runtime usCPU 实时调度周期/硬上限微秒--cpu-share NCPU shares相对权重--cpuset-cpus LIST/--cpuset-mems LIST可用 CPU/内存节点支持逗号与区间如0-3,7--memory bytes/--memory-reservation bytes内存硬限制 / 软限制字节--memory-swap bytes内存 swap 总量上限-1表示不设限--pids-limit N容器内最大进程数--l3-cache-schema SCHEMA/--mem-bw-schema SCHEMAIntel RDT/CAT L3 缓存与 MBA 内存带宽 schemacheckpoint基于 CRIU 的容器检查点Checkpointcheckpoint.rs对应 runc 的 checkpoint 功能参数用于控制 CRIU 的镜像保存行为--image-path PATHCRIU 镜像文件保存路径默认checkpoint--work-path PATH工作文件与日志保存路径--leave-running检查点保存后让进程继续运行--tcp-established/--tcp-skip-in-flight允许/跳过在途 TCP 连接--link-remap、--ext-unix-sk、--shell-job、--file-locks分别允许链接重映射、外部 Unix socket、shell 作业与文件锁--manage-cgroups-mode MODEcgroup 管理模式取值ignore/full/strict/soft默认soft--empty-ns NS对命名空间做检查点但不保存其属性目前仅接受network默认值也是network——注释说明 youki 不管理网络设备因此无法向 CRIU 描述其外部依赖。源码中还以 TODO 注释形式保留了未实现的选项如parent-path、lazy-pages、status-fd、page-server、pre-dump、auto-dedup这些在 youki 中属于规划中但尚未落地的能力从源码结构看与 runc 的完整 checkpoint 参数集仍有差距。源码级细节自定义值解析器与参数校验Exec中用到了两个值得注意的自定义解析函数exec.rsparse_env把KEYVALUE形式的字符串在第一个处拆分分别解析为键和值若找不到则返回invalid VARvalue: no found错误parse_user支持UID或UID:GID两种输入找不到:时组 ID 为None。它们都是泛型函数T: FromStr、T::Err: Error Send Sync因此天然支持把字符串解析为任意实现FromStr的类型这是 clap derive 模式下自定义 value parser的典型写法。参数校验方面所有容器 ID 位置参数统一使用NonEmptyStringValueParserrequired true从解析层面杜绝了空容器 ID 进入后续流程--preserve-fds等数值型参数由 clap 的default_value提供默认值默认0--manage-cgroups-mode通过PossibleValuesParser限定可选值集合。youki 主程序如何消费这些结构体youki 的入口 crates/youki/src/main.rs 展示了完整的对接方式use liboci_cli::{CommonCmd, GlobalOpts, StandardCmd};引入三个核心类型顶层Opts通过#[command(flatten)]合并GlobalOpts、YoukiExtendOpts与YoukiSubCommandYoukiSubCommand枚举同样用#[command(flatten)]内嵌liboci_cli::StandardCmd与liboci_cli::CommonCmd再追加 youki 特有的Info、Completion两个扩展子命令在main()中把解析结果分派到 crates/youki/src/commands 下各命令模块例如StandardCmd::Create(create) commands::create::create(create, root_path, systemd_cgroup)、CommonCmd::Exec(exec) commands::exec::exec(exec, root_path)等。可见 liboci-cli 承担了解析层youki 的 commands 目录承担执行层两者通过结构体解耦——这也是 liboci-cli 能被独立复用的原因。实现覆盖度与 OCI CLI 规范及 runc/crun 的对照crates/liboci-cli/README.md 维护了一张实现覆盖度对照表可归纳如下规范强制命令create、start、state、kill、delete全部实现且与 runc、crun、youki 均支持扩展命令events、exec、features、list、pause、ps、resume、run、spec已实现features在 runc 与 liboci-cli 中支持update已进入 liboci-cli 与 youkimain.rs 中可见CommonCmd::Update分派但 README 对照表尚未为其勾选属于文档滞后于代码的情况未实现restore容器恢复目前没有对应结构体checkpoint 的镜像恢复能力仍属空白。该对照表同时印证了 liboci-cli 的设计目标它不是 youki 的私有代码而是把OCI 运行时公共 CLI 面沉淀为可独立演进、可对照规范审计的共享库。在其他项目中复用 liboci-cli由于该 crate 只依赖 clap且所有结构体均为公开导出复用成本很低。在任意 Rust 项目中只需[dependencies] liboci-cli { path crates/liboci-cli } clap { version 4, features [derive] }然后在入口类型中组合即可与 youki 的做法完全一致use clap::{Parser, Subcommand}; use liboci_cli::{CommonCmd, GlobalOpts, StandardCmd}; #[derive(Parser)] #[command(name my-oci-runtime)] struct Opts { #[command(flatten)] global: GlobalOpts, #[command(subcommand)] subcmd: MySubCommand, } #[derive(Subcommand)] enum MySubCommand { #[command(flatten)] Standard(BoxStandardCmd), #[command(flatten)] Common(BoxCommonCmd), }这样你的运行时便自动获得与 youki 一致的参数解析行为包括全局选项、非空容器 ID 校验、--preserve-fds默认值等无需重新实现规范细节。小结liboci-cli用约 20 个短小源码文件crates/liboci-cli/src把 OCI 运行时命令行的公共面完整落地五个规范强制的标准子命令、十一个社区通用子命令、一套全局选项全部基于 clap v4 的 derive 宏声明式定义。对 youki 而言它是主程序main.rs与各命令执行模块之间的解析层对整个 Rust 容器生态而言它是一个可独立复用的 OCI CLI 解析组件。如果你想了解 youki 的命令行全貌从 lib.rs 的枚举定义出发再对照 main.rs 的分派逻辑逐层阅读是最快的路径。赞分享容器运行时云原生【免费下载链接】youkiA container runtime written in Rust项目地址https://gitcode.com/gh_mirrors/yo/youki点击查看免费下载相关推荐youki 的 liboci-cli用 clap 解析 OCI 容器运行时命令行参数的统一实现youki 的 liboci cli用 clap 解析 OCI 容器运行时命令行参数的统一实现 导读 liboci cli 是 youki用 Rust 编容器运行时云原生liboci-cli 深度解析youki 容器运行时的 OCI 命令行参数解析层liboci cli 深度解析youki 容器运行时的 OCI 命令行参数解析层 youki 是一个用 Rust 编写的 OCI 容器运行时。在它的多 cra容器运行时云原生TypeScript 高级类型系统实战指南来自 agents24 市场的 typescript-advanced-types 技能深度解析TypeScript 高级类型系统实战指南来自 agents24 市场的 typescript advanced types 技能深度解析 导读 本文以 ag容器运行时云原生上一篇探索Cypress-wait-until实现更强大的等待功能下一篇whichllm版本更新日志v1到v2的核心功能演进与性能提升创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表