摘要：在被納入后，與之爭日趨白熱化。一如微軟曾經試圖通過在中安裝來排擠，現在正在嘗試將融入到，以此來打擊，，和。如同微軟確確實實提升了的性能。瀏覽器突出了微軟的優勢，所以他們在年內都沒有繼續開發了。

在 Swarm 被納入 Docker 1.12后，Swarm 與 K8S 之爭日趨白熱化。本文作者 Adriaan de Jonge 身為 Xebia CTO ，專精 DevOps 及持續交付，曾為 Docker 搖旗吶喊三年的老司機，如今開始易幟。

現在即使是最酷的產品也綁定于某個特定供應商。不管在過去的三年里，我曾多么熱衷 Docker，但是現在，綁定的供應商開始動搖 Docker 在我心中的地位了。而目前他們兩者之間的競爭還在持續。又或許在這個過程中會出現一個更好的選擇也說不定。這篇文章就是帶領大家來了解一下 Core OS 的 rkt（讀音按照“rock－it”來），以及告訴你為什么從現在開始要了解 rkt。

如果你跟我經歷相似，你可能因為對 Docker 充滿熱情而被它的一些缺點蒙蔽了眼睛。不要誤解我，我并不是說 Docker 不好。我的意思是它并沒有那么完美。所以接下來讓我們來看一下它的一些不足之處吧。

一旦一家公司意識到它有著自己的壟斷權，他們就會開始做出壟斷行為。一如微軟曾經試圖通過在 windows 中安裝 Internet Explorer 來排擠 Netscape，現在 Docker 正在嘗試將 Swarm 融入到 DockerCore，以此來打擊 Kubernetes，Mesos，Marathon 和 Nomad。

Docker 確實有簡化 Swarm，使它輕松被廣大 Docker 用戶接受的優點。如同微軟確確實實提升了 Internet Explorer6.0的性能。MSIE6瀏覽器突出了微軟的優勢，所以他們在5年內都沒有繼續開發了。

想象一下 Docker 跟 Swarm 結合的結果是什么……想象一下你的下一個任務就是移動到 Docker：當需要選擇一個最好的調整程序時，在你選擇 Kubernetes，Mesos／Marathon，Nomad 之前，你首先要理清楚的就是 Swarm 的不足之處是在哪里。已經有了 Swarm，那么為什么在這個基礎上還要安裝其他的調度程序呢？

我希望 Docker 能夠提升 Swarm 的性能，在修改這一點上，希望 Docker 做得比微軟（修改 MISE）要好。但是即使是現在，Kubernetes 在很多方面也都是領先于 Swarm 的。隨著 Kubernetes 的持續開發，Swarm 已經遠遠落在后面。雖然 Docker 能夠讓人輕松使用調度程序，但是在我看來，他們還是應該跟 Docker 核心分開。

Docker 的核心就是 Daemon 程序，這個程序是 Docker 開始運行的起點。Docker 可執行文件僅僅只是一個 REST 代理，這個代理要求發請求給 Docker daemon 來完成它的工作。Docker 的評論家指出，這很不符合 Linux 的方式。

它的痛點在于你是否使用類似 systemd 這樣的初始化系統。因為 systemd 并不是針對 Docker 設計的，所以當你嘗試開啟一個 Docker 程序的時候，你其實也就是開啟了一個 Docker 代理程序，而這個代理程序向 Docker daemon 請求開啟真正的 Docker 容器。在這里還是有一個風險的，就是當 Docker 容器還在運行的時候，Docker 代理運行失敗了。在這樣的情況下，systemd 得出結論，程序已經停止，并且重啟 Docker 代理——于是創建第二個容器（是的，你還是可以繼續處理工作，但是已經是無關緊要的了）。

大概一年之前，我把 systemd 當成是一個簡單的 Docker 調整程序來調查。我遇到了同樣的危機，或者說將 Docker 和 systemd 結合的問題。那時候，我覺得這些是 systemd 的原因，而不是 Docker 的缺點。我那時候還想，會不會 systemd 并不是針對“Docker 本地”來設計的。

現在，我才了解到，可能 Docker 才是那些問題的癥結所在，而不是 systemd 的問題。就像上文中提到的，Docker 并不符合 Linux 的風格，而也正因為如此，Linux 工具跟 Docker 也協作得不是很好。所以是誰錯了呢？是新來的 Docker，還是已經存在了多年的 Linux 工具呢？CoreOS 的 CEO，Alex Polvi說：“Docker 的架構從基礎上就有瑕疵。”

Docker 最好的功能之一就是 Dockerfiles 的引入，你可以在構建 Docker 鏡像時保持版本控制。這里唯一的問題是在 Docker 的路標中 Dockerfile 語法凍結很長時間了。這就意味著在過去的一年半以來 Dockerfile 格式并沒有依據社區的良好建議而進化。

當然，在某種程度上，我們需要一個穩定的格式，但是只有當格式完全成熟的時候。在這里舉個例子，就是 Dockerfile 缺乏的地方，考慮到 Kelsey Hightower 在他博客《12 Fractured Apps》中提到的：“記住，我們要運送artifact，而不是編譯環境。”

事實就是，Dockerfile 格式并不能很好地支持這個區別。考慮到要構建一個可執行的 Golang：可執行的結果可能只有兩百萬字節大小，但是創建的環境有幾百兆字節。當然，你也可以在本地系統上構建鏡像。你無法利用 Docker Hub 中的自動化構建環境通過一個簡單的 Dockerfile 優雅的構建出一個小的 Golang 鏡像。社區有個關于擴展 Dockerfile 格式的提議就能很好的支持上述原理，但是由于 Dockerfile 格式的凍結該提議也被擱置了好幾年。

簡而言之，rkt 現在給 Docker 提供了更好的解決辦法。它擁有一套更加 Linux 的架構。這個強勁的對手會保持自己的壟斷作風。

具體一點的答案就是：2014年年底，Core OS 宣布，這個有競爭力的容器平臺 Rocket（后來簡寫并改名成 rkt）的誕生。雖然 rkt 在發布之后最初幾周里得到了很高的關注度，但是后來卻銷聲匿跡了。Core OS 還是將 rkt 作為 Docker 的可替代工具來開發，后來在2016年2月 rkt1.0版本發布的時候才回歸大眾視野。

現在 Docker 宣布在 Docker Engine1.12中已經包含了 Swarm，那么是時候正視 rkt，讓它作為 Docker 的可執行方案了。那在未來它會替代 Docker 嗎？從 Docker 切換到 rkt 難度大嗎？

讓我們來看一看 rkt 尋找答案吧。

假設現在你想要用 rkt 來替代你的 staging 以及產品系統，同時又想讓你所有的開發系統都繼續運行......在這個案例中，你可以只在你的運行系統上將 Docker 替換成 rkt。但嚴格來說，這并不是一個隨隨便便的替換。畢竟，架構是不一樣的——但是我們會努力往一樣的方向發展的。另一方面，為了在 rkt 上運行 Docker 容器而去學習新的命令行指令也不會太難。
在你最愛的云提供商上打開 Core OS 實例，并打出以下代碼：

或者用你最愛的 Docker 鏡像來替代 nginx。在底層，rkt 將 Docker 轉換到ApplicationContainer（appc）格式。

這也就意味著你不需要 Docker 來運行 Docker 鏡像了。而且也意味著你可以重新使用 Docker 創建的東西，在這個過程中不需要忍受遷移帶來的傷痛——而不是學習 rkt 的命令行語法。

讓我們來一睹命令行的單個部分：

如果你沒有忽略這部分，那么rkt就會拒絕啟動你的鏡像，因為它找不到簽名（.asc file）來確認 Docker 鏡像的完整性。rkt 默認設置下是安全創建的。在這個例子中，這也就意味著你可以通過提供合適的簽名來省去一些命令的輸入。

就比如在 Docker 中，你需要明確地暴露端口到外部。不像 Docker，rkt 端口已經被命名，而不是標記數字。如果這是一個原生的 rkt 鏡像（或者需要精確的appc），那么它讀起來很可能是這樣的：

然而，既然 Docker 沒有命名的端口，那么被暴露的端口就會被自動命名為-。這也就意味著，如果你只能顯示暴露端口的話，就使用 Dockerfile 中的 EXPOSE 關鍵字：

鏡像期望存儲在默認的 Docker 倉庫中（Docker Hub）。除了這個例子，還有個更長的 URL 指向另一個 Docker 倉庫（docker://）或者包含鏡像的通常的 web 網站（https://），但是之后你就不再運行 Docker 鏡像了。

在 rkt 中是沒有 daemon 進程的。Rkt 命令行工具做了所有的工作。來看從CoreOS 網頁借鑒的圖片：

跟 Docker 不同，如果你使用 systemd 來啟動 rkt容器，你實際上就是在監控容器進程，而不是監控代理程序，然后由代理程序連接到 daemon，并由 daemon（直接或者間接——依賴于你的 Docker 版本）來啟動容器。

另一方面，你不能這么寫：

像 Docker 代理一樣 daemon 化進程。而且必須要運行一個初始系統來 daemonize 進程。比如，你可以這樣運行：

同樣，你無法從遠程機器（比如 Docker 代理）運行 rkt 命令行。再有，你也可以將它作為安全功能考慮。

現在，rkt 允許你使用 Application Container（appc）或者 Docker 鏡像。在不遠的將來，Open Container Initiative（OCI）格式將會被加入，我們會朝那個方向走的。

容器鏡像擁有開放標準的好處就是，它允許開源社區提供多種創建鏡像的方法，不僅僅局限于 Dockerfile 格式。

構建 appc 鏡像的默認方式就是使用命令行工具，叫做 acbuild。說實話，喜歡 acbuild，還是喜歡 Dockerfile 格式，這真的只是個人口味問題。
好處就在于它天生就跟 Linux 原則距離更近。

而最大的好處就是開放格式允許可替代的構建機制。比如，考慮到全能創建工具 dgr 或者 Golang 指定創建工具 goaci。

一旦 OCI 格式可用，就會有更多可能，但是現在，我們還是需要等待。

如果你現在就想要開始使用 rkt，那么你在使用道路上會有一些磕絆。雖說你可以在磕磕絆絆之中找到方向，但是不得不承認的是，在我寫這篇文章的時候（也就是現在），說 rkt 一切都已經準備妥當還為時過早。不過，我相信，只是時間問題。

就像在上文中提到過的那樣，rkt 支持 Docker 鏡像格式，而且跟 Docker 倉庫互相溝通聯系。如果你能夠堅持使用 Docker 鏡像格式，那么相信它，它會運行得很好。

但是，如果你是個吹毛求疵的人——像我似的——你就沒辦法容忍在使用 Docker 的時候，你還無法使用命名的端口。所以，你就會想要使用 appc 容器。appc 容器是可以自由使用的。

但是你要怎么上傳 appc 容器給 Core OS 解決方案到 Docker Hub——quay.io？我自己是還沒有找到這樣的方法。

關于 appc 格式最好的一點就是，它并不是跟特定的 Docker 倉庫相聯系。反而，你可以在普通 http 服務器上，或者是在本地文件系統宿主鏡像。你可以豐富包含元標簽的 HTML 文件的原數據。

一旦 OCI 鏡像格式達到，rkt 才有可能真正 take off，變得足夠成熟，準備足夠充分來被接受，作為每個人心中的標準——包括 Docker。

為了在產品中運行容器，在某種程度上，你需要一個調度程序來控制運行什么程序，在哪里運行。目前，Kubernetes 和 Nomad 都支持 rkt。但是這種支持并沒有大家期望得那樣成熟。

Kubernetes 支持 rkt 是從積極開發的狀況下來說的。它有最小文檔以及一系列已經知道了解的問題。Nomad 支持標記試驗，但是不支持動態端口。

好在 rkt 不僅僅支持 CoreOS。你可以在多個平臺上，比如分布式 Linux，Debian，Ubuntu 以及 Fedora 上安裝 rkt。

如果你想在你的 Apple／Windows 開發機上運行 rkt，你當然可以在像 virtualBox 這樣的虛擬層運行。但是，這些設備沒有 Docker 的工具盒那么好用——特別是最新的 Docker Mac／Windows 測試版，這也就給了你一種 native 的感覺。要承認的是，這可能就是 rkt 架構上的缺點，在這點上，可執行的 rkt 已經做了所有的工作，而不只是作為一個 REST 代理。

如果你想要在非 Linux 機器上開發，最好的辦法就是仍然在本地用 Docker 鏡像進行處理，并且在你轉到 staging 和生產的時候，要將這些轉化為 appc 鏡像。

雖然這么說還很早，但是 rkt 現在已經變成 Docker 的一個可執行方案。如果你不需要 Kubernetes，Nomad 的動態功能，以及更多像 systemd，fleet 這樣的靜態選項，來滿足你的調度準則，那么你現在就可以將你的 staging 和產品服務器轉移到 rkt 了。

相信再有多一點的時間，Docker 和其它容器平臺間會有真正的互操作性，以 OCI 鏡像的形式出現。同時，允許 Kubernetes 和 Nomad 支持 rkt 的發展，然后 Docker 會跟 rkt 容器平臺會一樣可交換。

那現在有必要摒棄 Docker 嗎？不，沒有必要。除了這篇文章中提到的一些 Docker 的缺點，Docker 還是個有著很多開發工具，調度程序，編排的巨大生態系統創新平臺。重要的是，我們要有足夠多的選項。現在 Docker 有很多的競爭對手來保持清醒。

原文鏈接
保護知識產權，轉載聯系我們哦。