本文讲的是runC：轻量级容器运行环境【编者的话】runC是一个开源项目，虽然现在它只是个命令行工具，但它将是一个通用标准化环境，值得一试！
runC 是一个轻量级通用容器运行环境。目前，它是一个命令行工具，可以根据开放容器方案（Open Container Initiative）生成和运行容器。它的远景是：由Docker、Google、IBM、Microsoft、RedHat还有其他参与者创建一个通用且标准化的运行环境，提供容器运行时的元素可读文档，由Docker向OCI提供基于代码的可用实现方法。这包括libcontainer，Docker使用的原生底层接口，支持操作系统构建。
鉴于runC是一个开源项目并固定周期发布版本，可以从 GitHub上找到它的源码和相应版本 。如果你下载并编译runC的二进制，你将会得到采用runC作为简单容器运行环境的全部组件，包括1个JSON容器配置和1个根文件系统。如果你已经安装了Docker1.11或者更高版本，将自动获得一个近期版本的runC。它被命名为docker-runC，安装在/usr/bin下，可以在在Docker环境外使用，就像正常安装的runC一样。
除了在操作系统层面的新特性，runC是一个有效的debug平台，特别是处理需要debug容器进程上的整个Docker栈的复杂情况。
稍微超出一些单纯runC的讨论，有个一直没有讨论的内容是runC对Docker和其他OCI工具的可插入性。虽然在OCI社区中有其他项目runv、runz还有其他用Solaris zones或者轻量级hypervisor实现的OCI运行时技术。另一方面，runC和类似runC的实现对关注隔离技术或者操作系统容器特性的开发者比较有吸引力。
在他 ContainerCon的演讲中 ，Pill将会描述他的用例，还将展示如何用seccomp开启或者关闭特定syscall，并观察在应用程序上的效果。他还将利用开源工具来展示工作流提高开发者效率，利用当前Docker容器和镜像作为输入创建一个现有runC配置和根文件系统。
原文链接：runC: The little container engine that could（翻译：陈杰）
===================================================
译者介绍
runC 是一个轻量级通用容器运行环境。目前，它是一个命令行工具，可以根据开放容器方案（Open Container Initiative）生成和运行容器。它的远景是：由Docker、Google、IBM、Microsoft、RedHat还有其他参与者创建一个通用且标准化的运行环境，提供容器运行时的元素可读文档，由Docker向OCI提供基于代码的可用实现方法。这包括libcontainer，Docker使用的原生底层接口，支持操作系统构建。
鉴于runC是一个开源项目并固定周期发布版本，可以从 GitHub上找到它的源码和相应版本 。如果你下载并编译runC的二进制，你将会得到采用runC作为简单容器运行环境的全部组件，包括1个JSON容器配置和1个根文件系统。如果你已经安装了Docker1.11或者更高版本，将自动获得一个近期版本的runC。它被命名为docker-runC，安装在/usr/bin下，可以在在Docker环境外使用，就像正常安装的runC一样。
采用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栈的复杂情况。
使用runC的门槛
开发者们已经习惯了Docker生态系统中从low-friction点到容器的方式，包括采用DockerHub或者私有registry的镜像、直接运行docker run
来开启或者关闭容器的特性和配置。使用runC时，开发者必须要从其他系统中构建或者导出文件系统包，用于创建容器的入口。他们同样需要配置一些JSON文件，用于实现类似
docker run
的参数，这些需要直接编码在JSON文件中，因为runC有简单的启动、终止、暂停等接口，但是没有相应参数。
综合容器策略
它与开发人员总体策略的吻合度依赖于这是否是开发者的意愿和预期结果。对于一个寻找简单地运行容器的模型而不需要Docker守护进程特性的开发者来说，runC类似 containerd ，另一个Docker开源项目，它在Docker1.11及更高版本中存在，或许是个更好的选择。在西雅图的DockerCon演讲之后，我见到了多个开发者并分享他们构建的整个容器云架构，利用一个或者多个containerd和runC做有有趣的工作负载和容器生命周期管理。在很多场景下，runC将会是一个底层的细节，可能会也可能不会引起开发者的兴趣。稍微超出一些单纯runC的讨论，有个一直没有讨论的内容是runC对Docker和其他OCI工具的可插入性。虽然在OCI社区中有其他项目runv、runz还有其他用Solaris zones或者轻量级hypervisor实现的OCI运行时技术。另一方面，runC和类似runC的实现对关注隔离技术或者操作系统容器特性的开发者比较有吸引力。
映射容器特性，如Seccomp和用户命名空间
由于libcontainer（一个操作系统层的库）为操作系统提供容器隔离，它是runC的核心，相比起暴露给上层（如Docker），操作系统层的特性（例如sceccomp和用户命名空间）必须在runC中优先实现，这个特性（没有在runC中实现）是runC吸引人的地方。需要最新的特性已经暴露给Docker，并且在libcontainer和runC中已经可用。这同样意味着在这些隔离特性或者增强安全特性开发期间，runC是一个非常好的工具用JSON文件来测试配置。在他 ContainerCon的演讲中 ，Pill将会描述他的用例，还将展示如何用seccomp开启或者关闭特定syscall，并观察在应用程序上的效果。他还将利用开源工具来展示工作流提高开发者效率，利用当前Docker容器和镜像作为输入创建一个现有runC配置和根文件系统。
原文链接：runC: The little container engine that could（翻译：陈杰）
===================================================
译者介绍
陈杰，BOSS直聘app的数据工程师，工作重心为基于用户行为的数据推荐，平时也乐于去实现一些突发的想法。在疲于配置系统环境时发现了Docker，跟大家一起学习、使用和研究Docker。
原文发布时间为：2016-08-27
本文作者：陈杰
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：runC：轻量级容器运行环境
