资讯专栏INFORMATION COLUMN

上云采购季！| 2核2G4M爆款云服务器低至59元/年，更有多台、长期优惠，快来选购！

立即前往
首页/文章专栏/runc 1.0-rc6 发布之际

runc 1.0-rc6 发布之际

idisfkj / 2414人阅读

摘要：但当时并没有进行正式版发布，转而三个月后，稍做了更新。发布周期不明确。总结以上就是本次关于发布时的一些碎碎念，对这种情况颇有感慨，符合规范并没有那么好做，尤其是做基础支撑的时候。

如果你在用 Docker 或者 Kubernetes 想必你对 容器运行时 这个概念应该不会太陌生。

在 Docker 中，当你使用 docker info 即可查看当前所使用的 runtime。

</>复制代码 
  1. ➜  ~ docker info
  2. ...
  3. Server Version: 18.06.1-ce
  4. Storage Driver: overlay2
  5.  Backing Filesystem: extfs
  6.  Supports d_type: true
  7.  Native Overlay Diff: true
  8. Logging Driver: json-file
  9. Cgroup Driver: cgroupfs
  10. ...
  11. Swarm: inactive
  12. Runtimes: nvidia runc
  13. Default Runtime: runc
  14. Init Binary: docker-init
  15. containerd version: 468a545b9edcd5932818eb9de8e72413e616e86e
  16. runc version: 69663f0bd4b60df09991c08812a60108003fa340
  17. init version: fec3683
  18. Security Options:
  19.  seccomp
  20.   Profile: default
  21. ...

同时，你还可以自己在 /etc/docker/daemon.json 中增加支持的 runtime ， 以及在 docker run 的时候，通过 --runtime 参数配置所使用的 runtime 。

什么是 runc

简单来说，它是 OCI 标准的一种实现。 OCI 标准包含 运行时标准 和 镜像标准 两个部分，而 OCI 这个组织则是由 Docker, CoreOS 和其他的一些公司共同发起创建的，致力于将容器运行时和格式标准化。

即：凡是遵守此标准的实现，无论是 Docker 还是 rkt 或者其他的运行时实现，均可以通过标准的镜像启动容器。

runc 则是在 OCI 成立后，Docker 将其容器运行时 libcontainer 贡献出来后，并加以改造而成的。而 libcontainer 也是在 Docker 0.9 版本开始加入，我也是从这个版本开始使用它。

当然 libcontainer 出现的本意不仅是替换当时的 LXC 依赖，同时也希望能以此作为规范（让其他的项目使用）最终，目标达成。

runc 如何使用

runc 的使用本不是本篇的重点，稍微带过。

</>复制代码 
  1. ➜  ~ docker export -o debian.tar  `docker create debian`
  2. ➜  ~ ls
  3. debian.tar
  4. ➜  ~ tar -C rootfs -xf debian.tar
  5. ➜  ~ ls
  6. debian.tar   rootfs
  7. ➜  ~ tree -L 1 -a rootfs
  8. rootfs
  9. ├── bin
  10. ├── boot
  11. ├── dev
  12. ├── .dockerenv
  13. ├── etc
  14. ├── home
  15. ├── lib
  16. ├── lib64
  17. ├── media
  18. ├── mnt
  19. ├── opt
  20. ├── proc
  21. ├── root
  22. ├── run
  23. ├── sbin
  24. ├── srv
  25. ├── sys
  26. ├── tmp
  27. ├── usr
  28. └── var
  29. 19 directories, 1 file

通过以上操作，得到了运行一个容器所必须的 rootfs，当然，上面看到我是通过 docker 来获得这个文件的，但其实这只是为了方便罢了，docker 并不是必须的。

</>复制代码 
  1. ➜  ~ runc spec
  2. ➜  ~ ls
  3. config.json  debian.tar  rootfs

通过上面的操作，会得到一个基本的 config.json 的配置文件，这里面包含着运行一个容器所需要的一些配置。其中会包含着一些例如：

</>复制代码 
  1. "ociVersion": "1.0.1-dev"

这种用于标识规范版本号的信息。

接下来稍微对 config.json 文件进行查看，便可以看到未通过 user Namespace 进行隔离，所以我们需要以 root 权限运行我们的容器。

</>复制代码 
  1. ➜  ~ sudo runc run debian
  2. # ls                                      
  3. bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
  4. # hostname    
  5. runc               
  6. # cat /etc/os-release
  7. PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
  8. NAME="Debian GNU/Linux"
  9. VERSION_ID="9"
  10. VERSION="9 (stretch)"
  11. ID=debian
  12. HOME_URL="https://www.debian.org/"
  13. SUPPORT_URL="https://www.debian.org/support"
  14. BUG_REPORT_URL="https://bugs.debian.org/"

可以看到容器已经运行成功。当然，我们也可以不通过 root 权限运行容器，只要简单的通过 user Namespace 进行隔离，并添加 user 和 group 的映射之类的便可以了。此处不做赘述。

为何有 runc 1.0-rc6 存在

我们知道，OCI 在 2015 年成立，在 2017 年 7 月的时候正式宣布 OCI v1.0.0 release 。其实在 2017 年的 11 月还 release 了 v1.0.1 版本。

前面已经提过 runc 是 OCI 的官方实现，那为何时过一年还未正式 release 1.0 呢？这里面原因其实说来也复杂，这也是这篇文章想聊的部分。

首先：runc 1.0 我们想正式 relase 么？ 答案是 想。其实早在 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 在持续的迭代改进，另一方面是目前很多其他的运行时实现的一些 hooks 依赖于当前的一些实现，而这些实现，并不完全符合规范。这就造成了一旦修正了这些 “错误” 势必造成其他运行时的不稳定和错误。

发布周期不明确。目前容器相关生态中较为核心的项目，估计就 runc 的发布周期比较 “佛系” 了，我们甚至没有一个明确的发布周期。这次的总结中，我以 Kubernetes 的发布做了例子：

Kubernetes Release Date Cadence
Christening of 1.0 10th July 2015 ~one year from inception
From 1.0 to 1.1 9th November 2015 122 days
From 1.1 to 1.2 16th March 2016 128 days
From 1.2 to 1.3 1st July 2016 107 days
From 1.3 to 1.4 26th September 2016 87 days
From 1.4 to 1.5 12th December 2016 77 days
From 1.5 to 1.6 28th March 2017 106 days
From 1.6 to 1.7 30th June 2017 94 days
From 1.7 to 1.8 28th September 2017 90 days
From 1.8 to 1.9 15th December 2017 78 days
From 1.9 to 1.10 28th March 2018 103 days
From 1.10 to 1.11 3rd July 2018 97 days
From 1.11 to 1.12 ETA 25th September 2018 84 days

以这个发布记录来看的话，每三个月作为以此发布相对合适，也比较通用。

至于这次，runc 1.0-rc6 的发布，将作为特性冻结发布，直到下次发布前，重点都将放在 “符合规范” 上面，同时也给其他的运行时实现充足的时间，用于做好兼容之类的。

总结

以上就是本次关于 runc 1.0-rc6 发布时的一些碎碎念，对这种情况颇有感慨，“符合规范” 并没有那么好做，尤其是做基础支撑的时候。

可以通过下面二维码订阅我的文章公众号【MoeLove】

云服务器 GPU云服务器 runc 蓝绿发布 vs 灰度发布 灰度发布和不停机发布 全网发布

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/27572.html

相关文章

  • runc 1.0-rc6 发布之际

    摘要：但当时并没有进行正式版发布，转而三个月后，稍做了更新。发布周期不明确。总结以上就是本次关于发布时的一些碎碎念，对这种情况颇有感慨，符合规范并没有那么好做，尤其是做基础支撑的时候。 如果你在用 Docker 或者 Kubernetes 想必你对 容器运行时 这个概念应该不会太陌生。 在 Docker 中，当你使用 docker info 即可查看当前所使用的 runtime。 ➜ ~ ...

    singerye 评论0 收藏0

  • runc 1.0-rc6 发布之际

    摘要：但当时并没有进行正式版发布，转而三个月后，稍做了更新。发布周期不明确。总结以上就是本次关于发布时的一些碎碎念，对这种情况颇有感慨，符合规范并没有那么好做，尤其是做基础支撑的时候。 如果你在用 Docker 或者 Kubernetes 想必你对 容器运行时 这个概念应该不会太陌生。 在 Docker 中，当你使用 docker info 即可查看当前所使用的 runtime。 ➜ ~ ...

    qujian 评论0 收藏0

  • runc 1.0-rc7 发布之际

    摘要：在年月底时，我写了一篇文章发布之际。为何有存在前面已经基本介绍了相关背景，并且也基本明确了就是在正式发布之前的最后一个版本，那为什么会出现呢我们首先要介绍今年的一个提权漏洞。 在 18 年 11 月底时，我写了一篇文章 《runc 1.0-rc6 发布之际》 。如果你还不了解 runc 是什么，以及如何使用它，请参考我那篇文章。本文中，不再对其概念和用法等进行说明。 在 runc 1....

    zhunjiee 评论0 收藏0

  • runc 1.0-rc7 发布之际

    摘要：在年月底时，我写了一篇文章发布之际。为何有存在前面已经基本介绍了相关背景，并且也基本明确了就是在正式发布之前的最后一个版本，那为什么会出现呢我们首先要介绍今年的一个提权漏洞。 在 18 年 11 月底时，我写了一篇文章 《runc 1.0-rc6 发布之际》 。如果你还不了解 runc 是什么，以及如何使用它，请参考我那篇文章。本文中，不再对其概念和用法等进行说明。 在 runc 1....

    YanceyOfficial 评论0 收藏0

发表评论

登陆后可评论

0条评论

idisfkj

男|高级讲师
我要私信

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<