導(dǎo)語

容器技術(shù)火起來了以后，Docker的容器鏡像和容器運行時已然成為行業(yè)的標(biāo)準(zhǔn)。此后，為了推進容器生態(tài)的健康發(fā)展。在Linux基金會的主導(dǎo)下，Docker和各大云廠商Google, Amazon, CloudFoundary, Microsoft積極響應(yīng)于2016年成立了 “Open Container Initiative”，旨在主導(dǎo)容器的生態(tài)發(fā)展方向，促進容器生態(tài)的健康發(fā)展。本文主要介紹容器底層的運行標(biāo)準(zhǔn)OCI的背景和主要內(nèi)容，最后通過用runC構(gòu)建容器的示例帶你了解容器背后不一樣的故事。

背景

2013年Docker開源了容器鏡像格式和運行時以后，為我們提供了一種更為輕量、靈活的“計算、網(wǎng)絡(luò)、存儲”資源虛擬化和管理的解決方案，在業(yè)界迅速火了起來。

2014年更是容器技術(shù)發(fā)展的一個爆發(fā)點，各種容器編排工具也逐步開始發(fā)力。值得一提的是Google發(fā)布了Kubernetes的第一個Release版本，現(xiàn)已成長為容器編排領(lǐng)域的領(lǐng)導(dǎo)者。

我們知道Docker的容器運行時解決方案采用的兩個核心技術(shù)：Namespace（資源隔離）和Cgroup（資源管理），并不是Docker實現(xiàn)的。這兩項技術(shù)其實在Docker之前早已進入Linux內(nèi)核。換種說法就是Docker的容器解決方案離不開Linux內(nèi)核的支持。這就是說行業(yè)的各個大佬如果自己想搞，都可以利用這兩項技術(shù)自己做一套類似于Docker的容器解決方案。

到這里就引出了故事的另一個主角: Linux基金會。

容器技術(shù)火起來了以后，Docker的容器鏡像和容器運行時已然成為行業(yè)的標(biāo)準(zhǔn)。彼時，Docker正當(dāng)紅，對各大佬（Linux基金會、谷歌、微軟等）提出的合作邀請充耳不聞，態(tài)度強硬，力圖獨自主導(dǎo)容器生態(tài)的發(fā)展。加上Docker在Runtime的向下兼容性的問題，社區(qū)口碑較差。此時，各大佬就紛紛表示要另起爐灶、自已干，其中比較有代表性的就是Google聲稱要fork一個分支自己干。

不過，Linux基金會最后還是拉著前邊提的這些大佬向Docker施壓，最終Docker屈服，并于 2015 年 6 月在 Docker 大會DockerCon上推出容器標(biāo)準(zhǔn)，隨后便成立了OCI(Open Container Initiative)，并發(fā)展成為Linux基金會下的一個項目。在OCI的官網(wǎng)可以看到如下描述：

The Open Container Initiative (OCI) is a lightweight, open governance structure (project), formed under the auspices of the Linux Foundation, for the express purpose of creating open industry standards around container formats and runtime. The OCI was launched on June 22nd 2015 by Docker, CoreOS and other leaders in the container industry.

The OCI currently contains two specifications: the Runtime Specification (runtime-spec) and the Image Specification (image-spec). The Runtime Specification outlines how to run a “filesystem bundle” that is unpacked on disk. At a high-level an OCI implementation would download an OCI Image then unpack that image into an OCI Runtime filesystem bundle. At this point the OCI Runtime Bundle would be run by an OCI Runtime.

在這兩段描述中透露出2點關(guān)鍵信息：

1. OCI是在Linux基金會主導(dǎo)下的輕量級的開源管理項目。旨在為容器格式和運行時構(gòu)建開放的行業(yè)標(biāo)準(zhǔn)。

2. OCI標(biāo)準(zhǔn)目前包含兩部分內(nèi)容：

? ?- 容器運行時規(guī)范： 該規(guī)范定義了如何根據(jù)相應(yīng)的配置構(gòu)建容器運行時。

? ?- 容器鏡像規(guī)范： 該規(guī)范定義了容器運行時使用的鏡像的打包規(guī)范。

總的來說OCI的成立促進了社區(qū)的持續(xù)創(chuàng)新，同時可以防止行業(yè)由于競爭導(dǎo)致的碎片化，容器生態(tài)中的各方都能從中獲益。目前在行業(yè)中遵循OCI標(biāo)準(zhǔn)的容器解決方案比較熟悉的有：

Docker

Rocket（CoreOS）

warden (Cloud Foundary)

OCI Runtime 規(guī)范

基本理念

OCI規(guī)范了容器的配置、執(zhí)行環(huán)境和生命周期管理**。容器的配置信息由config.json配置文件來管理。規(guī)范容器的執(zhí)行環(huán)境可以保證容器內(nèi)運行的應(yīng)用在生命周期內(nèi)擁有一致的運行環(huán)境?？偟膩碚fOCI希望通過規(guī)范容器的配置、執(zhí)行環(huán)境和生命周期管理，進而達到Docker所提出的“Build, Ship, and Run any app, anwhere”愿景，為了達到這個目的，OCI在制定之初提出了以下5個理念：

1. 操作標(biāo)準(zhǔn)化：

對容器整個生命周期內(nèi)相關(guān)的標(biāo)準(zhǔn)化進行標(biāo)準(zhǔn)化，包括：創(chuàng)建、啟動、停止、創(chuàng)建快照、暫停、恢復(fù)等操作。規(guī)范每個操作的具體含義，將容器的具體操作進行原子化規(guī)范。

2. 內(nèi)容無關(guān)：

內(nèi)容無關(guān)指不管針對的具體容器內(nèi)容是什么，容器標(biāo)準(zhǔn)操作執(zhí)行后都能產(chǎn)生同樣的效果。如容器可以用同樣的方式上傳、啟動，不管是PostgreSQL還是MySQL數(shù)據(jù)庫服務(wù)。

3. 基礎(chǔ)設(shè)施無關(guān)：

容器可以運行在任何支持OCI的基礎(chǔ)設(shè)施上。

4. 為自動化而生：

由于容器的標(biāo)準(zhǔn)操作與基礎(chǔ)設(shè)施無關(guān)，這樣就為我們更好的進行自動化管理提供了良好的基礎(chǔ)。以前那些耗時、耗力需要投入大量人力的工作，現(xiàn)在就可以利用容器進行自支管理。

制定容器統(tǒng)一標(biāo)準(zhǔn)，是的操作內(nèi)容無關(guān)化、平臺無關(guān)化的根本目的之一，就是為了可以使容器操作全平臺自動化。

5. 工業(yè)級交付：

容器標(biāo)準(zhǔn)化能夠使軟件應(yīng)用的分發(fā)可以達到工業(yè)級的交付。標(biāo)準(zhǔn)容器使得我們可以構(gòu)建自動化的軟件交付流水線。不管是內(nèi)部的DevOps流，還是外部的軟件交付機制，容器正在一點點的改變我們對軟件打包和交付的認識。

基本屬性

OCI規(guī)范規(guī)定容器的基本狀態(tài)包含以下幾種屬性：

- ociVersion：oci規(guī)范的版本信息 - id: 容器的ID, 在同一主機上必須唯一，對于不同主機的容器ID，不做強制性要求。 - status: 容器的運行狀態(tài)，包含以下幾種： ?creating: 正在被創(chuàng)建 ?created: 容器進程未退出，而用戶的應(yīng)用進程還未執(zhí)行的狀態(tài)。 ?running： 容器進程已經(jīng)退出，而且用戶的應(yīng)用進程已經(jīng)開始正常運行。 ?stopped: 容器進程已經(jīng)退出。- pid: 容器進程ID。 - bundle: 容器標(biāo)準(zhǔn)包的絕對路徑。包含了容器的具體運行時配置信息和root文件系統(tǒng)。 - annotations: 容器的自定義屬性信息。

示例如下：

{ ? ?"ociVersion": "0.2.0",

? ?"id": "oci-container1",

? ?"status": "running",

? ?"pid": 4422,

? ?"bundle": "/containers/redis",

? ?"annotations": {

? ? ? ?"myKey": "myValue" ? ?}

}

生命周期

OCI定義了容器的生命周期中四個基本的狀態(tài): creating, created, running, stopped。各狀態(tài)的轉(zhuǎn)換如下圖所示：

需要注意的是OCI在start操作中預(yù)置了3個勾子函數(shù)prestart, poststart, poststop。用于在容器進程，用戶進程啟動前后進行一些定制化的操作。

prestart: 只能在運行時進行調(diào)用，如果調(diào)用失敗需要清除容器進程。prestart會在start命令執(zhí)行后，但還未啟動用戶進程之前進行調(diào)用。對Linux來講，prestart會在容器命名空間創(chuàng)建完成后調(diào)用。 poststart：該hook會在啟動完用戶進程，但start操作還未返回前進行調(diào)用。比如，我們可以通過poststart hook通知用戶容器的進程已經(jīng)啟動。 poststop： 會在容器被刪除但是刪除命令還未返回之前被調(diào)用。

運行時配置（Linux）

由于容器Runtime的配置文件config.json在各平臺下的配置略有不同，本文主要介紹常見的Linux平臺下的配置。

容器Runtime配置主要圍繞元數(shù)據(jù)、資源隔離、資源管理、用戶進程幾個維度展開：

元數(shù)據(jù)主要包括：

- oci的版本信息： ociVersion?

- 容器運行的根文件系統(tǒng)（root filesystem）路徑和讀寫權(quán)限。?

"root": {

? ?"path": "rootfs",

? ?"readonly": true

}?

- hostname配置。?

- 用戶配置

資源隔離（namespace）：

對于Linux來講，OCI支持Linux內(nèi)核支持的7種類型，具體來講如下：

- pid: 保證用戶進程只能看到所在容器內(nèi)的其它進程。?

- network：使容器擁有自已的網(wǎng)絡(luò)棧。?

- mount: 使容器擁有隔離的mount表。?

- ipc: 使容器內(nèi)的進程擁有系統(tǒng)級的IPC資源隔離。?

- uts: 容器可以使用自已的hostname和domainname。?

- user: 使得容器可以對主機和容器內(nèi)的用戶和用戶組進行映射。?

- cgroup：使得容器擁有獨立的cgroup視圖。

資源管理：

- mount：根據(jù)用戶的需求，順序?qū)τ脩舻膾燧d配置項進行掛載操作。每個掛載項包含基本的source, destination配置項。?

- rlimit： cpu，mem等的限制。

用戶進程 ：

用戶進程即process配置項，主要包括環(huán)境變量、安全、權(quán)限控制、OOM管理等內(nèi)容。當(dāng)然還有最重要的用戶進程的配置。

對Linux來講，還要求容器內(nèi)的proc, sysfs, devpts, tmpfs這四個文件系統(tǒng)必須可用。

Linux下config.json配置示例

配置項較多，這里就不列出，感興趣的可以在https://github.com/opencontainers/runtime-spec/blob/master/config.md#configuration-schema-example查看。

容器標(biāo)準(zhǔn)包（Bundle）

容器標(biāo)準(zhǔn)包包含了容器運行的所有環(huán)境依賴，它是保證容器運行一致性的基礎(chǔ)。一個標(biāo)準(zhǔn)的容器標(biāo)準(zhǔn)包包含所需要加載和啟動容器的所有信息。包含兩部分內(nèi)容：

- config.json： 即前文所述的容器運行時配置內(nèi)容。?

- root filesystem: 即前文所述的root.path所代表的位置。

OCI Image規(guī)范

OCI的Image格式規(guī)范是容器ship anywhere的基礎(chǔ), 最終落地時體現(xiàn)為Runtime中的bundle，以此為基礎(chǔ)為用戶提供一致的運行時依賴環(huán)境。該規(guī)范由Docker貢獻，并由社區(qū)維護。該規(guī)范包含manifest, image index 和 filesystem layers三部分內(nèi)容。

- anifest: 對于指定架構(gòu)和OS的容器鏡像， manifest定義了它所依賴的相關(guān)配置信息和對應(yīng)的layer鏡像層信息。?

- image index: 比manifest更高層的抽象，包含了額外的配置信息。?

- filesystem layer: 給出了如何將容器的文件系統(tǒng)進行序列化，如何創(chuàng)建和使用這些layer。我們知道容器的啟動速度可達秒級。主要的原因是我們常見的aufs, devicemapper等均采用了COW(copy on write)的技術(shù)，使得相同鏡像的不同容器實例可以共享bundle，write（修改）的數(shù)據(jù)也是在layter中。

runC

OCI定義了容器的Runtime和鏡像格式兩個核心的規(guī)范，現(xiàn)在有了規(guī)范，還需要一個落地的實體。由此runC誕生了。runC是一個符合OCI規(guī)范的輕量級容器運行時生命周期管理工具，最初由Docker貢獻給社區(qū)，來源于Docker原有的運行時管理部分。Docker也在其v1.11版本以后開始將runC作為自身服務(wù)的一個組件。關(guān)于這一點我們在后續(xù)的文章會里詳細介紹。

功能簡介

我們先看下runC都提供那些功能：

1.[root@breeze ~]# runc -h

2.USAGE:

3. ? runc [global options] command [command options] [arguments...]

4.

5.VERSION:

6. ? spec: 1.0.0

7.

8.COMMANDS:

9. ? ? checkpoint ?checkpoint a running container

10. ? ? create ? ? ?create a container

11. ? ? delete ? ? ?delete any resources held by the container often used with detached container

12. ? ? events ? ? ?display container events such as OOM notifications, cpu, memory, and IO usage statistics

13. ? ? exec ? ? ? ?execute new process inside the container

14. ? ? init ? ? ? ?initialize the namespaces and launch the process (do not call it outside of runc)

15. ? ? kill ? ? ? ?kill sends the specified signal (default: SIGTERM) to the container's init process

16. ? ? list ? ? ? ?lists containers started by runc with the given root

17. ? ? pause ? ? ? pause suspends all processes inside the container

18. ? ? ps ? ? ? ? ?ps displays the processes running inside a container

19. ? ? restore ? ? restore a container from a previous checkpoint

20. ? ? resume ? ? ?resumes all processes that have been previously paused

21. ? ? run ? ? ? ? create and run a container

22. ? ? spec ? ? ? ?create a new specification file

23. ? ? start ? ? ? executes the user defined process in a created container

24. ? ? state ? ? ? output the state of a container

25. ? ? update ? ? ?update container resource constraints

26. ? ? help, h ? ? Shows a list of commands or help for one command

27.

28.GLOBAL OPTIONS:

29. ? --debug ? ? ? ? ? ? enable debug output for logging

30. ? --log value ? ? ? ? set the log file path where internal debug information is written (default: "/dev/null")

31. ? --log-format value ?set the format used by logs ('text' (default), or 'json') (default: "text")

32. ? --root value ? ? ? ?root directory for storage of container state (this should be located in tmpfs) (default: "/run/runc")

33. ? --criu value ? ? ? ?path to the criu binary used for checkpoint and restore (default: "criu")

34. ? --systemd-cgroup ? ?enable systemd cgroup support, expects cgroupsPath to be of form "slice:prefix:name" for e.g. "system.slice:runc:434234"

35. ? --help, -h ? ? ? ? ?show help

36. ? --version, -v ? ? ? print the version

37.

如前文的Runtime介紹中所述，runC提供了生命周期管理、暫停、恢復(fù)、熱遷移、狀態(tài)查詢等操作。具體的細節(jié)在此不再贅述。下面我們通過運行一個容器來演示OCI是如何進行容器管理，提供基礎(chǔ)的原子操作，與上層的管理系統(tǒng)進行解耦的。

示例

我們通過運行一個容器監(jiān)控工具cadvisor的容器來展示整個容器管理過程。

由上文可知，在OCI下我們要運行一個容器，需要做兩個準(zhǔn)備：

1. config.json 準(zhǔn)備

config.json定義了容器運行時的具體配置信息，首先我們利用runC生成一個模板，然后在模板上再進行相關(guān)的修改。

[root@breeze runc]$runc spec?

[root@breeze runc]$ll

total 4 -rw-r--r-- 1 root root 2597 Nov 14 18:31 config.json

為了方便演示，我們簡單修改cadvisor的啟動參數(shù)，將args修改為：

/usr/bin/cadvisor -logtostderr

修改后的config.json為：

{ ? ?"ociVersion": "1.0.0",

? ?"process": {

? ? ? ?..."terminal": false,

?? ? ? ?"args": [

? ? ? ? ? ? ?"/usr/bin/cadvisor",

? ? ? ? ? ?"-logtostderr"

? ? ? ?],

? ? ? ?...

? ? }...?

}

2. bundle 準(zhǔn)備

runC可以使用符合OCI規(guī)范的bundle，前邊提到這個規(guī)范是Docker貢獻的，所以為了簡化過程，我們可以直接利用Docker生成這樣一個bundle。我們在另外一臺部署有Docker的主機上執(zhí)行以下命令創(chuàng)建cadvisor bundle。

[root@breeze runc]$ mkdir rootfs?

[root@breeze runc]$ docker export $(docker create cadvisor:latest) | tar -C rootfs -xvf -?

[root@breeze runc]$ ls rootfs/

bin ?glibc-2.23-r3.apk ? ? ?lib ? ? ?media ?root ?srv ?usr dev ?glibc-bin-2.23-r3.apk ?lib64 ? ?mnt ? ?run ? sys ?var etc ?home ? ? ? ? ? ? ? ? ? linuxrc ?proc ? sbin ?tmp

3. create

完成了準(zhǔn)備工作，我們就可以創(chuàng)建容器了?，F(xiàn)在我們看下當(dāng)前的目錄結(jié)構(gòu)：

[root@breeze runc]$ll

total 8

-rw-r--r-- ?1 root root 2597 Nov 14 18:31 config.json?

drwxr-xr-x 19 root root 4096 Nov 14 18:27 rootfs

在當(dāng)前目錄下執(zhí)行

[root@breeze runc]$ runc create oci-cadvisor?

[root@breeze runc]$ runc list

ID ? ? ? ? ? ? PID ? ? ? ? STATUS ? ? ?BUNDLE ? ? ? CREATED?

oci-cadvisor ? 17921 ? ? ? created ? ? /home/runc ? 2017-11-14T12:38:53.64550602Z?

[root@breeze runc]$ ps -ef|grep cadvisor?

root ? ? 18015 22812 ?0 20:39 pts/0 ? ?00:00:00 grep --color=auto cadvisor

從執(zhí)行輸出可以看到oci-cadvisor容器已經(jīng)create成功，但cadvisor進程還未被拉起。等等，那這個pid(17921)是誰的進程ID？我們來看一下，其實這是runC的init進程。具體我們會在后續(xù)的文章里解釋

[root@breeze runc]$ ps -ef|grep 17921 | grep -v grep?

root ? ? 17921 ? ? 1 ?0 20:38 ? ? ? ? ?00:00:00 /proc/self/exeinit

4. start

oci-cadvisor容器的容器進程已經(jīng)被拉起，接下來需要做的就是把真正的業(yè)務(wù)進程拉起來。結(jié)合前邊的生命周期管理圖，所以可看我們現(xiàn)在需要執(zhí)行start操作。

[root@breeze runc]$ runc start oci-cadvisor?

[root@breeze runc]$ runc list?

ID ? ? ? ? ? ? PID ? ? ? ? STATUS ? ? ?BUNDLE ? ? ? CREATED ? ? ? ? ? ? ? ? ? ? ? ? OWNER?

oci-cadvisor ? 17921 ? ? ? running ? ? /home/runc ? 2017-11-14T12:38:53.64550602Z ? root?

[root@breeze runc]$ ps -ef|grep cadvisor | grep -v grep?

root ? ? 17921 ? ? 1 ?0 20:38 ? ? ? ? ?00:00:00 /usr/bin/cadvisor -logtostderr

現(xiàn)在可以看到oci-cadvisor容器已經(jīng)run起來了。仔細再觀察一下，what? cadvisor進程的pid和前邊runc init的進程pid居然是一樣的? 這是因為runC通過執(zhí)行syscall.Exec(Linux 中的exec)讓用戶進程接管了init進程。

5. exec

現(xiàn)在容器進程也跑起來了，讓我們進到oci-cadvisor去看一看。說進容器里看一看，其實是我們再新起了一個進程，而這個進程的命名空間和容器擁有的命名空間，這樣就可以通過這個進程去查看容器內(nèi)的信息。讓我們sh進去簡單看一下。

[root@breeze runc]$ runc exec -t ?oci-cadvisor /bin/sh?

/ # ps aux PID ? USER ? ? TIME ? COMMAND

? ?1 root ? ? ? 0:00 /usr/bin/cadvisor -logtostderr

? 30 root ? ? ? 0:00 /bin/sh

? 36 root ? ? ? 0:00 ps aux

/ # ifconfig?

lo? ? ? ?Link encap:Local Loopback

? ? ? ? ?inet addr:127.0.0.1 ?Mask:255.0.0.0

? ? ? ? ?inet6 addr: ::1%32577/128 Scope:Host

? ? ? ? ?UP LOOPBACK RUNNING ?MTU:65536 ?Metric:1

? ? ? ? ?RX packets:16 errors:0 dropped:0 overruns:0 frame:0

?? ? ? ? ?TX packets:16 errors:0 dropped:0 overruns:0 carrier:0

? ? ? ? ?collisions:0 txqueuelen:0

? ? ? ? ?RX bytes:1344 (1.3 KiB) ?TX bytes:1344 (1.3 KiB)?

/ # netstat -nltp|grep 8080?

tcp ? ? ? ?0 ? ? ?0 :::8080 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?1/cadvisor

從容器內(nèi)我們可以看到oci-cadvisor擁有的cadvisor進程，我們剛才exec的sh進程。同樣該容器也擁有獨立的網(wǎng)絡(luò)棧。當(dāng)然，這些只是容器的一部分特性。

kill

接下來，我們kill掉oci-cadvisor容器，使其進行stopped狀態(tài)。

[root@breeze oci-cadvisor]$ runc kill oci-cadvisor?

[root@breeze oci-cadvisor]$ runc list?

ID ? ? ? ? ? ? PID ? ? ? ? STATUS ? ? ?BUNDLE ? ? ? CREATED ? ? ? ? ? ? ? ? ? ? ? ? OWNER?

oci-cadvisor ? 0 ? ? ? ? ? stopped ? ? /home/runc ? 2017-11-14T12:38:53.64550

delete

最后，我們將oci-cadvisor從我們的環(huán)境里清理掉，刪除運行時的數(shù)據(jù)（注意bundle仍在）。

[root@breeze runc]$ runc delete oci-cadvisor?

[root@breeze runc]$ runc list?

ID ? ? ? ? ?PID ? ? ? ? STATUS ? ? ?BUNDLE ? ? ?CREATED ? ? OWNER?

[root@breeze runc]$

寫在最后

現(xiàn)在看起來利用runC創(chuàng)建容器，并對其進行管理還是比較簡單，解決了容器最核心、最底層、最基礎(chǔ)的問題。而這離我們的實際需求還差的很遠，想要成為云計算的基礎(chǔ)設(shè)施還有很長的路要走。具體來說主要面臨以下幾個問題。

1. 對大規(guī)模管理的支持較弱。runC只是個命令行工具，不是常駐進程，對于大規(guī)模的編排需求，無法通過網(wǎng)絡(luò)調(diào)用實現(xiàn)。同樣，也無法實現(xiàn)整個容器生命周期的自動化管理。

2. bundle的管理。OCI包含了OCF規(guī)范，但是像我們這樣直接利用原生的bundle來構(gòu)建容器運行時的環(huán)境依賴直觀上來看有以下幾個缺陷：

? - 每個容器都要有自己的bundle，無法復(fù)用（應(yīng)用都有寫數(shù)據(jù)需求），同時帶來的是存儲資源的浪費和啟動速度的下降。

? - 容器的bundle沒有統(tǒng)一的管理，“ship anywhere”的愿望看起來可望不可及。

? - bundle的生命周期管理現(xiàn)在還沒解決。runC的delete操作并不是清理bundle。

3. 網(wǎng)絡(luò)能力弱。容器擁有獨立的網(wǎng)絡(luò)棧，但是還沒有解決容器內(nèi)的業(yè)務(wù)進程的通信需求，“世界那么大，還是要出去看看的”。

雖然總有不足的地方，但慶幸的是已經(jīng)邁出了第一步。OCI（Open Container Initiative）組織一成立便得到了包括谷歌、微軟、亞馬遜、華為等一系列云計算廠商的支持。制定的容器運行時和鏡像規(guī)范現(xiàn)已經(jīng)成為一個可靠的基礎(chǔ)標(biāo)準(zhǔn)。OCI通過開源的方式以runC落地，逐步脫離Docker的控制范圍。在runC的基礎(chǔ)上，允許和鼓勵多樣化的容器解決方案，這為廣大的云廠商和我們這些開發(fā)者提供了更廣闊的發(fā)揮空間，不斷促進容器生態(tài)的持續(xù)創(chuàng)新，服務(wù)各行各業(yè)。

參考文獻

https://blog.docker.com/2017/07/oci-release-of-v1-0-runtime-and-image-format-specifications/

https://github.com/opencontainers/runc

runC: The little container engine that could

https://www.opencontainers.org/

藍鯨智云簡介

騰訊藍鯨智云（簡稱藍鯨）軟件體系是一套基于PaaS的技術(shù)解決方案，致力于打造行業(yè)領(lǐng)先的一站式自動化運維平臺。目前已經(jīng)推出社區(qū)版、企業(yè)版、公有云版，歡迎體驗。

如有需要請聯(lián)系藍鯨客服QQ:800802001，有關(guān)藍鯨搭建布署以及使用方面的疑問，可加入QQ群討論交流：QQ群(495299374)

藍鯨智云招募合作伙伴

合作共贏，是騰訊文化中重要的一部分。藍鯨智云團隊計劃在全國范圍內(nèi)，大力發(fā)展生態(tài)體系，尋找優(yōu)質(zhì)的合作伙伴，共創(chuàng)運維領(lǐng)域的新局面。我們希望為解決方案供應(yīng)商、集成商、服務(wù)商、應(yīng)用軟件開發(fā)商、咨詢機構(gòu)等提供更多的增值服務(wù)。

招募詳情，請點擊訪問藍鯨官網(wǎng)：

http://bk.tencent.com