用于发布 runc 1.0-rc6

总结：不过当时还没有发布正式版本。 相反，三个月后略有更新。 发布周期未知。 这些是我对此版本的想法。 我对这种情况非常感慨。 遵守规范并不那么容易，尤其是在进行基本支持时。

如果您使用 Docker 或 Kubernetes，您应该熟悉容器运行时的概念。

在Docker中，您可以使用docker info查看当前使用的运行时。

➜ ~ docker info...服务器版本：18.06.1-ceStorage 驱动程序：overlay2 支持文件系统：extfs d_type：true 支持本机覆盖 Diff：trueLogging 驱动程序：json-fileCgroup 驱动程序：cgroupfs ...Swarm：非活动执行时间：nvidia runcDefault运行时：runcInit二进制文件：docker-initcontainerd版本：468a545b9edcd5932818eb9de8e72413e616e86erunc版本：69663f0bd4b60df09991c08812a60108003 fa3 40初始版本： fec3683 安全选项：seccomp 配置文件：默认...

同时，您还可以通过将支持的运行时添加到/etc/docker/daemon.json来添加对docker的支持。在执行时时，通过--runtime参数设置要使用的运行时。

runc

简而言之，它是OCI标准的实现。 OCI标准包括两部分：运行时标准和图像标准。 OCI 组织由 Docker 组建，而 CoreOS 则由许多其他公司共同创立，旨在标准化容器运行时和格式。

这意味着任何符合该标准的实现，甚至是诸如 Docker 或 rkt 之类的运行时实现，都可以通过标准镜像来运行容器。开始了。

runc 一旦OCI建立，Docker使用libcontainer来运行容器。 贡献和转变。 而且Docker0.9版本中也添加了libcontainer，我从这个版本开始使用它。

当然，libcontainer的最初目的不仅仅是为了替代当时的LXC依赖，也是为了将其作为标准使用（其他项目使用它）。 ，目的就达到了。

runc

如何使用runc如何使用runc不是本文的重点不过，我将简要讨论一下。

➜ ~ docker export -o debian.tar `docker create debian`➜ ~ lsdebian.tar➜ ~ tar -C rootfs -xf debian.tar➜ ~ lsdebian.tar rootfs➜ ~ 树 -L1 -a rootfsrootfs§── bin§── boot dev say── .dockerenv §── etctil── home say── lib §── lib64 Know── opt§── proc├ ── root∴── run∴── sbin§── srv§── sys∴── tmp§──​​​ usr└── var19目录，1个文件

。 通过以上操作，我们就获得了运行容器所需的rootfs。 当然，我们在上面看到我们通过 docker 获取了这个文件，但实际上这只是为了方便，我们不需要 docker。

➜~runc spec➜~lsconfig.json debian.tar rootfs

通过以上操作，你将得到基本的config.json配置文件。马苏。 这包括运行容器所需的一些配置。 这包括以下信息：

"ociVersion": "1.0.1-dev"

用于标识规范的版本号。

接下来，如果您查看 config.json 文件，您将看到该文件不是通过 user 命名空间隔离的。 使用 root 权限运行容器。

➜ ~ sudo runc run debian# ls bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var# 主机名 runc # cat /etc/os-releasePRETTY_NAME="Debian GNU/Linux 9 (stretch)"NAME="Debian GNU/Linux"VERSION_ID="9"VERSION="9 (stretch)" ID=debianHOME_URL= " https://www.debian.org/"SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/"

容器是执行成功。 当然，您也可以在没有 root 权限的情况下运行容器。 您可以简单地通过 user 命名空间将其隔离，并添加 user 和 group 的映射。 我们在这里不再赘述。

为什么 runc 1.0-rc6 存在

OCI 成立于 2015 年和 2017 年 7 月。我知道这一点。 3月，OCI v1.0.0正式发布。 事实上，v1.0.1 已于 2017 年 11 月发布。

前面说过，runc是OCI的官方实现，那为什么还没有发布呢？ 一年后才正式发布1.0？这其中的原因其实很复杂，这也是我这篇文章要讲的。

第一：runc你们会正式发布1.0吗？答案是肯定的。 事实上，截至 2017 年 8 月，runc 1.0-rc4 已支持 OCI v1.0.0。 但并未得到官方支持。正式发布三个月后，OCI收到了一些更新。

2018 年 2 月，runc 1.0-rc5 --“The Final Stretch”发布。 这个版本的名字其实已经很清楚了。 The Final Stretch发布此版本作为正式版本之前的最后一个版本。

但是，在撰写本文之前，发布了新版本 runc 1.0-rc6 --“For Real This Time”。 该版本实际上计划作为 1.0 发布。 经过讨论我们总结的主要结论是：

标准化程度不高。 一方面，runc正在不断改进，但另一方面，许多其他运行时实现的一些钩子目前依赖于当前的实现，这些实现并不完全符合规范。 这意味着一旦这些“错误”被修复，其他运行时不稳定和错误将不可避免地发生。

发布周期未知。 目前容器相关生态中的核心项目之一runc，发布周期比较“佛系”。 甚至没有明确的发布周期。 本概述使用 Kubernetes 版本作为示例。

日期

Cadence

2015年7月10日

从开始算起大约 1 年

2015年11月9日

122天

2016 年 3 月 16 日

128 天

2016 年 7 月 1 日

107 天

2016 年 9 月 26 日

87 天

2016年12月12日天

77天

2017年3月28日

106 天

2017 年 6 月 30 日

94天

2017年9月28日

90 天

2017 年 12 月 15 日

td>78 天

3 月 28 日， 2018

103天

td>2018 年 7 月 3 天

97 天

预计2018年9月25日

84天

从这个发布记录来看，这是每年的发布日期3个月。 比较合适。 而且多才多艺。

这次，runc 1.0-rc6 将作为功能冻结发布。 在下一个版本发布之前，重点将放在“符合规范”上。 同时，它给其他运行时实现足够的时间来实现兼容性等。

概述>

以上是我对runc 1.0-rc6发布的一些想法。 我对这种情况非常感慨。 “符合规范”并不那么容易，尤其是在进行基本支持时。

您可以通过下面的二维码订阅我的文章发布账号【MoeLove】