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生產環境的，我們很樂意想聽你們對于工具的發現和怎么在社區交流中得到一個真實的交流從而改善社區的經驗。
京公網安備 11010502049343號