OCI 镜像格式规范

OCI 镜像格式项目创建并维护软件容器镜像格式规范（OCI 镜像格式）。

规范可在此处找到。

该存储库还提供 Go 类型、内部 blob 验证工具和 JSON Schema。 Go 类型和验证应与当前 Go 版本兼容；不支持早期 Go 版本。

关于该组织如何运作的其他文档：

• 行为准则
• 路线图
• 发布
• 项目文档

运行 OCI 镜像

OCI 镜像格式的合作项目是 OCI 运行时规范项目。 运行时规范概述了如何运行在磁盘上解包的"文件系统包"。 在高层次上，OCI 实现会下载 OCI 镜像，然后将该镜像解包成 OCI 运行时文件系统包。 此时，OCI 运行时包将由 OCI 运行时运行。

整个工作流程支持用户从 Docker 和 rkt 等容器引擎中所期望的用户体验：主要是无需额外参数即可运行镜像的能力：

• docker run example.com/org/app:v1.0.0
• rkt run example.com/org/app,version=v1.0.0

为了支持这种用户体验，OCI 镜像格式包含足够的信息来在目标平台上启动应用程序（例如命令、参数、环境变量等）。

分发 OCI 镜像

OCI 分发规范项目定义了一个 API 协议，以促进和标准化内容的分发。 该 API 包括支持推送和拉取 OCI 镜像到符合 OCI 的注册表。

常见问题

问：AppC 或 Docker 镜像格式会怎样？

答：现有格式可以继续作为技术的试验场，根据需要使用。 OCI 镜像格式项目致力于提供一个可靠的开放规范，可以在不同工具之间共享，并可以在多年或几十年内保持兼容性；就像 deb 和 rpm 格式一样。

在 OCI 网站上可以找到更多常见问题。

路线图

GitHub 里程碑展示了未来改进的路径。

贡献

规范的开发在 GitHub 上进行。 问题用于报告 bug 和可执行项目，更长的讨论可以在邮件列表上进行。

规范和代码采用 Apache 2.0 许可证，可在本存储库的 LICENSE 文件中找到。

讨论你的设计

项目欢迎提交，但请让每个人都知道你在做什么。

在对本规范进行重大更改之前，请发送邮件到邮件列表讨论你的计划。 这让每个人都有机会验证设计，有助于防止重复工作，并确保想法合理。 它还保证在编写代码之前设计是合理的；GitHub 拉取请求不是进行高层次讨论的地方。

拼写错误和语法错误可以直接提交拉取请求。 如有疑问，请从邮件列表开始。

会议

请查看 OCI org 存储库 README以获取最新的 OCI 贡献者和维护者会议安排信息。 你还可以找到所有以前会议的议程和会议记录的链接。

邮件列表

你可以在 Google Groups 上订阅并加入邮件列表。

Markdown 风格

为了保持 Open Container 规范中 Markdown 文件的一致性，所有文件应该每句话占一行格式化。 这解决了两个问题：它使得 git 比较更容易，并解决了关于换行长度的争论。 例如，这段落在 Markdown 源文件中将跨越三行。

Git 提交

签署你的工作

签名是补丁说明末尾的简单一行，证明你编写了它或有权将其作为开源补丁传递。 规则很简单：如果你能证明以下内容（来自 developercertificate.org）：

开发者原创证书
版本 1.1

版权所有 (C) 2004, 2006 The Linux Foundation 及其贡献者。
660 York Street, Suite 102,
San Francisco, CA 94110 USA

每个人都被允许复制和分发本许可证文档的逐字副本，
但不允许修改它。


开发者原创证书 1.1

通过对本项目做出贡献，我证明：

(a) 该贡献完全或部分由我创作，我有权根据文件中
    指示的开源许可证提交它；或

(b) 该贡献基于我所知的先前工作，该工作受适当的
    开源许可证保护，我有权根据相同的开源许可证
    （除非我被允许根据不同的许可证提交）提交该
    工作及修改，如文件中所示；或

(c) 该贡献直接由某个证明了 (a)、(b) 或 (c) 的其他
    人提供给我，我没有对其进行修改。

(d) 我理解并同意本项目和贡献是公开的，贡献记录
    （包括我提交的所有个人信息，包括我的签名）
    将无限期保留，并可能与本项目或涉及的开源
    许可证一致地重新分发。

然后你只需在每个 git 提交消息中添加一行：

Signed-off-by: Joe Smith <joe@gmail.com>

使用你的真实姓名（抱歉，不允许使用假名或匿名贡献）。

你可以在创建 git 提交时通过 git commit -s 添加签名。

提交风格

为了保持 git 历史整洁的简单管理。 阅读更多关于如何写 Git 提交消息或 git-commit(1) 的讨论部分。

1. 用空行将主题与正文分开
2. 将主题行限制在 50 个字符以内
3. 主题行首字母大写
4. 不要用句号结束主题行
5. 在主题行中使用祈使语气
6. 将正文换行在 72 个字符处
7. 使用正文解释是什么和为什么而不是如何
   • 如果有重要/有用/必要的对话或信息，复制或包含引用
8. 如果可能，在主题中使用一个关键词来限定更改范围（例如 "README: ..."、"runtime: ..."）