【編者的話】本文作者主要講述了將業務遷移至Docker或者容器上需要了解的問題以及實現考慮的事情。很認同作者說的“having a powerful engine doesn’t get you far if you don’t have the rest of the car built to support it（即使有強大的引擎，缺少飛車的其餘部件，你也不能走的更遠）”，所以Docker只是一個引擎，真正應用到生產環境，還需要Kubernetes等相關工具的支援。
Docker和其他容器服務極具吸引力的原因是它們輕巧靈活。對於許多公司來說，為了讓平臺成熟度更上一層，他們希望將執行時的資源需求減少到和裸機執行一致（至少這是他們的意圖）。
當你深入研究容器所帶來的好處時，很容易看出為什麼這麼多公司已經開始著手：
- 容器化他們的app以及支撐服務
- 實現隔離
- 減少環境差異
- 儘可能提升部署週期
對於規模小、鬆耦合的軟體開發模式，能夠更好地圍繞容器化進行架構設計。我們（作者）是Threat Stack的大粉絲，我們持續投入資源支援那些依賴於Threat Stack的客戶。實際上，我們最近發表官方宣告我們的代理服務（agent）已經支援CoreOS。
不過，我們發現對於Docker以及其他容器服務的疑惑並不少見（考慮到容器服務快速成長與變化速度，這並不奇怪），比如說：
- 如何實現容器的好處
- 對基礎設施/運營的影響
- 對整體SDLC和Ops流程的影響
當然，容器是有很多好處，它提供了很好的方式讓你探尋如何為你的公司更好地應用容器。不過，我們最好是能夠先剝離其外表的酷炫，找到更好應用容器技術的方式。
為什麼是Docker？為什麼是現在？
許多公司目前正在執行大量的AWS例項用以加速新的應用程式、服務、資料庫等，從而擴大自身業務。當從業務量特別小開始擴張時，會逐步感受到其帶來的各種型別的開銷：
- 複用宿主機作業系統的計算資源
- 與應用程式無關的大量程式
- 管理更多的例項
這將導致無節制擴張、核心思想的不一致以及流程與預算挑戰。財務部門希望瞭解Ops團隊如何規劃他們的增長和支出，安全團隊會盡量插足業務增長情況，以確保公司達到其安全策略的目標，而工程師希望獲知如何能夠在他們需要快速部署的新元件上得到足夠的靈活性。與此同時，業務還需要不斷增長。
因此，一個關鍵問題是：我們該如何優化我們的流程，優化我們AWS環境（用以省錢），同時還能做我們需要做的事情？
Docker - 至少在表面上 - 似乎為這個難題提供了一個答案。
我們從具有很多AWS例項的公司那瞭解到一個常見的共同主題是通過增加單個例項配置和其上執行容器的規模來減少原始例項的數量。
例如，你有600個AWS例項，每個例項具有1個CPU和4-5GB的記憶體，那麼你可能會思考可以通過Docker容器將AWS例項減少到100個，而每個例項具有32個GPU和64GB記憶體。然後你就可以減少AWS上的花費，因為你擁有了更少的例項數。這是正確的嗎？其實沒那麼簡單。
轉向容器前應該思考什麼
在短期內，上述變化可能適用於某些用例。但從長遠來看，與許多技術選型一樣，你正在為另一種方式提供一套複雜性。為什麼？
一種全新的技術棧
隨著你開始大規模執行容器，你需要投入資源到一個管理與編排平臺用以管理你的容器和資源。這需要一個容器自身的整體技術棧。
而且由於容器的使用模式仍然是一個比較新的課題，因此沒有很多最佳做法可以參考借鑑，所以制定策略的過程取決於具體的實現，這將意味著生產和公司投入需要持續的迭代，這可能會影響交付計劃。
管理度挑戰
應用容器的其他較大挑戰包括：
- 如何管理容器
- 如何保持容器可見性
- 如何知道何時使用容器是適當的解決方案（何時又不是）
目前，就上述三個問題，我們能夠找到很多“Docker合理化”建議。這就意味著很多公司正在轉向容器化方案，因為他們能夠解決他們遇到的具體用例。這是一件好事（演變的發生需要不斷地迭代），但是當需要確定對於平臺可用性、安全性以及成本效率的影響時，最好是提前制定出一套清晰的用例目標。
安全風險
雖然從表面上看將你的工作負載遷移到容器上是有意義的，但難題經常發生在細節處理上。隨著容器具備更大的自由性與可選性，我們需要管理新的風險型別。 對於容器而言，安全性可能是非常具有挑戰性的，因為你沒有靠得住的最佳實踐可以依賴。
隨著你業務的擴充套件，你將需要了解如何對你正在使用的映象，它們的構建方式以及提供給程式的訪問範圍進行適當的控制。你應該事先知道如下問題的答案：
- 開發人員是否被允許登入一個生產環境執行中的容器？
- 所有容器是否保持不變？
- 我們該怎麼管理容器映象大小？
一開始就明確這些問題的答案將有助於讓你的實現過程清晰明確。
真誠面對挑戰
很多公司正在揭露容器複雜性方面所遇到的挑戰，我們所瞭解到的一些難題如下：
- 需要使用哪種型別以及相應數量的例項來執行這些容器？並且，真正的效能瓶頸是什麼？
- 由於工作負載的特點隨著時間的推移而變化，如何知道容器基礎設施需要進行適配以及重新建模？
- 如何處理規模伸縮問題？何時向上擴充套件？何時向外擴充套件？該怎麼減少外層規模而不引入SPoF？
- 如何處理容器的安全性，程式執行在容器中，它們可以訪問哪些容器外部事物？
問題會從很多維度產生。需要謹記的最重要的事情之一是，儘管Docker確實可以幫助你執行得更快，但即使擁有強大的引擎，缺少構建飛車的其餘部件，也不能讓你走的更遠。
未來是光明的
很明顯，容器是雲端計算基礎設施未來的重要組成部分，我們在Threat Stack中正在擁抱容器。我們希望看到越來越多的公司能夠以開放的態度應用容器技術，從而與容器化中固有的風險認知相平衡。
好訊息是將你的工作負載遷移到容器中並不會真正減少可見性，但你必須意識到Docker不能解決雲上的所有問題，就像任何其他技術一樣，應該用樂觀和懷疑的態度來應用它。
原文連結：Why Docker Can’t Solve All Your Problems in the Cloud（翻譯：肖遠昊）