【轉載】作為一個運維，我怎麼看Docker？

轉載自：http://weibo.com/p/1001603839871499289201

最近docker非常火，以至于和圈裡朋友聊天的時候，如果不提docker，都不好意思打招呼。于是就補習了下docker的基本知識：《docker入門與實踐》。有了個大緻的感覺。

有個雲計算的産品經理問我，你對docker怎麼看？我的回答是：很不錯，但是現階段還不成熟，我不看好。總體來說，對開發很友好，對運維是個災難。我不知道那些鼓吹docker具有優秀“可運維性”的人，是否真正做過docker的運維？

這個觀點可能來自于很多個理由，其中最大的理由是“碎片化”。我的前一個微網誌講運維的本質是可控。那麼docker的碎片化，就是讓這個“可控”變得“失控”。為什麼這樣講，docker有個很大的優點，就是靈活，他可以非常靈活的部署，疊代和引用。但這個也是個雙刃劍。

舉個例子：我們現在做了一個docker img。這個img可能會被很多業務通過docker hub 靈活的引用。但若幹時間後，這個base img發生了bug或者漏洞，而修複這些東西可能會造成上層引用的img故障，這個時候怎麼辦？

1：選擇重新build img，所有的引用全部重來，這個。。。業務系統稍微複雜一點，這種做法，就是要累死運維了。。。。

2：不做任何強制性限制，哪個業務系統可以改，就改，不能改就算了。反正docker可以靈活的引用，沒關系。時間長了，生産環境中就會充斥各個不同的“版本”，運維的同學既不能控制風險，也不能控制穩定性和性能，完全又是要死的節奏。

這個例子很典型，也是docker對運維影響的其中之一。另外，docker相對複雜的網絡配置，container之間的通信，都是需要攻破的難題。磁盤io，quota本身也是docker的弱項，就更不用提了。

是以，docker的優點，都是針對于開發來講，而非運維。要說運維的優點，很多人會說docker非常輕量級，效率高，實際上docker帶來的效率提升，遠不及業務系統邏輯和代碼優化那麼一點點。。。。。。

當然也有人會說docker的發展很快，以後有很多運維性的提高，沒錯，但到了那個時候，也許會有更新的容器技術出現，就像nvdimm之于ssd~