1. 程式人生 > >部署 Docker 前必須問自己的四個問題

部署 Docker 前必須問自己的四個問題

2013年4月Docker被正式釋出開源,所以在軟體行業中Docker還很年輕。像我這樣的網蟲(nerds),對於這麼明星耀眼的軟體,首先看到的是它的潛質,並思考如何開始在各種場景下的使用它。

現在很多博主仍在聚焦Docker的優勢,而我們感覺到已經是時候認真的詢問在什麼場景下、為什麼這是我們最佳的選擇方案。而且更重要的是,當你 可能在兩者之間做出最好抉擇的時候。在慎重思考以下幾點後,我們最終沒有將Docker用於生產環境。但是,如果你已經將Docker用於生產,我們也願 意聽一下你的原因。

我將在這篇文章中分享一下我們的一些發現和一些關鍵問題的概括,如果你也有計劃實施使用Docker,這些問題你應該會遇到的。

我們也希望從你們那裡聽到: 你認為是什麼驅動你採用Docker的?你怎麼看待未來工具的變化?你期望它們能做到什麼地步?

1-你到底需要做多少?

Docker提供功能廣泛,這裡有幾個的例子:

  • Images(映象):Docker可以通過Pull和Push命令構建物件到服務中心

  • Containers(容器):Docker可以通過Start/Stop命令管理容器的生命週期

  • Logging(日誌):Docker可以通過stdout,stderro捕獲輸出所有的容器內部資訊

  • Volumes(儲存):Docker可以建立和管理容器的相關檔案儲存

  • Networking(網路):Docker可以建立管理虛擬的介面和內部所有容器之間的網路橋接

  • RPC:Docker伺服器提供允許外部程式去控制所有容器的行為的API


提供的功能越多必然會增加一定程度的複雜度,據使用sloccount 統計,僅僅在main repo中就有97100行程式碼。它們在Docker中全有或者全部沒有關係。所有的特性被打包到一個二進位制的檔案中,沒有方法可以實現只打進去一半。所 以,如果你準備開始使用Docker,就應該考慮是否需要它提供的這些功能。

2-搞這麼複雜值得嗎?

一年前,我們為了尋找方法簡化構建執行時的管理,開始了Docker跟 Jenkins結合使用。開始這個想法後我們不得不開始擔憂構建依賴或同時構建造成的環境汙染等問題。每一次在新容器的構建,Docker將被隔離。這個做法(指隔離Docker的操作,譯者注)在我們僅僅需要Java和Docker而不必處理其它的衝突依賴時簡化了我們的設定。

做了這些工作良好的運行了一段時間後,也引入了不少的問題。管理執行時容器並非是不重要的,我們要清理掉舊的容器會留下的檔案目錄,否則可能最終引起機器故障。

為了解決這些問題,我們不得不構建了一個包裝工作(參考

cide)來管理Docker容器的每次構建。
當cide構建時,我們也會和Dockerfile構建者關注一些靈活性問題,它不能較好的使用Gemfiles來適應私有庫的依賴管理。僅僅是獲取執行時和清理工作至少要花費三次的不同迭代。

最終新的解決方案要比先前的好。但是我們覺到這些可以更加簡單 ,可以跟工具集更緊密的結合。像所有優秀的開發者一樣,你可以在一個在抽象層尋找一個解決方案,但是它並不是那麼完美。

3–你能處理故障嗎?

Pusher的例子略微小眾化,因為我們有長期執行的客戶端連線,這些連線有償提供給我們的客戶以便可靠快速的使用。我們必須先限制分發使用者的數量。實際上,當我們部署時就已經採取額外的步驟去限制故障了(參考 crank的例項)。

Docker是 按一個月或者兩個月的頻次釋出新的版本,你很可能像通過二進位制更新到最新版。但是,由於Docker是結構化層次的,要想升級就必須關閉宿主機上的所有的容器。這就必然會增加引入新的故障挑戰。

目前,這是我們放棄在主生產環境使用Docker最大的原因。我們計劃通過替換整個機器環境,通過重定向轉換DNS流量,但是直到現在我們也沒有解決這個問題。依據你應用程式的架構,這些經驗也可以為提供一些建議。

如果你在此處不太注意,就會發現自己重建整個應用程式只是為了適應這種模式而已。這也是我們決定放棄使用Docker的另一個原因。我們懷疑它能新增延遲和一些額外的開銷。

4–你有技術支援嗎?

最終還是想想看吧,你需要捫心自問你具有操作知識嗎?我們發現找到詳細的例項Docker部署資訊非常困難。我們遇到的都是一些操作的問題以及如何處理它們。

一旦你深入發掘Docker的更多操作,你就發現網上的一點點文件完全不夠的。所以有兩種方式獲得問題的解答:要麼多花費時間思考問題,多去論壇交流刷刷問題,或者你總是能搜尋到Docker提供的專門支援問題。

本質上,能搜尋的是有很多的基礎入門資訊,但是很少量的資訊是在最優解和可操作性上是可用的。超過現在的水平去理解它是一個長期的實用解決方案這個問題是很難做到的。我們想給正在做出決定的人提供一點力所能及的幫助,這也是我們分享這篇文章其中原因之一。

那麼我們應該部署Docker嗎?

最後這是一個你自己能回答的問題。根據你的使用情況,Docker中無所不包的方法是完美的。 如果說萬丈高樓平地起,它確實是一個不錯的開端。

但是如果你已經有一個已經發布架構,你就應該問一下自己到底是否真的合適了。我們建議先規劃好你的應用程式藍圖,確認你應該需要什麼功能,然後檢 測這些功能Docker是否提供。如果你在構建一些很簡單的應用,它可能不是你的理想工具。如果上線的時間是一個障礙,它可能也不是你的理想工具。

對於那些已經執行在Docker生產環境的,我們很樂意想聽你們對於工具的發現和怎麼在社群交流中得到一個真實的交流從而改善社群的經驗。

你們在生產環境開始使用Docker了嗎? 如果你覺得哪個領域有用?我們錯過了什麼?請在下面的評論讓我們知道。