三年後，咱們從 Docker 轉到了 RKT

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

如今即便是最酷的產品也綁定於某個特定供應商。無論在過去的三年裏，我曾多麼熱衷 Docker，可是如今，綁定的供應商開始動搖 Docker 在我心中的地位了。而目前他們二者之間的競爭還在持續。又或許在這個過程當中會出現一個更好的選擇也說不定。這篇文章就是帶領你們來了解一下 Core OS 的 rkt（讀音按照「rock－it」來），以及告訴你爲何從如今開始要了解 rkt。

Docker 怎麼了？

若是你跟我經歷類似，你可能由於對 Docker 充滿熱情而被它的一些缺點矇蔽了眼睛。不要誤解我，我並非說 Docker 很差。個人意思是它並無那麼完美。因此接下來讓咱們來看一下它的一些不足之處吧。

Docker 愈來愈像之前的 Microsoft

一旦一家公司意識到它有着本身的壟斷權，他們就會開始作出壟斷行爲。一如微軟曾經試圖經過在 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 的架構從基礎上來看就是有瑕疵的」

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 建立程序，陷在了第二個階段

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

固然，在某種程度上，咱們須要一個穩定的格式，可是隻有當格式徹底成熟的時候。在這裏舉個例子，就是 Dockerfile 缺少的地方，考慮到 Kelsey Hightower 在他博客《12 Fractured Apps》中提到的：「記住，咱們要運送artifact，而不是編譯環境。」

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

那麼，rkt 是如何緩解這個情況的？

簡而言之，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 可以運行 Docker 鏡像

假設如今你想要用 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 沒有命名的端口，那麼被暴露的端口就會被自動命名爲<number>-<protocol>。這也就意味着，若是你只能顯示暴露端口的話，就使用 Dockerfile 中的 EXPOSE 關鍵字：

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

Rkt 有着更加簡單的架構

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

跟 Docker 不一樣，若是你使用 systemd 來啓動 rkt容器，你實際上就是在監控容器進程，而不是監控代理程序，而後由代理程序鏈接到 daemon，並由 daemon（直接或者間接——依賴於你的 Docker 版本）來啓動容器。

另外一方面，你不能這麼寫：

像 Docker 代理同樣 daemon 化進程。並且必需要運行一個初始系統來 daemonize 進程。好比，你能夠這樣運行：

一樣，你沒法從遠程機器（好比 Docker 代理）運行 rkt 命令行。再有，你也能夠將它做爲安全功能考慮。

Rkt 爲鏡像聽從開放標準

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

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

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

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

一旦 OCI 格式可用，就會有更多可能，可是如今，咱們仍是須要等待。

Rkt：咱們到達目的地了嗎？

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

OCI 鏡像格式尚未準備好

就像在上文中提到過的那樣，rkt 支持 Docker 鏡像格式，並且跟 Docker 倉庫互相溝通聯繫。若是你可以堅持使用 Docker 鏡像格式，那麼相信它，它會運行得很好。

可是，若是你是個吹毛求疵的人——像我似的——你就沒辦法容忍在使用 Docker 的時候，你還沒法使用命名的端口。因此，你就會想要使用 appc 容器。appc 容器是能夠自由使用的。

可是你要怎麼上傳 appc 容器給 Core OS 解決方案到 Docker Hub——quay.io？我本身是尚未找到這樣的方法。

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

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

Nomad&Kubernetes 尚未徹底成熟

爲了在產品中運行容器，在某種程度上，你須要一個調度程序來控制運行什麼程序，在哪裏運行。目前，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 有不少的競爭對手來保持清醒。

原文連接保護知識產權，轉載聯繫咱們哦。