Cube Sandbox

简体中文

English

简体中文

English

Appearance

什么是文件系统、镜像与可写层 ​

一句话定义 ​

在 CubeSandbox 里，环境的“文件世界”不是一个单层概念，而是至少由四层抽象构成：

  • 镜像（Image）：环境输入
  • 根文件系统（Root Filesystem / rootfs）：运行基础内容
  • Template：可发布母版
  • 可写层（Writable Layer）：实例级差异状态

很多对 CubeSandbox 的误解，都来自把这四层混成“同一个东西”。

为什么必须把文件系统概念分层 ​

如果不分层，你会很难回答这些问题：

  • 为什么可以从 OCI 镜像制作 Template？
  • 为什么两个 Sandbox 能共享基础环境，却不能共享彼此运行中的文件改动？
  • 为什么模板制作和实例创建是两个阶段？
  • 为什么实例既像“从模板复制出来”，又还能拥有自己的独立文件状态？

这些问题的答案都指向同一个事实：

CubeSandbox 不是把“一个镜像直接跑起来”，而是在管理一个分层环境系统。

什么是镜像（Image） ​

定义 ​

镜像是构建环境的输入材料。

它通常描述：

  • 需要哪些文件
  • 需要哪些依赖
  • 初始目录结构是什么
  • 基础用户态环境如何组成

在 CubeSandbox 中的角色 ​

CubeSandbox 常常从 OCI 镜像开始构建环境，但镜像本身不是最终交付对象。

更准确地说，镜像回答的是：

“这个环境的静态内容从哪里来？”

而不是：

“这个环境如何被高性能、强隔离地交付给用户？”

为什么镜像不是平台概念终点 ​

镜像非常重要，但它还不具备：

  • Guest 运行状态
  • 平台探针语义
  • 可复用快照状态
  • 统一发布对象身份

所以镜像只是起点。

什么是根文件系统（rootfs） ​

定义 ​

根文件系统是实例或模板在 Guest 内部看到的基础文件内容集合。

它比“镜像”更接近实际运行环境，因为它已经是一个可被运行时使用的文件系统基础。

它解决什么问题 ​

镜像往往是分发格式；rootfs 更接近运行格式。

换句话说：

  • 镜像描述怎么分发环境
  • rootfs 描述实例启动时到底能看到哪些文件

为什么 rootfs 不是完整环境 ​

即便有了 rootfs，也不等于已经有完整 Sandbox。

因为一个完整环境还需要：

  • Guest 内核
  • 运行时状态
  • 网络配置
  • 实例元数据
  • 可写层与生命周期状态

所以 rootfs 是环境基础，但不是环境全貌。

什么是 Template 在文件系统层面的意义 ​

Template 可以理解成“以 rootfs 为基础，再叠加可复用运行准备结果后的平台母版”。

从文件系统视角看，它至少意味着两件事：

  1. 基础环境已经被整理成可复用母版
  2. 后续实例创建时可以共享这份基础，而不必重新构造整套环境

所以 Template 不是简单“另一个文件系统格式”，而是把文件系统基础、运行状态和平台元数据组织成一个可发布对象。

什么是可写层（Writable Layer） ​

定义 ​

可写层是 Sandbox 实例级的可变文件状态。

它承载的是这个实例在运行过程中发生的文件系统差异，例如：

  • 新建文件
  • 修改配置
  • 下载依赖
  • 写入工作目录
  • 生成临时结果

为什么它必须是实例级的 ​

如果多个 Sandbox 直接共享可写状态，会立即出现问题：

  • 一个实例改文件会污染另一个实例
  • 同一模板无法稳定复用
  • 实例间缺乏边界
  • 回收与问题定位会极其困难

因此 CubeSandbox 必须做到：

共享基础，不共享差异。

可写层就是这个“差异层”。

最核心的分层关系 ​

你可以把这四层关系记成一句话：

  • 镜像提供原材料
  • rootfs 提供运行基础
  • Template 提供可复用母版
  • 可写层提供实例差异

这是理解 CubeSandbox 文件系统模型最重要的主线。

为什么这套分层对性能和密度很关键 ​

CubeSandbox 的目标不是让每个实例都拥有一份完全独立、从零复制的完整环境，而是：

  • 尽可能共享基础层
  • 尽可能把差异限制在实例级可写层
  • 在安全边界成立的前提下最大化复用

这会直接影响两个关键指标：

1. 存储效率 ​

共享基础意味着不必为每个实例复制整套环境内容。

2. 内存和启动效率 ​

当系统在文件系统和运行状态上都能良好分层时，实例创建就更接近“挂载差异层并恢复状态”，而不是“现场拼装新系统”。

为什么“镜像 -> 模板 -> 实例”是三段而不是一步 ​

这是 CubeSandbox 设计最值得理解的一点。

第一步：镜像到基础环境 ​

系统先从镜像得到基础内容。

第二步：基础环境到模板 ​

系统再把基础内容预热、固化、组织成可复用 Template。

第三步：模板到实例 ​

系统最后在共享基础之上，为每个 Sandbox 附加自己的实例差异状态。

这三步分别解决：

  • 输入来源
  • 母版复用
  • 实例个体化

如果把它们压成一步，系统很难同时获得高性能、高密度与高可治理性。

为什么文件系统概念和快照概念紧密相连 ​

文件系统分层主要解决“静态和实例差异怎么组织”； 快照机制主要解决“运行状态怎么复用”。

两者合在一起，才形成完整的极速交付模型：

  • 文件系统共享基础
  • 可写层承接差异
  • Snapshot 复用运行准备状态

所以当你听到“热启动很快”，不要只想到内存快照，也要想到背后的文件系统分层。

为什么文件系统概念和安全概念也有关系 ​

文件系统不仅关乎性能，还关乎边界。

例如：

  • 实例是否能看到其它实例的状态
  • 实例修改是否会污染母版
  • 回收后差异状态是否被正确清理
  • Guest 内文件视图是否严格限制在实例边界内

所以“分层文件系统”不仅是资源优化问题，也是隔离与治理问题。

常见误解 ​

误解一：Template 就是一份 rootfs 归档 ​

不对。

rootfs 是文件基础；Template 是平台母版对象，往往还包含运行状态与发布语义。

误解二：镜像和模板只是名字不同 ​

不对。

镜像偏输入分发；模板偏平台复用与交付。

误解三：可写层只是一个小优化 ​

不对。

可写层是实例差异边界得以成立的核心抽象之一。如果没有它，模板复用和实例隔离都会变得混乱。

运维和平台设计最该关心什么 ​

你在实际工作中最应该关注这四个判断：

  1. 哪些层是共享基础，哪些层是实例差异。
  2. 镜像、模板、rootfs 的职责是否被混用。
  3. 实例回收是否真正清理了可写层状态。
  4. 环境变更到底应该落在镜像、模板还是实例层。

和相关文档的关系 ​

下一步 ​

理解了环境内容和状态如何分层之后，最后一个必须讲透的概念就是：

CubeSandbox 到底隔离了什么、没隔离什么，它的安全边界到底在哪里？

下一章专门回答这个问题： 什么是安全边界与隔离模型。