除非你在過去幾年里一直生活在石器時代，否則你肯定知道容器和Docker。如果你是互聯(lián)網(wǎng)極客的話，可能你已經(jīng)準(zhǔn)備在生產(chǎn)環(huán)境中使用Docker了。

[[151524]]

一年前我也在嘗試跟上技術(shù)更新的步伐，但以忙于交付原生態(tài)的系統(tǒng)結(jié)束。我見識到的雖讓我某種程度上傷痕累累，但也讓我收獲頗豐，更重要的是讓我意識到很多很流行工具的缺點。直到我們建立起一套不錯的托管技術(shù)棧的時候，我的團(tuán)隊已經(jīng)為融合這些技術(shù)開發(fā)了很多定制代碼，我對這樣的系統(tǒng)設(shè)計和運營很不滿意，于是離開那里，成為了ContainerShip的聯(lián)合創(chuàng)始人。

顯然我可能帶有偏見，但我認(rèn)為ContainerShip非常棒，它可以幫你節(jié)省很多時間，減少很多痛苦。當(dāng)然，我不會強迫你去用它，同時我也會盡量避免將偏見帶入這篇文章中。

1.太多不確定因素

微服務(wù)和面向服務(wù)的體系模式，倡導(dǎo)將系統(tǒng)分隔成許多不同的、小的、松耦合的軟件模塊，而不是一個單一的整體。當(dāng)涉及到開發(fā)一個大型軟件項目時，更容易將這些模塊分給不同的團(tuán)隊，每個團(tuán)隊還可以用自己擅長的技術(shù)來開發(fā)。

這種認(rèn)識甚至已經(jīng)滲透到了基礎(chǔ)設(shè)施的層面。取其精華，去其糟粕，這在理論上講行得通，但實踐過程中可能是個美麗的陷阱。

當(dāng)您的托管平臺是由一系列變動的部件構(gòu)成，每個部件都是由開源項目或公司所維護(hù)，就需要編寫大量的定制代碼來將其融合起來。而這些定制代碼，必須要自己維護(hù)，并且當(dāng)問題發(fā)生時，你很難確定是哪一個組件的故障，可能也沒人能幫得上忙，因為讓團(tuán)隊成員學(xué)習(xí)大量的組件是非常耗時和困難的。如果API發(fā)生變化或新版本發(fā)布，你只能靠自己讓它繼續(xù)工作。

我最初是沿著這條路走的，一個基礎(chǔ)設(shè)施團(tuán)隊，服務(wù)于數(shù)百個非常忙碌的服務(wù)，最終以痛苦告終。

2.沒有高可用性

現(xiàn)在有幾個越來越受歡迎的開源項目，完全忽略了它們master服務(wù)器(編排管理剩余集群的服務(wù)器)的高可用性。可怕的是這些公司宣稱其產(chǎn)品是在生產(chǎn)環(huán)境中運行Docker的***方式。如果集群管理系統(tǒng)不是高可用的，沒有l(wèi)eader election的概念，運行在一臺單獨的服務(wù)器上，我不能想象這可以稱為生產(chǎn)級別的產(chǎn)品。無論選擇何種解決方案，請確保它支持多個master的高可用性，以及通過一些選舉機制來決定哪個master作為leader或者有很好的結(jié)束機制。

3.不開源

我曾因為把寶都壓在一個非開源項目中，而非常痛苦。如果沒有類似經(jīng)歷的話，可能會覺得難以置信。以Genius上所紕漏的Heroku的丑聞為例，沒有人會想到，他們底層的托管平臺的文件會有造假，用戶則在被系統(tǒng)超長的響應(yīng)時間所困擾。還有很多古怪事情發(fā)生在這些非開源的Docker管理系統(tǒng)。

4.非必要的網(wǎng)絡(luò)需求

現(xiàn)在有一個趨勢是通過overlay網(wǎng)絡(luò)，為主機系統(tǒng)上的每個容器分配唯一的IP地址。這種方式帶來的***好處是易于使用，但隨之而來的是延遲和帶寬限制的成本。甚至一些最專業(yè)的container編排系統(tǒng)也在向用戶推銷這種方式。在新的實現(xiàn)中，事情得到了改善，但是降低性能來提高易用性的方法，并不是一個好主意。

另一種方式是“端口映射”，比如所有容器都運行子啊隨機端口上，通過計算獲得流量的正確方向。好消息是，端口映射問題并不是真的很難，你不需要限制你的性能。使用分布式架構(gòu)的目的是上提高性能，可用性和功能，不要因為錯誤的選擇反而破壞了性能。

5.托管核心業(yè)務(wù)

幾乎所有大型云供應(yīng)商都發(fā)布了自己的容器生產(chǎn)解決方案，比如AWS的EC2 Container Service，谷歌的Google ContainerEngine，Joyent的Triton等等。不幸的是(我的觀點)，在容器托管服務(wù)商中運行你的容器負(fù)載，會違背容器***的一個好處：可移植性。托管服務(wù)供應(yīng)商會想盡一切辦法留住你。過去你沒有太多選擇，只能糾結(jié)于配置管理系統(tǒng)和多個提供商的API。現(xiàn)在情況已經(jīng)有所轉(zhuǎn)變，有了開放的和供應(yīng)商無關(guān)的選擇。我強烈建議不要使用一個不具有靈活性的系統(tǒng)，而且與供應(yīng)商無關(guān)作為他們的主要目標(biāo)。

另一個選擇是“Docker as a Service”提供商，在他們自己的網(wǎng)絡(luò)上提供運行所有重要的系統(tǒng)，而且為你提供托管主機上簡單的運行獨立服務(wù)器，有客戶端連接到他們管理系統(tǒng)。但當(dāng)你不想再付錢給這些供應(yīng)商，或者他們的服務(wù)不再適應(yīng)于你業(yè)務(wù)的增長時，你是沒有辦法回退到免費和開源的模式的。ContainerShip可以做到，當(dāng)您在CoutainerShip中啟動一個集群，系統(tǒng)的核心運行在您自己的服務(wù)器上，您可以隨時停止運行在云服務(wù)中的工作，使用開源的核心系統(tǒng)。

6.強制的操作系統(tǒng)

我以前負(fù)責(zé)安全和PCI DSS協(xié)作，還要處理隨之而來的上百的監(jiān)控和審計要求，使用微型Linux操作系統(tǒng)是不行的，因為IDS/日志/安全軟件，不適合在只能通過Docker安裝和運行軟件的主機上使用。可能對你來說并不是一個問題，但我希望能自由選擇操作系統(tǒng)。為什么要用一個指定的操作系統(tǒng)來使用Docker?或者為什么你需要利用一個初始化系統(tǒng)來運行容器?我認(rèn)為這是你要極力避免的緊耦合。靈活性和多種Linux操作系統(tǒng)的支持非常重要，尤其是對于那些希望能夠繼續(xù)使用某些操作系統(tǒng)的企業(yè)，因為他們已經(jīng)在這個操作系統(tǒng)上投入了時間培訓(xùn)，有一些服務(wù)部署在上面。

總結(jié)

以上只是我的建議，但它們來自于無數(shù)個小時的研究，開發(fā)和實踐中大規(guī)模運行Docker的經(jīng)驗。當(dāng)你計劃向容器和分布式系統(tǒng)遷移時，請記住這些經(jīng)驗。有時候，炒作會讓你走上一條路，從現(xiàn)在起6個月就沒辦法工作了。計算領(lǐng)域的技術(shù)更新非常迅速，但多年沉淀下來的***實踐不會改變。一定要相信你的直覺，容器并不能使一個壞的解決方案變好。

原文鏈接：http://chuansong.me/n/1760627