下一代容器架構已出，Docker何去何處？看看這裡的6問6答！！

• 2019 年 11 月 5 日
• 筆記

作者： Lateautumn4lin

來源：雲爬蟲技術研究筆記

我猜很多人一看這個標題已經感覺很懵逼了，什麼？下一代容器都出來了，我還沒學Docker呢！！！

咳咳~~在這裡我給大家做一個保證，下一代容器目前也只是各個公司在測試階段，Github上面也有很多Issue，因此，大家可以放寬心，下一代容器離我們還很遠呢~

切入正題：

我們今天討論的是《下一代容器架構已出，Docker何去何處？》

其實就目前來說，下一代容器架構可以約等於≒

Podman+Skopeo+Buildah

其實這半年來很多自媒體都在鼓吹新的容器架構，吹噓將要很快的替代Docker。但是很少人討論新的架構和老的架構的區別，以及目前遷移的可能性等等等等。。。這些都是擺在企業面前去接觸新架構的大山。所以，我們今天不做具體的新容器架構實戰，我們只回答以下幾個問題。

下面開始，我要做一波自問自答了

Q1

什麼是Linux容器以及它如何工作？

一句話回答：就像港口的集裝箱

（1）linux容器又名LXC(Linux Container)，我們要形象的理解Linux容器的話，我們可以把它想像成集裝箱，而操作系統就像港口。集裝箱的特色，在於其格式劃一，並可以層層重疊。它是一種內核輕量級的操作系統層虛擬化技術。

（2）容器通過四個主要組件工作：名稱空間（namespaces），控制組（cgroups），映像（images）和用戶空間工具例如Docker。Linux系統上的所有進程都從init進程fork派生。Linux容器的一個主要組件是在新的命名空間下創建一個新的init進程。因此，僅憑名稱空間（namespaces），我們就有能力生成一個進程樹並操縱一些底層系統資源，而不會影響主機系統。那另一個問題，是什麼來阻止新產生的容器過度使用主機的資源呢？使用cgroups，我們可以限制CPU使用率，內存，磁盤等等，這樣我們就能夠保證我們創建的容器在合理使用的範疇內。最後映像（images）和用戶空間工具就是幫助我們更便捷的使用LXC。

Q2

什麼是OCI、CRI、CNI？

一句話回答：接口抽象化

（1）回答這個問題之前呢？需要先說一下容器發展的歷史：一開始是Docker.io公司推出了容器Docker，但其實容器並非只要Docker，這樣帶來一個問題是很多做容器編排的公司都要去兼容所有的容器類型。於是後來北美的一些大廠就開始討論聯合指定一個統一的規範，以後做容器的公司都要以這個為準，這個標準就是 Open Container Initiative（OCI）。

（2）CRI是OCI標準中的其中一個，「容器運行時標準」，它定義了容器在硬盤上存儲的方式，用於描述容器中應用程序的 JSON 文件和如何創建和運行容器。Docker.io貢獻了 libcontainer，並且提供了 runc 作為 OCI 運行時規範的默認實現。

（3）CNI則是CNCF旗下的一個項目，由一組用於配置Linux容器的網絡接口的規範和庫組成，同時還包含了一些插件。CNI僅關心容器創建時的網絡分配，和當容器被刪除時釋放網絡資源。

Q3

新容器架構是什麼樣的？

一句話回答：新時代容器「三兄弟」

就像開頭我們說的一樣，新容器架構是Podman+Skopeo+Buildah，這裡我們一一介紹這些工具：

（1）Podman： Podman 原來是 CRI-O 項目的一部分，後來被分離成一個單獨的項目叫 libpod。Podman 的使用體驗和 Docker 類似，不同的是 Podman 沒有 daemon。以前使用 Docker CLI 的時候，Docker CLI 會通過 gRPC API 去跟 Docker Engine 說「我要啟動一個容器」，然後 Docker Engine 才會通過 OCI Container runtime（默認是 runc）來啟動一個容器。這就意味着容器的進程不可能是 Docker CLI 的子進程，而是 Docker Engine 的子進程。Podman 比較簡單粗暴，它不使用 Daemon，而是直接通過 OCI runtime（默認也是 runc）來啟動容器，所以容器的進程是 podman 的子進程。這比較像 Linux 的 fork/exec 模型，而 Docker 採用的是 C/S（客戶端/服務器）模型。

（2）Skopeo：Skopeo是一個工具，允許我們通過推，拉和複製鏡像來處理Docker和OC鏡像。我們都知道我們可以通過Docker來拉取遠程的鏡像。但是我們不能在本地直接查看遠程鏡像的詳細信息，必須要先拉到本地才行，而Skopeo就解決了這樣一個痛點。而它還有一個優點是是它不需要任何守護進程的協助來完成任務。

（3）Buildah： Buildah用來構建OCI圖像。雖然Podman也可以用戶構建Docker鏡像，但是構建速度超慢，並且默認情況下使用vfs存儲驅動程序會耗盡大量磁盤空間。它類似於Dockerfile，但更優秀的地方是它不需要依賴其餘的守護進程，它能支持非Dockerfile的構建文件。

所以，新容器架構運行方式就是這樣：Buildah構建容器，Podman運行容器，Skopeo傳輸容器鏡像。這些都是由Github容器組織維護的開源工具（github/containers）

Q4

Docker模型和Podman模型的區別？

一句話回答：C/S（客戶端/服務器）模型和fork/exec模型

我們主要對比Docker和Podman的模型區別：

（1）Docker主要使用C/S（客戶端/服務器）模型

（2）Podman主要使用fork/exec 模型

那我們想想這兩個模型的區別：

（1）fork/exec模型知道某個容器進程到底是誰啟動的，因為都是它的子進程啊！

（2）如果我們使用Namespace或者Cgroup對Podman 做一些限制，那麼所有創建的容器都會被限制，因為都是它的子進程啊！

（3）可以做一些黑科技，進程通信？進程XX，因為都是它的子進程啊！

好吧，其實區別就是在於C/S（客戶端/服務器）模型和fork/exec模型的區別，這個知識點大家都是具體查找其他的資料，總之，我們可以做出各種黑科技。

Q5

怎麼從老架構遷移到新架構，有哪些風險？

一句話回答：慎入！！！

這部分我們主要講給那些使用自建容器編排集群的開發者將講（因為要排除一些開發者直接使用GKE，EKS之類現成的編排平台，就不好改雲平台的底層架構），首先，在使用方面，基礎平台之上的使用人員可能感受不是很大，畢竟Podman號稱高度匹配Docker命令，所以單純的替換CRI的話可能是對於資源消耗以及容器啟動速度都是有明顯加成的，這個是優點。但是，換個角度想，我們要是全部都按照新架構替換的話，這裏面的風險就很難預測了。舉幾個例子：Podman在拉取推送鏡像時存在同一鏡像digests 改變的情況；使用Docker Compose做部署的時候部署文件怎麼修改？特定的指令怎麼對接？這些問題都是很需要時間和人力去推動的，所以，在新架構還沒有推出穩定的版本之前，最好還是不要遷移，當然，如果你是新進場的雲試驗者，果斷上吧！

Q6

未來的趨勢會是怎麼樣的？

一句話回答：新時代容器是可期的！

未來的趨勢，依我個人的觀點，新容器的架構會慢慢的蠶食Docker代表的舊架構，原因如下：

（1）Docker本身的設計模式的限制，不能很好的做軟件集成；

（2）越來越多的CRI組件推出，在性能上以及資源消耗方面都勝過Docker;

（3）Podman等工具設計出來的時候就是本着服務於K8S的目的，所以他們和K8S貼合的無疑會更緊密，雖然這些工具目前有着這些那些的問題，但是誰說Docker剛推出的時候沒有問題了，只是我們入場的早晚罷了。2018是K8S的元年，Google等大廠都開始擁抱K8S，所以未來，新時代容器是可期的！ 以上就是我關於下一代容器架構的想法，所以大家也該多多少少明白以後的雲容器發展趨勢了。所以這裡的總結呼應上文，雖然下一代容器架構離我們還很遠，但是別妄想了，快點抓緊時間學，比別人多了解一點是一點啊！！！