在“選擇Docker還是Rocket做容器？為何不選擇兩個？”一文中，曾提到CoreOS的創(chuàng)始人Polvi和Docker的創(chuàng)始人Sonomon都認(rèn)為，Rocket和Docker沒有競爭性。Docker平臺是一個產(chǎn)品，Rocket是一個組件。企業(yè)可以選擇Docker替代Cloud Foundry，也可以使用Rocket構(gòu)建Cloud Foundry。CoreOS在發(fā)布Rocket時就指出，Rocket的出現(xiàn)是因為有些人需要一個更“純凈”的容器。換句話說，Rocket算是“App Container Specification”的標(biāo)準(zhǔn)實現(xiàn)。本文作者從“App Container Specification”入手，分析了Rocket和Docker在技術(shù)實現(xiàn)上的不同。以下為原文：

Docker和Rocket，殊途同歸

首先，對于那些把Docker與Rocket放在一起比較的人，我想勸你們首先適當(dāng)?shù)卣{(diào)查一下。如果有這樣兩個軟件：一個已經(jīng)有1年多的歷史，作為一個開源項目由全世界上千的開發(fā)者共同參與，并且已經(jīng)或即將在實際的生產(chǎn)環(huán)境中被部署、測試;而另一個軟件則是“新鮮出爐”的。如果這個較成熟的軟件不是特別爛的話，那么很有可能它就是贏家。

所以，將Docker0.1.1與最近預(yù)發(fā)行的Rocket拿來比較會更公平一些。此外， CoreOS的CTO Brandon Philips也多次強(qiáng)調(diào)，Docker的一些功能將不計劃加入到Rocket中——不只是現(xiàn)在，也許永遠(yuǎn)不會。為什么?因為Rocket項目的重點，至少目前的情況——不是重新實現(xiàn)Docker。Rocket是 “App Container Specification”的實現(xiàn)，因此，想比較兩者，最好比較“App Container Specification”和最初的Docker清單或者Docker實現(xiàn)的其它規(guī)范。

以下的比較都將基于以上共識：

Systemd

通常情況關(guān)于Rocket的討論最多的話題是systemd-spawn或者是 systemd 。 CoreOS已將systemd作為他們Linux發(fā)行版的init系統(tǒng)。他們可以接著使用Init 腳本或者upstar，但是他們選擇使用了將來會成為所有主流Linux版本標(biāo)準(zhǔn)的init系統(tǒng)。實話說我并沒有關(guān)于systemd獨(dú)到的見解，只是讀過Lennart等人的一些文章。對于CoreOS來說，將systemd作為新的Linux發(fā)行版的init系統(tǒng)的是不明智的。另外，CoreOS已經(jīng)獲得了我的信任，我對此深信不疑。你可能會拋出 btrfs與我爭論，但是， 那個會很快消失，我希望它會被修復(fù)，或者被其他可靠的方案替換。畢竟穩(wěn)定性比功能更重要。

好吧，讓我們回到問題上來。其中systemd做的或者說能夠做的事情多是進(jìn)程管理。你可能會認(rèn)為，systemd解決這個問題的方式，多少有些重疊了服務(wù)、進(jìn)程管理的概念，并且將一些原本能在PID1之外很簡單的任務(wù)復(fù)雜化了，但因為CoreOS是systemd的忠實用戶，如果使用其它工具來實現(xiàn)反而顯得奇怪。

此外，據(jù)Brandon介紹，Rocket的最初實現(xiàn)使用systemd-nspawn的原因是他們想用systemd，Systemd-naspawn 已經(jīng)實現(xiàn)，而且正在做他們想做的東西，所以它有助于項目的開始。坦率地說，在0.1.1版本，我并不關(guān)心他們使用的技術(shù)，沒準(zhǔn)以后都會變的，因為Rocket的設(shè)計是可插拔的。如果你不喜歡systemd-nspawn，可以用你自己的stage1實現(xiàn)，Rocket已經(jīng)提供了詳細(xì)的命令行參數(shù)。

另外需要指出的是，那些認(rèn)為想使用Rocket，就必須運(yùn)行systemd的人就完全錯了。Rocket根本不需要systemd。它也能與其它init系統(tǒng)，如SysV或upstart配合工作。我在upstart上測試了Rocket，沒有遇到任何問題。Rocket僅僅是“重用”了systemd和systemd-nspawn，處理stage1和stage2。

App Container

有些人可能還沒有準(zhǔn)確地理解“App Container Specification”。他們一直在說systemd，并說Docker是如何好，不需要在容器中用systemd運(yùn)行進(jìn)程。Docker通過后臺進(jìn)程管理單進(jìn)程的容器。Docker后臺進(jìn)程未被寫成一個進(jìn)程管理工具，當(dāng)你的容器停止時，這種設(shè)計的弊端就會顯現(xiàn)出來。你最終要通過主機(jī)或者容器中的進(jìn)程管理工具來應(yīng)付它。如果你還沒有經(jīng)歷過這樣的事，要么你可能是幸運(yùn)的，又或者沒有在環(huán)境中運(yùn)行大量的容器。

我們需要進(jìn)程管理，或進(jìn)程管理提供的某些功能。如果讀過“App Container Specification”，你會理解這點的。我將其中一部分摘錄如下：

容器執(zhí)行一個或多個應(yīng)用程序，共享PID namespace、network namespace、mount namespace、IPC namespace和UTS namespace。執(zhí)行之前，每個應(yīng)用程序?qū)㈤_始轉(zhuǎn)為(比如chroot)自己特有的讀寫根文件系統(tǒng)。容器的定義是，包含一系列應(yīng)該在一起啟動的應(yīng)用，以及應(yīng)用與整個容器的隔離器。

上面明確提到了幾個進(jìn)程共享Linux的命名空間。換言之，Kubernetes的Pod與以上對容器的定義很像，我不知道這是否與CoreOS正在積極參與Kubernetes的開發(fā)有什么關(guān)系。但Kubernetes Pod是一組容器，而不是容器中的一組進(jìn)程。這讓你能從多個Docker鏡像組成一個Pod中獲益。這是App Container Specification定義了 依賴關(guān)系的地方，所以你的容器可以依賴于其他容器，因此通過 Stage0創(chuàng)造的最終容器runtime可能是 這樣的。

現(xiàn)在，你已經(jīng)在容器中運(yùn)行多個進(jìn)程，其中一些可能是后臺進(jìn)程，并且可能需要被監(jiān)督，你需要一個進(jìn)程管理器。至今我用過最好的管理器是runit，但話說回來，當(dāng)你已經(jīng)積累了大量關(guān)于systemd的經(jīng)驗時，你為什么會想要寫runit腳本或使用其他管理器?如果我是CoreOS，也會做出一樣的決定——systemd。

Docker和命名空間

現(xiàn)在，讓我們回到Docker。Docker一直倡導(dǎo)一個容器運(yùn)行一個進(jìn)程�？偟膩碚f，我同意這一點，因為Linux容器主要是為了實現(xiàn)主機(jī)的進(jìn)程隔離，而每個容器運(yùn)行一個進(jìn)程，會給你帶來更多的靈活性和復(fù)合型，獨(dú)立的更新、回滾等，操作更加簡單。然而，當(dāng)你創(chuàng)建一個新的Docker容器或事實上LXC容器，容器被重新分配一套由libcontainer提供的全新的Linux命名空間。實話說，我覺得這有點浪費(fèi)。于Docker還挺有意義，因為你要在一個容器中運(yùn)行一個單獨(dú)的進(jìn)程，并且如果你想提供更通用的進(jìn)程環(huán)境，來覆蓋大多數(shù)的用例，你可能需要libcontainer高效提供的大量可用命名空間。

只為一個進(jìn)程創(chuàng)建一組命名空間，增加了內(nèi)核大量的額外管理工作。如果你的主機(jī)上運(yùn)行了很多的容器，可能會出現(xiàn)內(nèi)核某些方面的瓶頸。你可能會說開銷很小，但是為什么非要過度占用內(nèi)核呢?

因此，為了節(jié)省開銷，可以共享進(jìn)程之間的命名空間。但是有個問題，如果你開始共享命名空間，并且創(chuàng)建它的容器已經(jīng)終止，它會刪除共享命名空間的所有的進(jìn)程。Kubernetesde在設(shè)計Pod時，就考慮到這個問題了。 Kubernetes Pod中第一個被創(chuàng)建的容器，會被從internal/24 VLAN中分配一個IP地址，該IP地址也被Pod內(nèi)共享一個network namespaces的容器共享。

你可以看到這里微妙之處。每當(dāng)“網(wǎng)絡(luò)”創(chuàng)建的容器停止時，他會撤銷Pod中所有的其它容器，因為沒有可以共享的命名空間了，所以需要從頭創(chuàng)建新的Pod，重新分配IP。更糟糕的是，你的連接也沒了。所以，當(dāng)你的容器停止后，不能自動重啟它們。我相信通過觀察Docker銷毀容器的過程，可以找到解決辦法，但是，那有些繞。所以，如果你想要在Docker容器中運(yùn)行多個進(jìn)程，你會需要一個進(jìn)程管理工具。

監(jiān)管日志

最后，講一下日志。日志由管理進(jìn)程負(fù)責(zé)。通常這個進(jìn)程管理器通過捕獲進(jìn)程的stdout/stderr，并將其記錄到一個日志�！癆pp Container Specification”上有關(guān)日志的說明如下：

應(yīng)用程序應(yīng)登錄到stdout和stderr。容器執(zhí)行程序負(fù)責(zé)捕捉和不斷輸出。

對于CoreOS來說，systemd似乎是一個顯而易見的選擇。Runit在這方面做得很好，但這又回到我已經(jīng)在前面提到的，專業(yè)上來講，這是不必要的額外工作。

Docker的做法是，把近六個月的日志記錄到日志插件prosposal文檔中。雖然還未實現(xiàn)，但考慮到這是由Michael Crosby提出的，我對它有信心。

用戶體驗和使用經(jīng)驗

大家對Rocket的另一個不滿在于用戶體驗。但請記住，Rocket最新發(fā)布的版本是0.1.1。你知道第一輛車的樣子嗎?它看起來是這樣的。這當(dāng)然不是最好的用戶體驗，然而這是朝著法拉利和保時捷的第一步.

但同樣也是最重要的是，Rocket是App Container Specification的實現(xiàn)，不會強(qiáng)加給你任何東西。同樣，Dockerfiles、Docker daemon以及其它你想要的實現(xiàn)，都只能靠你自己了。甚至是Stage1!你想讓Docker作為管理器?破解它，并把它作為參數(shù)傳遞給rkt run，成為一個Stage1進(jìn)程。我都能想象在未來，CoreOS很可能會實現(xiàn)一些很棒的工具，甚至提升Ops 和Devs的用戶體驗。但那些工具可能會作為單獨(dú)的項目，而不是Rocket的核心部分。在這一點上我認(rèn)為最重要的是項目的穩(wěn)定。

結(jié)束語

我要十分明確地說，我喜歡Docker，并且一直在關(guān)注Docker。這篇博文并不是在討論Docker或Rocket好與壞。大多數(shù)人都是沒有讀過“App Container Specification”，才會總是要比較這兩者的好壞。

最后，強(qiáng)烈建議你去了解一下Docker和Rocket。如果你喜歡用C編碼，你也應(yīng)該試試LXC或其它類似的技術(shù)。還有很多事情可以做，很多機(jī)會，讓你成為目前這個行業(yè)巨變的一部分!

在不久的將來，云計算一定會徹底走入我們的生活，有興趣入行未來前沿產(chǎn)業(yè)的朋友，可以收藏云計算，及時獲取人工智能、大數(shù)據(jù)、云計算和物聯(lián)網(wǎng)的前沿資訊和基礎(chǔ)知識，讓我們一起攜手，引領(lǐng)人工智能的未來！

標(biāo)簽： linux 大數(shù)據(jù) 腳本 開發(fā)者 網(wǎng)絡(luò) 云計算

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。