![]()
runC（https://runc.io/）是一个轻量级通用容器运行环境。目前，它是一个命令行工具，可以根据开放容器方案（Open Container Initiative）生成和运行容器。它的远景是：由Docker、Google、IBM、Microsoft、RedHat还有其他参与者创建一个通用且标准化的运行环境，提供容器运行时的元素可读文档，由Docker向OCI提供基于代码的可用实现方法。这包括libcontainer，Docker使用的原生底层接口，支持操作系统构建。
假定runC是一个开源项目并固定周期发布版本，可以从GitHub上找到它的源码和相应版本（https://github.com/opencontainers/runc）。如果你下载并编译runC的二进制，你将会得到采用runC作为简单容器运行环境的全部组件，包括1个JSON容器配置和1个根文件系统。如果你已经安装了Docker1.11或者更高版本，将自动获得一个近期版本的runC。它被命名为docker-runC，安装在/usr/bin下，可以在在Docker环境外使用，就像正常安装的runC一样。
在OCI和runC存在以前，很多Docker的核心开发者用过runC的类似工具nsinit，它允许一个简化的探针到运行和调试的底层容器的功能，不需要整个Docker守护进程的接口。现在runC存在了，这依然是个应用场景，特别是某些潜在挖掘新的linux隔离特性的人。例如，Linux用户检查点/恢复项目( Linux Checkpoint/Restore In Userspace，CRIU)中的检查点/恢复特性已经通过runC实现，并且准备成为Docker守护进程中runC的更高一层。当然，随着runC/OCI在Linux上的扩展，它也将会成为其他系统资源隔离的可能。例如，Solaris zones和Microsoft上基于Windows的容器，这两者均期待具有OCI运行特性并通过runC来实现。
除了在操作系统层面的新特性，runC是一个有效的debug平台，特别是处理需要debug容器进程上的整个Docker栈的复杂情况。
开发者们已经习惯了Docker生态系统中从low-friction点到容器的方式，包括采用DockerHub或者私有registry的镜像、直接运行
docker run
来开启或者关闭容器的特性和配置。使用runC时，开发者必须要从其他系统中构建或者导出文件系统包，用于创建容器的入口。他们同样需要配置一些JSON文件，用于实现类似
docker run
的参数，这些需要直接编码在JSON文件中，因为runC有简单的启动、终止、暂停等接口，但是没有相应参数。
它与开发人员总体策略的吻合度依赖于这是否是开发者的意愿和预期结果。对于一个寻找简单地运行容器的模型而不需要Docker守护进程特性的开发者来说，runC类似Containerd（https://github.com/docker/containerd），另一个Docker开源项目，它在Docker1.11及更高版本中存在，或许是个更好的选择。在西雅图的DockerCon演讲之后，我见到了多个开发者并分享他们构建的整个容器云架构，利用一个或者多个containerd和runC做有有趣的工作负载和容器生命周期管理。在很多场景下，runC将会是一个底层的细节，可能会也可能不会引起开发者的兴趣。
