runc 1.0-rc6 发布之际

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

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

➜  ~ docker info
...
Server Version: 18.06.1-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: trueLogging Driver: json-file
Cgroup Driver: cgroupfs
...
Swarm: inactive
Runtimes: nvidia runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 468a545b9edcd5932818eb9de8e72413e616e86e
runc version: 69663f0bd4b60df09991c08812a60108003fa340
init version: fec3683
Security Options:
 seccomp
  Profile: default
...

同时,你还可以自己在 /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 的使用本不是本篇的重点,稍微带过。

➜  ~ docker export -o debian.tar  `docker create debian`
➜  ~ ls
debian.tar
➜  ~ tar -C rootfs -xf debian.tar
➜  ~ ls
debian.tar   rootfs
➜  ~ tree -L 1 -a rootfs
rootfs
├── bin
├── boot
├── dev
├── .dockerenv
├── etc
├── home
├── lib
├── lib64
├── media
├── mnt
├── opt
├── proc
├── root
├── run
├── sbin
├── srv
├── sys
├── tmp
├── usr
└── var19 directories, 1 file

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

➜  ~ runc spec
➜  ~ ls
config.json  debian.tar  rootfs

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

"ociVersion": "1.0.1-dev"

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

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

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

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

为何有 runc 1.0-rc6 存在

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

前面已经提过 runcOCI 的官方实现,那为何时过一年还未正式 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(TheMoeLove)

原文发表时间:2018-11-27

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏云计算D1net

想要使用容器技术 这5类遗留工具就应该被淘汰

充分利用容器并不只是安装Dockers和激活容器应用程序那么简单。你需要改进的同样还有监控方法、安全性能等。 这么做的理由是,容器并不只是对你过去工作中使用到的...

36080
来自专栏点点滴滴

关于Windows系统安装(一)

13160
来自专栏Albert陈凯

5分钟弄懂Docker

尽管之前久闻Docker的大名了,但是天资愚钝,对其到底是个啥东西一直摸不清,最近花了一段时间整理了一下,算是整理出一点头绪来。 官网的介绍是这样的: Do...

35550
来自专栏大魏分享(微信公众号:david-share)

原生KVM虚拟化方案"管理平台"配置步骤(RHV-M Appliance)

浅谈2016年的虚拟化市场 本文正式开始之前,先阐述一个观点,即RHV/RHEV是基于KVM原生的虚拟化解决方案, 为什么这么说呢? 首先,KVM严格意义上讲不...

53340
来自专栏IT大咖说

揭秘携程内部海量CRN项目解决方案

摘要 随着公司内部CRN项目的日益增多,越来越多的业务部门开始意识到,是否可以将CRN的项目直接运行在浏览器上,以免去他们在H5和SEO上的额外开发。甚至有的W...

45650
来自专栏编程坑太多

跟我一起学docker(一)--认识

22740
来自专栏美团技术团队

美团容器平台架构及容器技术实践

美团的容器集群管理平台叫做HULK。漫威动画里的HULK在发怒时会变成“绿巨人”,它的这个特性和容器的“弹性伸缩”很像,所以我们给这个平台起名为HULK。貌似有...

24250
来自专栏喵了个咪的博客空间

Kubernetes(一) - Docker管理工具

21730
来自专栏DevOps时代的专栏

E2E 测试容器化实践

在互联网最初之时,没有任何容器化的概念,那么刚开始的时候是怎样开发软件或者是网站的吗?那时就是计算机便是服务器,就是一个简单的静态网页,没有复杂的业务逻辑。

16320
来自专栏FreeBuf

如何打造一款可靠的WAF(Web应用防火墙)

之前写了一篇《WAF防御能力评测及工具》,是站在安全运维人员选型WAF产品的角度来考虑的(优先从测试角度考虑是前职业病,毕竟当过3年游戏测试?!)。本篇文章从W...

42150

扫码关注云+社区

领取腾讯云代金券