容器 E06：Wasm 模块不是 Linux 容器进程
OCI 的制品分发与执行合约是不同层。10 的 descriptor/manifest可以组织非传统 rootfs 制品，但一个 Wasm 模块如何运行，依赖选定 Wasm runtime、WASI 版本与宿主接口，而不是把 .wasm 文件放进 OCI layer 就自动变成 Linux ELF 进程。
对比的是同一功能，不是同一执行模型
Linux probe-app 用 Python HTTP server，经内核的 socket 系统调用处理请求；WASI 提供的系统接口与实现能力随版本、runtime 而变。若要比较相同功能，必须选定能提供所需网络和文件能力的具体实现，明确编译目标和运行参数，再通过 OCI 制品把模块与运行配置交给支持该制品的 runtime；传统 runc 不会因此执行 Wasm 模块。正例在独立 VM 选定一个明确支持该 WASI 功能的 runtime，实现与 probe-app 可对照的简单响应；反例去掉相应 WASI 能力或选用不支持的 runtime，记录制品能被下载但无法执行的错误。版本与具体源码调用路径须按安装后实际情况核查。
版本冻结与最小功能定义、Linux 侧探针源码只提供对照输入；当前无 WASI runtime、模块编译器或 OCI runtime，所有 Wasm 构建/运行 `NOT_RUN`，不能将布局生成器成功当 Wasm 兼容通过。| 现象 | 检查 | 不可推出 |
|---|---|---|
| OCI blob 能下载 | media type 与执行 runtime | Wasm 已运行 |
| 同一 HTTP 功能 | 运行时提供的网络接口 | 两端都是 Linux 进程 |
| 模块启动失败 | WASI/宿主能力版本 | 镜像摘要必然错误 |
练习
- 先预测传统 runc 接到只有 Wasm 模块的 OCI 制品会怎样，在专用 VM 区分内容准备、执行 runtime 选择和 ABI 错误。
- 对一份简单状态读写功能，比较选定 WASI 版本是否支持必要文件和网络接口，并记录不能实现的部分，而非伪造同功能性能数据。
先修：10：OCI 制品、18：任务。下一篇：E07：懒加载。
系列总目录：从进程隔离到运行时与编排。
参考资料
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-10-01
容器 37：从源码到一次真实服务响应
本系列的每个对象都有不同寿命：源码树变化不等于已部署镜像改变；Pod 重建不等于数据卷重建；HTTP 请求成功也不能证明读写结果符合预期。综合实验必须让一条请求沿同一个 digest、容器 ID、Pod UID、宿主 PID、namespace/cgroup、网络路径和卷挂载回溯到源码，而不是把不同实验的截图接成故事。 只用一份 probe-app 从干净的实验目录取独立源码包并校验 SHA，固定基础镜像 digest，按13构建真实镜像，按12分发到受控 registry，再按26将 digest 部署到自建 kind 节点。通过 Service 访问 /identity 取得进程信息，通过 /state 写入一段最多 4096 字节的合成文本；从 Pod UID 到容器 ID、宿主 PID，查 namespace inode、cgroup、网络地址/路由及卷的 mountinfo，最后在同一卷上重建 Pod 后复读内容。每一步记录输入、时间、原始响应与校验值，不能从“yaml 配好了”跳到“持久化成功”。 正常案例需要请求 JSON 中的 PID 和 UID 与节点对象一一对...
2026-10-01
容器 00：运行中的容器究竟是哪一个进程
同一份应用文件在本机运行时只是进程；打包为镜像之后也不会自动变为“正在运行的容器”。要解释一次请求为什么失败，先区分磁盘上的制品、运行时创建的对象、内核里的进程和应用的就绪状态。这四者不处在同一层；把它们都叫“容器”会使故障归因失去落点。 从制品到请求 OCI Image Specification 约定索引、描述符、配置和层等制品表示；Runtime Specification 约定 bundle 配置与执行环境。镜像的摘要标识内容，不是 PID；bundle 描述将要执行的命令与隔离、挂载等参数，不是已经建立的内核对象。运行时准备根文件系统、进程配置，创建或加入 namespace、应用资源及权限约束，最后让内核执行程序。一个处于不同 namespace 的 Linux 进程仍与同机进程共享一个内核；VM 内的 Linux 容器共享 VM 的内核，而非桌面宿主内核。 实际排查时需要沿对象逐一核验：镜像引用解析到哪个 digest；运行时对象的 ID 是什么；运行程序在宿主侧 PID 是什么；/proc/<pid>/ns/* 指向哪些 inode；/proc/<...
2026-10-01
容器 10：OCI 镜像到底保存了什么
09已经能让自编探针作为进程退出，但无法用一个可分发制品重建其根文件系统。OCI 镜像表示的是若干内容寻址的字节和元数据，而非正在运行的进程。以这一区别为出发点读 `index.json`，比背一串 Docker 命令更容易定位“拿到的是哪个制品”。 从索引走到字节 本地 OCI image layout 的入口是 oci-layout 与 index.json。索引中的 descriptor 用 media type、digest、size 指向 manifest，可能列有平台信息；manifest 再指向 image config 与一组层。config 描述操作系统、架构、根文件系统的 diff_ids 及进程默认参数等；层可以是 tar gzip 的变更集。给定 sha256:<hex>，实际 blob 路径是 blobs/sha256/<hex>，应以文件真实字节核验 digest 和 size，不能只看 JSON 里字符串长得像摘要。 一个特别容易混淆的点是压缩层 descriptor 的 digest 与 config 中 DiffID：前者...
2026-10-01
容器 12：镜像拉取是下载还是解包
本地已知镜像的index、manifest 与 blob，接下来问另一台机器如何得到相同字节。Distribution Specification 约定 registry API；它不等于 Linux 的 mount、容器进程的 exec，也不保证客户端已把层成功解压成可运行的 rootfs。 引用解析和内容获取分开 客户端把名字/tag 交给 registry，商议清单媒体类型，读取 manifest 后根据 descriptor 的 digest 与 size 请求 config 和 layer blob。digest 绑定字节，tag 可重新指向另一 manifest；“我拉到了 tag”不能证明和上一次拉到的内容相同。Blob 下载成功仍需校验摘要、解压层、建立本机快照才能供运行时使用。认证失败应定位到 HTTP 挑战、凭据与仓库权限，缺失 blob 则应定位对应 digest 和 HTTP 返回，而非笼统说“网络不通”。不要将镜像 registry 的身份验证和镜像签名混为一谈。 引用如何落到确定的 manifest OCI Distribution Specifica...
2026-10-01
容器 15：同一镜像名称怎样指向多种 CPU 制品
同一 tag 不能让 x86 指令在 ARM CPU 上原生执行。10 的 index能够把 platform 描述符指向不同的 manifest：选择具体平台时，客户端取得对应的 config/layer 并执行该平台的程序。平台选择成功只是内容匹配；不保证内核 ABI、库或应用本身都可运行。 把构建和运行拆开 在本机生成两套平台元数据并不证明拥有两套机器码。原生构建、交叉编译与仿真构建分别对构建时使用的 CPU/用户空间提出不同条件；通过 QEMU user-mode 仿真运行的性能不能当作原生 ARM 性能。对解释型应用也不能因为 probe_app.py 是同一份文本就断言镜像完全相同：最终基础镜像中的 Python 二进制、库和平台标记仍可能不同。index manifest、每平台 manifest digest 和实际内核及 CPU 架构应一起保存。 一个名字会解析到哪个对象 OCI image-spec v1.1.1 的 image index 是高于单平台 manifest 的对象，其 manifests 数组包含描述符；每条 descriptor 可以带 pl...
2026-10-01
容器 17：OCI runtime 的 create 与 start 分别做什么
10 的镜像布局适于存储、传输与校验；OCI runtime 读取的入口却是 bundle，核心是 `config.json` 和 rootfs。把 manifest 文件直接交给 runc 并不能从镜像层自动得到已经展开的 rootfs。前篇09构造了局部的进程启动链路，这篇以规范而非教学实现重画边界。 生命周期为何拆成两段 OCI Runtime Specification v1.3.0 定义了 create、start、state、kill、delete 的状态与条件。create 必须按照 config.json 构造执行环境，但此时不执行用户指定程序；state 的 created 带有 Linux PID，却不等于应用开始响应。start 才使用户程序开始执行；程序退出后进入 stopped，满足删除前提后 delete 撤销运行时创建的资源。runtime 对象 ID、容器进程 PID、bundle 的绝对路径分别是三种字段；别用 ID 当 PID。即使 running，也仍需实际请求 /ready 才能讨论服务可用性。 bundle 与镜像不是两种叫法 OCI i...