容器运行时云原生网络【免费下载链接】rkt[Project ended] rkt is a pod-native container engine for Linux. It is composable, secure, and built on standards.项目地址https://gitcode.com/gh_mirrors/rk/rkt点击查看免费下载rkt 的镜像处理历来以 appc 规范下的 ACIApplication Container Image为核心本提案系统梳理了 rkt 内部三个镜像子系统fetching、image store、tree store的现状并规划了在不移除 ACI 支持的前提下通过 CIMD 分发点、基于引用的镜像存储、传输处理器与 tree store OCI 适配四个步骤逐步实现 OCI 镜像原生支持的技术路线。阅读本文后你将理解 rkt 的镜像格式转换链路、CIMD URI 的完整语法与各分发点实现、镜像存储对 SHA-512 的依赖及其改造方向以及该路线图背后的兼容性风险。背景rkt 与 ACI/OCI 两种镜像规范rkt 当前实现的是 appc 规范因此内部依赖 ACIApplication Container Image这一镜像格式。而 OCIOpen Container Initiative 定义了一套独立规范下的全新镜像格式它与 rkt 内部基于 ACI 的镜像处理方式差异显著——OCI 镜像以 manifest 中的 layers 数组表达依赖而 ACI 依赖图则由 appc 规范的依赖关系决定。从仓库源码可以确认rkt 的镜像处理链路确实被划分成三个独立子系统fetching拉取负责下载各种类型的镜像。非 ACI 镜像Docker、OCI通过委托 docker2aci 中的docker2aci.ConvertRemoteRepo(registryURL, config)调用这是当前所有 Docker/OCI 镜像进入 rkt 的唯一转换入口。image store镜像存储负责持久化和管理已下载的镜像由两部分组成存储镜像文件 blob 的目录树通常位于/var/lib/rkt/cas/blob以及存储镜像元数据的嵌入式 SQL 数据库通常位于/var/lib/rkt/cas/db/ql.db。实现位于github.com/rkt/rkt/store/imagestore包。在 store/imagestore/store.go 中可以看到blob与imageManifest两个 diskv 存储区以及sha512-前缀的 key 生成逻辑。tree store树存储由于 ACI 镜像之间的依赖关系按照 appc 规范形成一个有向无环图DAG这些镜像会被预渲染到名为 tree store 缓存的目录中。若启用了 overlay 文件系统预渲染结果将作为 pod 根文件系统的lowerdir使用。实现位于github.com/rkt/rkt/store/treestore包源码可见 store/treestore/tree.go 中的Store结构体通过acirenderer依赖图渲染 ACI 镜像树。rkt 内部镜像的完整生命周期记录在 架构文档 的 image lifecycle 章节中。OCI 与 appc 在镜像处理上的关键差异原提案给出了一张对比表概括两种格式在镜像处理层面的核心区别方面OCIACI依赖image manifest 中的 layers 数组基于 appc 规范的依赖图DAG哈希算法可能支持多种算法SHA-256 为首选固定使用 SHA-512正是这两点差异直接决定了后续路线图中镜像存储改造哈希算法扩展与 tree store 适配依赖渲染方式的必要性。目标与非目标原生支持 OCI保留 ACI随着 appc 规范的弃用rkt 现有内部架构不再占优。当前 rkt 已能支持 ACI、Docker、OCI 三类镜像但通过docker2aci将 OCI 转换为 ACI 的这一步显得多余它引入了 CPU 和 I/O 开销且受限于两种格式之间的语义差异。因此本提案的目标是在 rkt 内部原生支持 OCI 镜像与 ACI 并列共存rkt 会继续支持 ACI 镜像格式及其分发机制目前没有移除该支持的计划。非目标是 OCI 运行时规范runtime-spec的实现——即在 rkt 内部直接运行 OCI 容器这一话题由独立工作项跟踪。为实现原生 OCI 支持提案明确了四个必要步骤下文逐一展开。第一步分发点Distribution Points——CIMD 统一镜像定位语法rkt 历史上依靠镜像名称及围绕名称的启发式规则来判断镜像格式类型appc、Docker、OCI。分发点distribution point概念引入了一种 URI 语法能够唯一指向不同镜像格式并携带必要的元数据文件位置、来源 URL、版本等。CIMD URI 语法分发点选择了cimdContainer Image Distribution容器镜像分发作为 URI scheme。其通用形式为cimd:DISTTYPE:vuint32(VERSION):DATAcimd容器镜像分发 schemeDISTTYPE分发类型vVERSION分发类型格式的版本号uint32DATA具体的分发数据opaque 部分与 query 参数。在源码层面pkg/distribution/cimd.go 的parseCIMD用strings.SplitN(u.Opaque, :, 3)将 opaque 数据切分为类型、版本和数据三段并校验 scheme 必须为cimdNewCIMDString则负责拼装cimd:Type:vVersion:Data形式的字符串。rkt 当前支持的三种 CIMD 分发点原提案给出了当前支持的三种分发点名称示例appccimd:appc:v0:coreos.com/etcd?versionv3.0.3oslinuxarchamd64ACIArchivecimd:aci-archive:v0:file%3A%2F%2Fabsolute%2Fpath%2Fto%2FfileDockercimd:docker:v0:busyboxappc 分发点间接分发点使用 appc 镜像发现机制格式为cimd:appc:v0:name?label01....label02....label 值必须经过 Query 转义。实现见 pkg/distribution/appc.go其中NewAppc将 CIMD 数据与 query 参数重新拼接成 appc 发现字符串交给discovery.NewAppFromString解析NewAppcFromApp反向构造时会对 URI 进行 query 排序归一化purell.FlagSortQuery使同一镜像的不同书写形式可以稳定比较。ACIArchive 分发点直接分发点直接定义镜像的最终位置格式为cimd:aci-archive:v0:ArchiveURL?query...ArchiveURL 必须 Query 转义例如cimd:aci-archive:v0:file%3A%2F%2Fabsolute%2Fpath%2Fto%2Ffile与cimd:aci-archive:v0:https%3A%2F%2Fexample.com%2Fapp.aci。实现见 pkg/distribution/aciarchive.goNewACIArchive对数据段做url.QueryUnescape后得到真正的传输 URLtransport URL可通过TransportURL()取出供底层传输层使用。Docker 分发点间接分发点使用 Docker registry其格式cimd:docker:v0:[REGISTRY_HOST[:REGISTRY_PORT]/]NAME[:TAG|DIGEST]与docker pull的镜像字符串格式一致。实现见 pkg/distribution/docker.goNewDocker委托 docker2aci 的ParseDockerURL解析镜像引用并维护simple用户友好简写与full补全默认值的完整引用两种表示。值得注意的默认值逻辑见SimpleDockerRef/FullDockerRef当使用默认 registryregistry-1.docker.io时会省略 registry 前缀与library/仓库前缀tag 默认latest。分发点的注册与解析机制pkg/distribution/distribution.go 定义了Distribution接口包含三个方法CIMD()返回 CIMD URI 副本、String()返回用户友好表示、Equals()比较两个分发点是否等价。各分发点类型通过init()中的Register()注册到全局表Parse()/Get()负责从字符串或 URL 解析分发点遇到未知类型或畸形 URI 会返回错误。这一注册-解析机制是后续扩展cimd:oci的基础——新增分发点只需实现接口并注册。未来的 OCI 分发点原提案的 TODO 明确列出引入专用的远端cimd:oci分发点以及潜在的本地cimd:oci-layout分发点对应 OCI image-layout 规范。在配套设计文档 Documentation/devel/distribution-point.md 中对这两个未来分发点做了更详细的规划OCI 镜像分发间接OCI 镜像当前可从 Docker registry 获取未来 OCI 规范会定义从镜像名含 tag/label出发的自有分发方式OCI 镜像布局直接可从 OCI image layout 拉取镜像location 可指向单个文件归档、本地目录布局或远端目录布局示例格式如cimd:oci-image-layout:v0:file%3A%2F%2Fabsolute%2Fpath%2Fto%2Ffile?refrefname由于一个布局可含多个镜像通过 ref 选择而分发点只对应单个镜像故每个分发 URI 必须显式携带ref参数。cimd:oci预计会是cimd:oci-image-layout的上层间接分发点类似 appc 之于 ACIArchive 的关系。用户友好字符串与向后兼容CIMD URI 较长且复杂为便于用户在 CLI 中使用rkt 将输入镜像字符串映射为分发点 URI以维持旧的 ImageType 启发式判别的向后兼容详见 Documentation/devel/distribution-point.md 中的映射表appc 发现字符串、文件路径、file URL、http(s) URL、docker URI/URL 分别映射到对应 CIMD 分发点。解析与生成用户友好字符串的工作被放在 distribution 包之外使包的使用者能自行实现自己的友好字符串格式。第二步基于引用的镜像处理Reference Based Image Handling现有 image store 实现不支持多种镜像格式blob 镜像存储仅支持 SHA-512ql 支撑的 SQL 镜像存储 schema 也仅引用 ACI 镜像。为准备 OCI 原生支持需要以下改动将 CIMD URI 作为当前镜像存储的主键支持多种哈希算法当前仅支持 SHA-512OCI 额外需要 SHA-256 及潜在的其他算法重做数据库 schema以反映多镜像支持。这些判断与源码现状完全吻合。在 store/imagestore/store.go 中可见hashPrefix sha512-、lenHash sha512.Size等常量blob 的 key 由 SHA-512 哈希生成WriteACI写入时使用sha512.New()作为哈希器。而 store/imagestore/schema.go 中remote表以aciurl为主键、aciinfo表以blobkey为主键并带name/importtime/lastused/latest等字段全部围绕 ACI 语义建模且dbVersion当前为 7schema 的每次演进都依赖迁移语句和数据库备份机制backupDB保留 5 份备份。这解释了提案中不只是简单的 schema 变更而是侵入式 schema 与目录布局变更的风险判断。配套设计文档同时建议引入一个新的基于 Bolt 的 key/value 存储但当前共识是ql的替换可独立进行因此应作为 OCI 路线图的非目标。第三步传输处理器Transport Handlers目前 rkt 直接拉取远端 ACI 镜像或使用docker2aci代理非 ACI 镜像的拉取。由于缺少抽象层现有实现很难集成独立的拉取子系统。本步骤的提议是将拉取逻辑抽象为传输处理器transport handlers为各种镜像格式提供独立且可替换的拉取实现。这既是分发点设计文档中分发点与传输层分离思路的自然延伸例如 ACIArchive 分发点可调用 file、http、s3、bittorrent 等多种传输插件也为引入github.com/containers/image这类第三方库委托 OCI/Docker 拉取提供了抽象边界。当前状态设计文档与初版实现均已提出但处于非常早期阶段仅应作为启发参考TODO必须支持所有格式的远端拉取与本地磁盘拉取需确定最终设计需抽象现有 fetcher 逻辑以引入替代库。第四步tree store 对 OCI 的支持现有 tree store 实现仅用于渲染 ACI 镜像。要支持 OCI需要新的设计文档与初始实现以原型化解压 OCI 镜像及其依赖的流程。其难点在于 OCI 的依赖表达layers 数组与 ACI 的依赖图DAG不同渲染策略需重新设计——包括 overlay 文件系统下如何将 OCI 图层组装成 pod 根文件系统的lowerdir。此项工作的状态为尚未开始。风险分析向后兼容与回滚能力提案明确指出的最大顾虑是向后兼容性与回滚能力。上述改动不只是 ql 数据库的简单 schema 变更而是侵入式的 schema 和目录布局变更。结合源码可见image store 的迁移流程store/imagestore/store.go在检测到旧版本数据库时会先获取独占锁、备份数据库再执行迁移且非 root 用户执行迁移会被拒绝ErrDBUpdateNeedsRoot。任何新格式的引入都会沿着这条既有迁移路径放大风险一旦新版本写入新布局旧版本 rkt 将无法正确解读回滚需要额外的备份恢复机制。因此兼容性策略包括cimd:oci分发点的引入节奏、schema 迁移的多版本共存能力是本路线图落地前必须解决的首要问题。总结本路线图描绘了 rkt 从单一 ACI 内部格式 docker2aci 转换桥走向多格式原生并存的清晰路径以 CIMD 分发点统一镜像定位与引用第一步以引用化存储承载多哈希算法与多格式元数据第二步以传输处理器解耦各格式的拉取实现第三步以 tree store 适配覆盖 OCI 图层的根文件系统渲染第四步。每一环节都保留了 ACI 的完整支持与向后兼容边界而 OCI 运行时执行本身则被明确排除在范围之外。对于想要深入 rkt 镜像子系统的读者建议从 Documentation/devel/distribution-point.md分发点设计、store/imagestore/store.go 与 store/imagestore/schema.go存储现状、store/treestore/tree.go树渲染以及 rkt/image/dockerfetcher.go当前转换链入手。赞分享容器运行时云原生网络【免费下载链接】rkt[Project ended] rkt is a pod-native container engine for Linux. It is composable, secure, and built on standards.项目地址https://gitcode.com/gh_mirrors/rk/rkt点击查看免费下载相关推荐如何在DeepForge中创建自定义操作零基础开发者的完整指南如何在DeepForge中创建自定义操作零基础开发者的完整指南 DeepForge是一个现代化的深度学习开发环境允许开发者创建、管理和执行复杂的机器学习工作OCI镜像转换指南将现有镜像迁移到OCI标准格式OCI镜像转换指南将现有镜像迁移到OCI标准格式 OCI镜像格式作为容器技术的行业标准为容器镜像提供了统一、可互操作的规范。本指南将详细介绍如何将现有镜像迁云原生存储OCI镜像格式与Docker镜像的10个关键差异对比OCI镜像格式与Docker镜像的10个关键差异对比 想要理解容器技术的演进历程OCI镜像格式作为开放容器倡议的标准规范与传统的Docker镜像有着本质的区云原生存储上一篇vscode-web-visual-editor 设置项完全指南HTML可视化编辑器4个配置深度解读与最佳实践下一篇headlines.nvim 插件架构解析代码实现细节揭秘创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考