opencontainers/runtime-spec

# Open Container Initiative Runtime 规范 [](https://github.com/opencontainers/runtime-spec/actions?query=workflow%3Abuild) [Open Container Initiative][oci] 致力于为操作系统进程和应用容器制定标准规范。 该规范可以在[这里](spec.md)找到。 ## 目录 关于该小组如何运作的更多文档： - [行为准则][code-of-conduct] - [风格与约定](style.md) - [实现](implementations.md) - [发布](RELEASES.md) - [章程][charter] ## 用例 为了给用户提供背景信息，以下部分给出了规范中每个部分的示例用例。 ### 应用 Bundle 构建器 应用 bundle 构建器可以创建一个 [bundle](bundle.md) 目录，其中包含将应用作为容器启动所需的所有文件。 该 bundle 包含一个 OCI [配置文件](config.md)，构建器可以在其中指定与主机无关的细节（例如[要启动的可执行文件](config.md#process)）以及与主机相关的设置（例如 [mount](config.md#mounts) 位置、[hook](config.md#posix-platform-hooks) 路径、Linux [namespaces](config-linux.md#namespaces) 和 [cgroups](config-linux.md#control-groups)）。 由于配置包含特定于主机的设置，因此在两个主机之间复制的应用 bundle 目录可能需要调整配置。 ### Hook 开发者 [Hook](config.md#posix-platform-hooks) 开发者可以通过外部应用介入容器的生命周期，从而扩展符合 OCI 标准的 runtime 的功能。 示例用例包括复杂的网络配置、卷垃圾回收等。 ### Runtime 开发者 Runtime 开发者可以构建 runtime 实现，以便在特定平台上运行符合 OCI 标准的 bundle 和容器配置（包含底层的操作系统和特定于主机的详细信息）。 ### 讨论你的设计 本项目欢迎提交内容，但请让大家知道你正在开发什么。 在对本规范进行重大修改之前，请向[邮件列表](#mailing-list)发送邮件，讨论你计划做什么。 这可以让每个人都有机会验证设计，有助于防止重复劳动，并确保该想法符合规范。 它还能确保在编写代码之前设计是合理的；GitHub 的 pull-request 并不适合进行高层级的讨论。 拼写错误和语法错误可以直接提交 pull-request。 如果有疑问，请先在[邮件列表](#mailing-list)中发起讨论。 ### 会议 请参阅 [OCI 组织仓库的 README](https://github.com/opencontainers/org#meetings)，以获取有关 OCI 贡献者和维护者会议日程的最新信息。你还可以找到所有历次会议的议程链接和会议纪要。 ### 邮件列表 ### 聊天 OCI 的讨论在以下聊天室中进行，这些聊天室都已经互相桥接： ### Git 提交 #### 签署你的工作 签名 (sign-off) 是位于补丁说明末尾的一行简单文字，用于证明是你编写了该代码，或者你有权将其作为开源补丁传递。 规则非常简单：如果你能保证以下内容（来自 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 时通过 `git commit -s` 添加签名。 #### 提交风格 为了保持清晰的 git 历史的简单维护规则。 请阅读[如何编写 Git Commit 消息][how-to-git-commit]或 [git-commit(1)][git-commit.1] 的 Discussion 章节，了解更多信息。 1. 使用空行将主题与正文分隔开 2. 主题行限制在 50 个字符以内 3. 主题行首字母大写 4. 主题行不要以句号结尾 5. 在主题行中使用祈使语气 6. 正文每行换行控制在 72 个字符 7. 使用正文来解释“是什么”和“为什么”，而不是“怎么做” * 如果有重要/有用/必要的对话或信息，请复制或包含参考链接 8. 如果可能，在主题中使用一个关键字来界定更改范围（例如 "README: ...", "runtime: ..."）

标签：Cutter, EVTX分析, 防御加固