mise oci run 实战指南从 mise.toml 构建容器镜像并运行命令【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/misemise oci run是 mise 实验性 OCI 子命令体系中构建 运行的一站式入口它基于当前项目的 mise.toml 构建一个 OCI 镜像并借助本机 podman / docker 引擎在容器内执行命令stdin/stdout/stderr 直接继承。读完本文你将掌握mise oci run的完整参数语义、引擎选择与镜像装载原理、默认清理机制以及复用既有镜像布局的实战技巧从而把声明式工具环境无缝封装进可运行的容器。命令概览一次调用完成 build runmise oci run等价于先执行mise oci build、再执行docker run/podman run。其完整用法为mise oci run [FLAGS] [-- CMD]…命令位于mise oci SUBCOMMAND之下与build、push并列三者分别负责生成 OCI 布局构建并运行构建并推送见 docs/dev-tools/mise-oci.md 中的总览表。核心源码在 src/cli/oci/run.rsRun::run()src/cli/oci/run.rs#L110-L221依次完成参数校验、引擎探测、镜像构建/复用、镜像装载、引擎run调用与清理。前置条件命令标注为experimental需要同时满足开启实验特性mise settings experimentaltrue持久化或按次调用MISE_EXPERIMENTAL1 mise oci run …。源码中由Settings::get().ensure_experimental(mise oci run)?src/cli/oci/run.rs#L111强制校验。本机存在容器引擎podman或docker二者至少其一。参数与标志完整参考参数参数说明[-- CMD]…--之后为要在容器内执行的命令及其参数即mise oci run [FLAGS] -- cmd [args...]标志标志说明--engine ENGINE容器引擎auto默认优先 podman、podman、docker--from FROM构建时的基础镜像引用与--image-dir互斥时被忽略--image-dir IMAGE_DIR复用已构建好的 OCI 镜像布局跳过构建步骤必须包含index.json--include-global同时纳入全局/系统配置中的工具默认仅项目配置细节见mise oci build --help--keep运行结束后保留引擎存储中的镜像默认清理见下文生命周期--mount-point MOUNT_POINT覆盖镜像内工具安装挂载点与--image-dir互斥--no-mise不把 mise 二进制嵌入镜像与--image-dir互斥--owner UID[:GID]构建时赋予每个 tar 条目所有者的 UID[:GID]与--image-dir冲突覆盖[oci].user_id/[oci].group_id默认0:0省略 GID 时取 UID。只影响文件所有权镜像的USER指令由[oci].user控制--volume HOST:CONTAINER绑定挂载主机路径可重复格式HOST:CONTAINER[:MODE]。注意没有-v短标志因为 mise 保留-v给--verbose请用--volume或--mount-e, --env KEYVAL设置容器环境变量可重复-i, --interactive交互式运行向引擎传递-i-t, --tty分配 TTY向引擎传递-t-w, --workdir WORKDIR容器内工作目录-h, --help打印帮助其中--engine的定义见 src/cli/oci/run.rs#L102-L107 的Engine枚举--volume在源码中使用alias mountsrc/cli/oci/run.rs#L77因此--mount也可作为等价写法。三个开箱即用的示例1. 交互式进入容器 shellmise oci run -it -- bash构建当前 mise.toml 对应的镜像后以交互式 TTY 方式进入 bash。2. 一次性命令环境变量 挂载 工作目录mise oci run -e DEBUG1 --volume $PWD:/work -w /work -- npm test把当前目录挂载到容器内/work、设置DEBUG1、将工作目录切到/work执行npm test。注意这里--volume不能缩写为-v。3. 复用已构建的镜像布局跳过构建mise oci build -o ./img mise oci run --image-dir ./img -- node -e console.log(process.version)先用mise oci build -o ./img产出 OCI 布局再通过--image-dir ./img直接复用适合反复运行同一镜像做多次实验。mise-oci 总指南中的快速开始也推荐了同样的组合docs/dev-tools/mise-oci.mdmise oci build -o ./mise-oci mise oci run --image-dir ./mise-oci -- node --version引擎选择与镜像装载原理mise oci run在auto模式下优先选择 podman其次是 docker两者都不可用时直接报错src/cli/oci/run.rs#L224-L249--engine podman要求 PATH 中存在podman否则报错--engine docker要求 PATH 中存在docker否则报错--engine auto先探测podman再探测docker都没有则提示安装二者之一。装载方式随引擎不同而不同src/cli/oci/run.rs#L267-L308podman原生支持 OCI 布局mise 执行podman pull --quiet oci:dir直接拉取本地布局--quiet输出恰好是镜像 IDmise 捕获该 ID 作为后续podman run的引用。源码注释特别说明不依赖podman tag因为 tag 需要镜像名/ID 而非 transport 引用且镜像名随 podman 版本浮动捕获pull --quiet输出的镜像 ID 跨版本更稳定。dockermise 通过docker load把布局以 docker-archive 流式灌入 daemon。为避免并发调用互相踩踏镜像标签按进程 ID 纳秒时间戳生成mise-oci:run-pid-nanos见 src/cli/oci/run.rs#L295-L302这样两次并发的mise oci run不会因共享mise-oci:run标签而在容器启动前互相覆盖镜像。最终执行的等价命令为engine run [--rm] [-i] [-t] [-e KV]... [-v HOST:CONTAINER]... [-w DIR] image-ref cmd...参数透传逻辑见 src/cli/oci/run.rs#L160-L189。生命周期与默认清理机制mise oci run默认在命令退出后执行双重清理src/cli/oci/run.rs#L191-L210向引擎传--rm运行结束即删除容器主动调用engine rmi --force image-ref删除装载进引擎存储的镜像避免重复调用在 podman/docker 存储中累积镜像。也就是说默认情况下docker run --rm只删容器、不删镜像mise 补上了镜像清理这一步反复执行mise oci run不会让引擎存储越积越多。rmi失败例如镜像正被其他并发运行占用不会导致整体命令失败仅记入 debug 日志。若希望保留镜像docker 下标签为mise-oci:run-*podman 下为拉取的镜像 ID传--keep即可。另外构建过程产生的临时布局目录存放在TempDir中前缀mise-oci-run-随TempDir析构自动删除——GB 级的工具层不会残留在 /tmp 中src/cli/oci/run.rs#L130-L152。参数校验与互斥约束参数优先于引擎探测源码先校验参数再探测引擎因此--image-dir指向的目录若缺少index.json不符合 OCI 布局结构会先于引擎缺失报错提示does not look like an OCI image layout (missing index.json)src/cli/oci/run.rs#L113-L121。--image-dir与构建类参数互斥--from、--mount-point、--no-mise、--owner、--include-global均不能与--image-dir同时使用src/cli/oci/run.rs#L38因为复用既有布局时不存在构建动作。与mise oci build/mise oci push的分工命令职责mise oci build把 mise.toml 变成磁盘上的 OCI 镜像布局每个工具独立成层mise oci run构建或复用镜像并在 podman/docker 中运行命令mise oci push构建或复用镜像并用 mise 内置的 registry 客户端推送mise oci run关注本地执行验证它需要一个容器引擎且构建用的工具必须是主机二进制Linux 主机、目标架构一致。如需发布镜像则应使用mise oci push无需 docker/podman仅需 registry 凭据。mise oci run自身不依赖任何 registry——装载发生在本地引擎中。二者共享的构建层细节layering、[oci]配置段、[bootstrap]/[dotfiles]支持、环境变量组装顺序、可复现性等见 docs/dev-tools/mise-oci.md。使用前提与限制实验性 API行为、标志和输出布局在后续版本可能变化升级 mise 后建议查看mise oci run --help。主机平台约束镜像内容是主机原生二进制在 macOS/Windows 上构建出的镜像虽标记为 linux但内部二进制仍是宿主机架构在容器内会报Exec format error应在 Linux 主机或 Linux 开发容器中构建与运行。引擎必需mise 没有内置容器运行时mise oci run必须依赖 podman 或 dockermise oci push则无需任何外部工具。环境变量中的机密写入[env]的值含.env解析结果会进入镜像 config JSON可能被docker inspect读取运行时机密请通过-e、secret mount 或编排器注入。延伸阅读mise oci run 命令参考 — 本文对应的官方 CLI 参考页mise oci SUBCOMMAND— OCI 子命令总览Building and running OCI images — 构建、分层、[oci]配置、推送与多架构的完整指南全局标志与参数语法 — 所有 mise 命令共用的全局选项【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/mise创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 mise oci run 实战指南：从 mise.toml 构建容器镜像并运行命令
mise oci run 实战指南从 mise.toml 构建容器镜像并运行命令【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/misemise oci run是 mise 实验性 OCI 子命令体系中构建 运行的一站式入口它基于当前项目的 mise.toml 构建一个 OCI 镜像并借助本机 podman / docker 引擎在容器内执行命令stdin/stdout/stderr 直接继承。读完本文你将掌握mise oci run的完整参数语义、引擎选择与镜像装载原理、默认清理机制以及复用既有镜像布局的实战技巧从而把声明式工具环境无缝封装进可运行的容器。命令概览一次调用完成 build runmise oci run等价于先执行mise oci build、再执行docker run/podman run。其完整用法为mise oci run [FLAGS] [-- CMD]…命令位于mise oci SUBCOMMAND之下与build、push并列三者分别负责生成 OCI 布局构建并运行构建并推送见 docs/dev-tools/mise-oci.md 中的总览表。核心源码在 src/cli/oci/run.rsRun::run()src/cli/oci/run.rs#L110-L221依次完成参数校验、引擎探测、镜像构建/复用、镜像装载、引擎run调用与清理。前置条件命令标注为experimental需要同时满足开启实验特性mise settings experimentaltrue持久化或按次调用MISE_EXPERIMENTAL1 mise oci run …。源码中由Settings::get().ensure_experimental(mise oci run)?src/cli/oci/run.rs#L111强制校验。本机存在容器引擎podman或docker二者至少其一。参数与标志完整参考参数参数说明[-- CMD]…--之后为要在容器内执行的命令及其参数即mise oci run [FLAGS] -- cmd [args...]标志标志说明--engine ENGINE容器引擎auto默认优先 podman、podman、docker--from FROM构建时的基础镜像引用与--image-dir互斥时被忽略--image-dir IMAGE_DIR复用已构建好的 OCI 镜像布局跳过构建步骤必须包含index.json--include-global同时纳入全局/系统配置中的工具默认仅项目配置细节见mise oci build --help--keep运行结束后保留引擎存储中的镜像默认清理见下文生命周期--mount-point MOUNT_POINT覆盖镜像内工具安装挂载点与--image-dir互斥--no-mise不把 mise 二进制嵌入镜像与--image-dir互斥--owner UID[:GID]构建时赋予每个 tar 条目所有者的 UID[:GID]与--image-dir冲突覆盖[oci].user_id/[oci].group_id默认0:0省略 GID 时取 UID。只影响文件所有权镜像的USER指令由[oci].user控制--volume HOST:CONTAINER绑定挂载主机路径可重复格式HOST:CONTAINER[:MODE]。注意没有-v短标志因为 mise 保留-v给--verbose请用--volume或--mount-e, --env KEYVAL设置容器环境变量可重复-i, --interactive交互式运行向引擎传递-i-t, --tty分配 TTY向引擎传递-t-w, --workdir WORKDIR容器内工作目录-h, --help打印帮助其中--engine的定义见 src/cli/oci/run.rs#L102-L107 的Engine枚举--volume在源码中使用alias mountsrc/cli/oci/run.rs#L77因此--mount也可作为等价写法。三个开箱即用的示例1. 交互式进入容器 shellmise oci run -it -- bash构建当前 mise.toml 对应的镜像后以交互式 TTY 方式进入 bash。2. 一次性命令环境变量 挂载 工作目录mise oci run -e DEBUG1 --volume $PWD:/work -w /work -- npm test把当前目录挂载到容器内/work、设置DEBUG1、将工作目录切到/work执行npm test。注意这里--volume不能缩写为-v。3. 复用已构建的镜像布局跳过构建mise oci build -o ./img mise oci run --image-dir ./img -- node -e console.log(process.version)先用mise oci build -o ./img产出 OCI 布局再通过--image-dir ./img直接复用适合反复运行同一镜像做多次实验。mise-oci 总指南中的快速开始也推荐了同样的组合docs/dev-tools/mise-oci.mdmise oci build -o ./mise-oci mise oci run --image-dir ./mise-oci -- node --version引擎选择与镜像装载原理mise oci run在auto模式下优先选择 podman其次是 docker两者都不可用时直接报错src/cli/oci/run.rs#L224-L249--engine podman要求 PATH 中存在podman否则报错--engine docker要求 PATH 中存在docker否则报错--engine auto先探测podman再探测docker都没有则提示安装二者之一。装载方式随引擎不同而不同src/cli/oci/run.rs#L267-L308podman原生支持 OCI 布局mise 执行podman pull --quiet oci:dir直接拉取本地布局--quiet输出恰好是镜像 IDmise 捕获该 ID 作为后续podman run的引用。源码注释特别说明不依赖podman tag因为 tag 需要镜像名/ID 而非 transport 引用且镜像名随 podman 版本浮动捕获pull --quiet输出的镜像 ID 跨版本更稳定。dockermise 通过docker load把布局以 docker-archive 流式灌入 daemon。为避免并发调用互相踩踏镜像标签按进程 ID 纳秒时间戳生成mise-oci:run-pid-nanos见 src/cli/oci/run.rs#L295-L302这样两次并发的mise oci run不会因共享mise-oci:run标签而在容器启动前互相覆盖镜像。最终执行的等价命令为engine run [--rm] [-i] [-t] [-e KV]... [-v HOST:CONTAINER]... [-w DIR] image-ref cmd...参数透传逻辑见 src/cli/oci/run.rs#L160-L189。生命周期与默认清理机制mise oci run默认在命令退出后执行双重清理src/cli/oci/run.rs#L191-L210向引擎传--rm运行结束即删除容器主动调用engine rmi --force image-ref删除装载进引擎存储的镜像避免重复调用在 podman/docker 存储中累积镜像。也就是说默认情况下docker run --rm只删容器、不删镜像mise 补上了镜像清理这一步反复执行mise oci run不会让引擎存储越积越多。rmi失败例如镜像正被其他并发运行占用不会导致整体命令失败仅记入 debug 日志。若希望保留镜像docker 下标签为mise-oci:run-*podman 下为拉取的镜像 ID传--keep即可。另外构建过程产生的临时布局目录存放在TempDir中前缀mise-oci-run-随TempDir析构自动删除——GB 级的工具层不会残留在 /tmp 中src/cli/oci/run.rs#L130-L152。参数校验与互斥约束参数优先于引擎探测源码先校验参数再探测引擎因此--image-dir指向的目录若缺少index.json不符合 OCI 布局结构会先于引擎缺失报错提示does not look like an OCI image layout (missing index.json)src/cli/oci/run.rs#L113-L121。--image-dir与构建类参数互斥--from、--mount-point、--no-mise、--owner、--include-global均不能与--image-dir同时使用src/cli/oci/run.rs#L38因为复用既有布局时不存在构建动作。与mise oci build/mise oci push的分工命令职责mise oci build把 mise.toml 变成磁盘上的 OCI 镜像布局每个工具独立成层mise oci run构建或复用镜像并在 podman/docker 中运行命令mise oci push构建或复用镜像并用 mise 内置的 registry 客户端推送mise oci run关注本地执行验证它需要一个容器引擎且构建用的工具必须是主机二进制Linux 主机、目标架构一致。如需发布镜像则应使用mise oci push无需 docker/podman仅需 registry 凭据。mise oci run自身不依赖任何 registry——装载发生在本地引擎中。二者共享的构建层细节layering、[oci]配置段、[bootstrap]/[dotfiles]支持、环境变量组装顺序、可复现性等见 docs/dev-tools/mise-oci.md。使用前提与限制实验性 API行为、标志和输出布局在后续版本可能变化升级 mise 后建议查看mise oci run --help。主机平台约束镜像内容是主机原生二进制在 macOS/Windows 上构建出的镜像虽标记为 linux但内部二进制仍是宿主机架构在容器内会报Exec format error应在 Linux 主机或 Linux 开发容器中构建与运行。引擎必需mise 没有内置容器运行时mise oci run必须依赖 podman 或 dockermise oci push则无需任何外部工具。环境变量中的机密写入[env]的值含.env解析结果会进入镜像 config JSON可能被docker inspect读取运行时机密请通过-e、secret mount 或编排器注入。延伸阅读mise oci run 命令参考 — 本文对应的官方 CLI 参考页mise oci SUBCOMMAND— OCI 子命令总览Building and running OCI images — 构建、分层、[oci]配置、推送与多架构的完整指南全局标志与参数语法 — 所有 mise 命令共用的全局选项【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/mise创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考