opencontainers/image-spec
GitHub: opencontainers/image-spec
OCI容器镜像格式的官方规范文档,定义了跨平台容器镜像的标准结构和元数据格式。
Stars: 4193 | Forks: 818
# OCI 镜像格式规范

[](https://pkg.go.dev/github.com/opencontainers/image-spec)
OCI 镜像格式项目创建并维护软件交付容器镜像格式规范(OCI 镜像格式)。
**[规范可以在这里找到](spec.md)。**
本仓库还提供了 [Go 类型](specs-go)、[Blob 内验证工具和 JSON Schema](schema)。
Go 类型和验证应与当前的 Go 版本兼容;不支持早期的 Go 版本。
关于本组运作方式的更多文档:
- [行为准则][code-of-conduct]
- [路线图](#roadmap)
- [发布版本](RELEASES.md)
## 运行 OCI 镜像
OCI 镜像格式的合作项目是 [OCI Runtime Spec 项目](https://github.com/opencontainers/runtime-spec)。
Runtime Specification 概述了如何运行一个解压到磁盘上的 “[文件系统包](https://github.com/opencontainers/runtime-spec/blob/main/bundle.md)”。
在高层次上,OCI 实现会下载一个 OCI 镜像,然后将其解压为一个 OCI Runtime 文件系统包。
此时,OCI Runtime 包将由 OCI Runtime 运行。
整个工作流程支持用户期望从 Docker 和 rkt 等容器引擎获得的用户体验(UX):主要是无需额外参数即可运行镜像的能力:
- docker run example.com/org/app:v1.0.0
- rkt run example.com/org/app,version=v1.0.0
为了支持这种用户体验,OCI 镜像格式包含了在目标平台上启动应用程序所需的足够信息(例如命令、参数、环境变量等)。
## 分发 OCI 镜像
[OCI Distribution Spec 项目](https://github.com/opencontainers/distribution-spec/)定义了一个 API 协议,以促进和标准化内容的分发。
该 API 包括支持向符合 OCI 标准的仓库推送和拉取 OCI 镜像。
## 常见问题解答
**问:AppC 或 Docker 镜像格式会怎样?**
答:现有格式可以继续根据需要作为技术的试验场。
OCI 镜像格式项目致力于提供可靠的开源规范,可在不同工具间共享,并能保持数年甚至数十年的兼容性;就像 deb 和 rpm 格式那样。
在 [OCI 网站](https://www.opencontainers.org/faq)上查找更多 [常见问题解答]。
## 路线图
[GitHub 里程碑](https://github.com/opencontainers/image-spec/milestones)规划了未来改进的路径。
### 讨论你的设计
本项目欢迎提交,但请让所有人知道你正在做什么。
在对本规范进行重大更改之前,请发送邮件至[邮件列表](#mailing-list)讨论你计划做什么。
这让大家有机会验证设计,有助于防止工作重复,并确保想法合适。
这也保证了在编写代码之前设计是合理的;GitHub pull-request 不是进行高层次讨论的地方。
错别字和语法错误可以直接提交 pull-request。
如有疑问,请先在[邮件列表](#mailing-list)上讨论。
### 会议
有关 OCI 贡献者和维护者会议日程的最新信息,请参阅 [OCI org 仓库 README](https://github.com/opencontainers/org#meetings)。
你还可以找到所有既往会议的会议议程和纪要链接。
### 邮件列表
你可以在 [Google Groups](https://groups.google.com/a/opencontainers.org/forum/#!forum/dev) 上订阅并加入邮件列表。
### Markdown 风格
为了保持 Open Container 规范中 Markdown 文件的一致性,所有文件的格式应为一行一句。
这解决了两件事:使使用 git 进行差异比较更容易,并解决了关于换行长度的争论。
例如,本段落在 Markdown 源代码中将跨越三行。
### Git 提交
#### 签署你的工作
签署是补丁说明末尾的一行简单内容,证明是你编写了它,或者 otherwise 有权将其作为开源补丁传递。
规则非常简单:如果你能认证以下内容(来自 [developercertificate.org](https://developercertificate.org/)):
```
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
660 York Street, Suite 102,
San Francisco, CA 94110 USA
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
```
那么你只需在每个 git commit 消息中添加一行:
```
Signed-off-by: Joe Smith
```
使用你的真实姓名(抱歉,不接受化名或匿名贡献。)
你可以通过 `git commit -s` 在创建 git commit 时添加签署。
### Commit 风格
简单的内务整理,以保持干净的 git 历史。
在[如何编写 Git Commit 消息](https://chris.beams.io/posts/git-commit/)或 [`git-commit(1)`](https://git-scm.com/docs/git-commit)的讨论部分阅读更多内容。
1. 使用空行将主题与正文分开
2. 将主题行限制在 50 个字符以内
3. 主题行首字母大写
4. 不要以句号结束主题行
5. 在主题行中使用祈使语气
6. 正文在 72 个字符处换行
7. 使用正文解释“做什么”和“为什么”,而不是“怎么做”
- 如果有重要/有用/必要的对话或信息,请复制或包含参考
8. 在可能的情况下,在主题中使用一个关键字来界定更改范围(例如 “README: ...”,“runtime: ...”)
标签:Docker, EVTX分析, Go语言, JSON Schema, NIDS, Web截图, 互操作性, 基础设施, 安全防御评估, 容器化, 容器安全, 容器镜像, 开放容器倡议, 日志审计, 标准规范, 程序破解, 虚拟化技术, 软件供应链, 运行时规范, 镜像仓库, 镜像分发, 镜像构建, 镜像格式, 防御加固