国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

runc 1.0-rc6 發布之際

idisfkj / 2384人閱讀

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

如果你在用 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 參數配置所使用的 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
└── var

19 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 權限運行我們的容器。

?  ~ 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 的映射之類的便可以了。此處不做贅述。

為何有 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】

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/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條評論

最新活動
閱讀需要支付1元查看
<