這四種容器部署方式哪種適合你？
容器作為一種賦能技術，在企業(yè)IT規(guī)劃中扮演著重要的角色。其中原因不言而喻，它能幫助企業(yè)獲得快速發(fā)展。畢竟對于數(shù)字化業(yè)務而言，速度就是金錢。為了實現(xiàn)業(yè)務敏捷度，IT領導者希望顛覆以往的二八模式，即將80%的預算用于維護，僅投入20%預算進行創(chuàng)新。如今，CIO們希望將更多預算用來幫助企業(yè)建立敏捷性與敏銳性。
容器、DevOps以及微服務等要素組合起來，可以幫助CIO們實現(xiàn)這一目標。
簡而言之，容器將應用程序封裝在單一程序包當中，與運行所在的主機系統(tǒng)相隔離。開發(fā)人員能夠在開發(fā)過程中，輕松移動這些程序包，這也是DevOps理念中的基本要求。從開發(fā)環(huán)境快速遷移至生產環(huán)境時，容器技術同樣具有重大意義。
僅僅技術本身并不能解決問題，在多個跨職能DevOps小組和重新考慮流程以及業(yè)務邊界時，CIO還需要直面文化層面的種種挑戰(zhàn)。無論是技術還是文化，CIO都可以從同行身上學到很多東西。本文介紹了企業(yè)采用容器的四種典型方式，并列舉出每種方式所需要注意的事項。
當然，對于任何一家企業(yè)而言，并不存在完美的容器部署方式。你可以以一條路徑作為切入點，之后再切換至其他路徑。另外，企業(yè)內部的不同團隊往往也會采取不同的容器部署方式。因此，企業(yè)內部往往同時存在多種容器部署模式。
引入容器平臺
不少企業(yè)在開始使用容器之后，很快意識到自己需要一套平臺。通常，由特定的小組（例如DevOps小組）在推進變更的過程中，引入一套用于快速執(zhí)行實驗及部署的敏捷性技術平臺。在此過程中，容器就成了理想的解決方案，他們會力爭說服領導者接納容器，并最終將其作為企業(yè)運營的固定組成部分。關鍵問題在于，企業(yè)應該使用哪種平臺部署并管理容器？盡管目前市面上存在著大量開源容器工具，但企業(yè)級容器平臺通常囊括數(shù)十種開源項目，包括Kubernetes編排、安全性、網絡、管理、自動化構建以及持續(xù)集成/部署等功能。總而言之，這類平臺有助于解決管理、治理以及安全性方面的諸多問題。
對于這條路徑，企業(yè)可以先從易于實現(xiàn)的目標入手。 Web服務器與應用程序服務器往往是最易于作為容器化工作負載進行部署的目標，然后進一步引入數(shù)據庫與有狀態(tài)系統(tǒng)，同時密切關注與現(xiàn)有構建及部署工具/流程的集成效果，把握進展情況。
除此以外，也要考慮容器安全問題。由于容器中包含系統(tǒng)特定的庫與依賴項，因此更不容易發(fā)現(xiàn)隱藏的安全漏洞，可信注冊表、鏡像掃描與管理工具可實現(xiàn)自動識別并修復容器鏡像。
打造云原生應用容器
一些企業(yè)更傾向于使用由應用程序開發(fā)團隊打造的云原生應用容器，其中包括新項目以及對原有應用程序的改造成果。這類應用程序通常以微服務架構為基礎，目標在于將應用程序拆分為多項基礎服務，以便團隊可以針對各獨立組件進行應用程序更新。IT團隊還可以使用靈活的API實現(xiàn)這類目標。
如果采用此種模式，企業(yè)應使用安全且易于理解的API集在應用程序當中同其他自有，或者第三方應用程序、系統(tǒng)及數(shù)據進行交互。另外，還需要充分考慮如何將其與現(xiàn)有系統(tǒng)相集成。由此可以看出，容器與微服務及API相結合，將幫助開發(fā)團隊更輕松地開發(fā)、協(xié)同并部署云原生應用程序。
在考慮使用新的運行時，以往部署的單體式應用服務器很難用于運行下一代應用程序，這是因為后者往往采用事件驅動設計、響應式以及無服務器等新興技術。容器平臺必須有能力支持廣泛的現(xiàn)有及云原生運行時與框架方案。同時，也要關注開發(fā)者工具，在運行時不斷發(fā)展的同時，立足云端的開發(fā)者工具，也有望高效管理由自我學習技術以及自動化工作流帶來的日益復雜的工作環(huán)境，進而幫助開發(fā)人員更快構建起高質量產品代碼。
實現(xiàn)云管理的技術與文化因素
在這種常用模式中，運營團隊或管理大量應用程序的其他團隊通常已經深刻認識到公有云的優(yōu)勢，且希望將其彈性、速度與性能等要素納入運營環(huán)境。但團隊可能出于歷史、法規(guī)或安全等方面的考量，仍需要在本地環(huán)境中運行某些應用程序。此外，團隊通常還需要面對原有裸機服務器或虛擬化環(huán)境，甚至包括一部分私有云。面對繁多的考量因素，云管理將成為至關重要的一環(huán)。
這其中關鍵問題在于——要如何建立一個抽象層級？一套在所有環(huán)境中都能良好運行的平臺？確保運營團隊能夠無縫管理所有應用程序？又如何將各類基礎設施隱藏起來，為開發(fā)人員提供一套統(tǒng)一的部署環(huán)境？這種便利性將成為提高開發(fā)者工作速度的重要前提。
從另外一個方面來看，文化因素可能讓數(shù)字化轉型難以起步。一位帶領重要變革的銀行CIO表示，除非員工們能夠在心態(tài)與行為模式上真正適應這種改變，否則一切變革都只能是空談。推動文化變革的IT領導者需要同時得到企業(yè)高層與基層團隊管理者的支持。畢竟，無論愿不愿行動、如何行動，業(yè)務對于速度的追求永遠不會消失。
推動業(yè)務創(chuàng)新
在這種模式下，企業(yè)會成立一支小團隊以解決特定的業(yè)務問題，這就需要引入更多現(xiàn)代實踐，引導員工成為變革的推動者。同時，IT團隊需要快速創(chuàng)建、迭代并確保IT部門后續(xù)能夠對解決方案進行擴展。這些團隊通常會獲得新的技術工具與使用權限，根據不同規(guī)則進行探索性嘗試。
我們的IT人員是否具備適應新需求的技能？我們需要招聘新員工嗎？我們原本的技能投資該怎么處理？……這些對技能的爭論逐漸浮出水面。企業(yè)不僅需要招聘新員工，還需將內部交叉培訓結合起來，由外部專家評估當前狀況，并制定計劃以幫助達成目標。
值得注意的是，企業(yè)不要怕失敗，如果企業(yè)不愿放手讓IT團隊進行大膽嘗試，那么人才必將開始流失。以澳大利亞麥格理銀行為例，他們的CIO就希望招募人才以建立新的、極具突破性的客戶體驗。正是憑借著這種充分放權、尊重創(chuàng)造的態(tài)度，麥格理銀行才成功吸引到了高質量的新鮮血液。
結束語
每一段數(shù)字化轉型都有其獨特之處，也沒有哪兩條DevOps道路會一模一樣。正如之前提到的四種模式一樣，你不一定非要照搬其他企業(yè)或競爭對手的容器使用方式。但可以向他們學習，并參考以下幾項基本思路推動容器采用：
成熟企業(yè)比云原生企業(yè)面臨著更大的挑戰(zhàn)。Netflix一直以快速發(fā)展的開發(fā)團隊為傲，而且從不會為陳舊的基礎設施所限。相比之下，不少成熟企業(yè)的CIO仍然需要支持COBOL應用程序。IT管理團隊需要明白，沒必要在這方面Netflix進行直接比較。
不要被規(guī)模問題困擾。單從規(guī)模角度來看，世界上沒有幾家企業(yè)能夠與Facebook相提并論。但你并不需要Facebook那么龐大的資源或技能儲備，也可以完成重大的業(yè)務變革，從小處入手，并在逐步獲得成功后再擴展團隊、引入技術。
最后，鼓勵IT團隊積極參與外部交流。鼓勵團隊成員與公司之外的同行們交互，共同探討技術與文化層面的挑戰(zhàn)。
