摘要：但當時并沒有進行正式版發(fā)布，轉而三個月后，稍做了更新。發(fā)布周期不明確。總結以上就是本次關于發(fā)布時的一些碎碎念，對這種情況頗有感慨，符合規(guī)范并沒有那么好做，尤其是做基礎支撐的時候。

如果你在用 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: true
Logging 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 參數(shù)配置所使用的 runtime 。

簡單來說，它是 OCI 標準的一種實現(xiàn)。 OCI 標準包含 運行時標準 和 鏡像標準 兩個部分，而 OCI 這個組織則是由 Docker, CoreOS 和其他的一些公司共同發(fā)起創(chuàng)建的，致力于將容器運行時和格式標準化。

即：凡是遵守此標準的實現(xiàn)，無論是 Docker 還是 rkt 或者其他的運行時實現(xiàn)，均可以通過標準的鏡像啟動容器。

runc 則是在 OCI 成立后，Docker 將其容器運行時 libcontainer 貢獻出來后，并加以改造而成的。而 libcontainer 也是在 Docker 0.9 版本開始加入，我也是從這個版本開始使用它。

當然 libcontainer 出現(xiàn)的本意不僅是替換當時的 LXC 依賴，同時也希望能以此作為規(guī)范（讓其他的項目使用）最終，目標達成。

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
└── var

19 directories, 1 file

通過以上操作，得到了運行一個容器所必須的 rootfs，當然，上面看到我是通過 docker 來獲得這個文件的，但其實這只是為了方便罷了，docker 并不是必須的。

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

通過上面的操作，會得到一個基本的 config.json 的配置文件，這里面包含著運行一個容器所需要的一些配置。其中會包含著一些例如：

"ociVersion": "1.0.1-dev"

這種用于標識規(guī)范版本號的信息。

接下來稍微對 config.json 文件進行查看，便可以看到未通過 user Namespace 進行隔離，所以我們需要以 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
# hostname    
runc               
# cat /etc/os-release
PRETTY_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 進行隔離，并添加 user 和 group 的映射之類的便可以了。此處不做贅述。

我們知道，OCI 在 2015 年成立，在 2017 年 7 月的時候正式宣布 OCI v1.0.0 release 。其實在 2017 年的 11 月還 release 了 v1.0.1 版本。

前面已經提過 runc 是 OCI 的官方實現(xiàn)，那為何時過一年還未正式 release 1.0 呢？這里面原因其實說來也復雜，這也是這篇文章想聊的部分。

首先：runc 1.0 我們想正式 relase 么？ 答案是 想。其實早在 2017 年 8 月份的時候 runc 1.0-rc4 就已經支持 OCI v1.0.0 了。但當時并沒有進行正式版發(fā)布，轉而三個月后， OCI 稍做了更新。

到 2018 年 2 月份的時候，發(fā)布了 runc 1.0-rc5 -- "The Final Stretch" 這個版本取名其實已經很明確了 The Final Stretch 已經將這個版本作為正式版本前的最后一個版本進行發(fā)布了。

但是，提筆前又發(fā)了新版本 runc 1.0-rc6 -- "For Real This Time" ，這個版本在預期中其實是想發(fā)布 1.0 的。我們討論后總結的結論主要有以下幾個：

不夠規(guī)范。一方面是 runc 在持續(xù)的迭代改進，另一方面是目前很多其他的運行時實現(xiàn)的一些 hooks 依賴于當前的一些實現(xiàn)，而這些實現(xiàn)，并不完全符合規(guī)范。這就造成了一旦修正了這些 “錯誤” 勢必造成其他運行時的不穩(wěn)定和錯誤。

發(fā)布周期不明確。目前容器相關生態(tài)中較為核心的項目，估計就 runc 的發(fā)布周期比較 “佛系” 了，我們甚至沒有一個明確的發(fā)布周期。這次的總結中，我以 Kubernetes 的發(fā)布做了例子：

以這個發(fā)布記錄來看的話，每三個月作為以此發(fā)布相對合適，也比較通用。

至于這次，runc 1.0-rc6 的發(fā)布，將作為特性凍結發(fā)布，直到下次發(fā)布前，重點都將放在 “符合規(guī)范” 上面，同時也給其他的運行時實現(xiàn)充足的時間，用于做好兼容之類的。

以上就是本次關于 runc 1.0-rc6 發(fā)布時的一些碎碎念，對這種情況頗有感慨，“符合規(guī)范” 并沒有那么好做，尤其是做基礎支撐的時候。

可以通過下面二維碼訂閱我的文章公眾號【MoeLove】