runC，一个轻量级的通用容器运行时，是一个命令行工具，用于根据开放容器倡议 (OCI) 规范生成和运行容器。这是简短版本。完整版本：由 Docker、Google、IBM、Microsoft、Red Hat 和许多其他合作伙伴创建的治理伞，旨在创建一个通用且标准化的运行时规范，其中包含容器运行时元素的可读规范文档，以及基于 Docker 贡献给 OCI 的代码的可用实现。它包括 libcontainer，这是最初在 Docker 引擎中使用的原始底层库接口，用于设置我们称为容器的操作系统构造。
鉴于 runC 是一个具有定期发布节奏的开源项目，您可以在 GitHub 上找到代码和相应的版本。如果您下载或构建 runC 二进制文件，您将拥有开始使用 runC 作为基于运行时规范元素的简单容器执行器所需的一切：一个 JSON 容器配置和一个根文件系统捆绑包。请注意，如果您安装了 Docker 1.11 或更高版本，您的系统也会自动安装 runC 的最新副本。它很可能被命名为 docker-runC 并安装在 /usr/bin 中，并且可以像任何正常的 runC 安装一样在 Docker 之外使用。
使用 runC 的优势
甚至在 OCI 和 runC 存在之前，许多核心 Docker 引擎开发人员都使用 runC 的前身 nsinit，它允许一个简化的入口点来运行和调试底层容器功能，而无需整个 Docker 守护进程接口的开销。现在 runC 已经存在，这绝对是一个持续的用例，特别是对于可能公开新的 Linux 隔离功能的人员。例如，使用 Linux Checkpoint/Restore In Userspace (CRIU) 项目的检查点/恢复功能首先通过 runC 提供，并且现在正准备添加到 runC 之上的 Docker 守护进程层。当然，随着 runC/OCI 扩展到 Linux 之外，对于其他操作系统 (OS) 隔离原语（例如 Solaris 区域或基于 Microsoft Windows 的容器）来说，情况也是如此，这两者都希望通过 OCI 运行时规范和 runC 实现获得功能。
除了操作系统层的新功能开发之外，runC 还是一个有用的调试平台，用于查找难以解决的错误，这些错误在整个 Docker 堆栈之上的容器进程中更难调试。
开始使用 runC 的挑战
开发人员可能已经习惯了使用整个 Docker 生态系统（包括使用 DockerHub（或私有注册表）获取镜像）以及简单的 docker run 命令来启用和禁用容器的各种功能和配置，从而轻松进入容器领域。使用 runC，开发人员必须从其他系统构建或导出文件系统捆绑包，以创建他们自己的容器起点。他们还需要组合 JSON 配置文件，该文件具有与各种 docker run 标志相关的类似“旋钮”，但必须直接在 JSON 文件中进行编纂，因为 runC 二进制文件本身具有简单的启动、停止、暂停等接口，没有标志。
总体容器策略
这如何融入开发人员的总体策略可能取决于开发人员的意图和期望的结果。对于寻求更简单的容器执行模型而不需要更广泛的 Docker 守护进程功能的开发人员来说，runC 与 containerd（Docker 1.11 及更高版本引擎中使用的另一个 Docker 开源项目）的结合可能是一个不错的选择。在我在西雅图举行的 DockerCon 大会上发表演讲后，有几位开发人员走过来分享了他们基于 containerd 和 runC 中的一个或两个构建的完整容器云架构，这些架构正在进行有趣的工作负载和容器生命周期。然而，在许多情况下，runC 可能只是一个较低层级的细节，可能对开发人员的一般兴趣不大。
将讨论范围稍微扩展到纯粹的 runC 之外，我们尚未讨论的一种使用模型是 runC 与 Docker 引擎或其他未来符合 OCI 标准的引擎的可插拔性。在 OCI 社区中，已经有像 runv、runz 等项目，它们使用 Solaris 区域或轻量级虚拟机监控程序（参见 Intel clear containers 作为示例）作为操作系统级隔离技术来实现通用的 OCI 运行时规范。runC 或类似 runC 的实现受到关注的另一种方式是针对其他隔离技术或操作系统容器功能的开发人员。
映射容器功能，例如 seccomp 和用户命名空间
由于 libcontainer（这个操作系统层库完成了为您的操作系统执行容器隔离原语的实际工作）是 runC 的核心，因此任何操作系统层的功能（例如 seccomp 和用户命名空间）都必须首先在 runC 中实现，然后才能暴露给更高的层，例如 Docker 引擎。这种额外的能力——在 runC 中尝试尚未在更高层公开的新功能——是 runC 的另一个吸引人的地方，并且 Docker 中公开的几个最新功能在 libcontainer 和 runC 中可用得早于它们进入 Docker。这也意味着在开发这些隔离功能或增强的安全功能期间，runC 是一个很好的工具，可以使用 JSON 配置文件来测试和尝试独特的配置。
在 他在 ContainerCon 上的演讲 中，Phil 将演示这个用例，他将展示如何使用 JSON 配置文件中的 seccomp 条目来打开/关闭使用某些系统调用的能力，并立即观察对应用程序的影响。他还将展示一个使用现有开源工具的工作流程，以缩短开发人员使用 runC 的启动时间，使用当前的 Docker 容器和镜像作为输入来创建 runC 就绪的配置和根文件系统捆绑包。
评论已关闭。