譯者注：使用Docker能真正改善傳統的應用發布管理中遇到的問題么?以下是譯文：

自從2013年發布以來，Docker已經成為每一個操作管理者眼中的***。如果你一直與世隔絕，這里恰恰是你錯過的部分。

Docker是在一個操作環境地址空間中的分區能力。通過允許分區直接使用宿主的操作系統，即使操作系統位于分區之外(分區在這里稱為容器)，啟動時間得以縮短，管理容器所需要的資源同樣得以縮減(如果你熟悉z/OS，你會發現這個概念有點熟悉)

財務人士會喜歡這點，因為獲取操作環境licenses的花費會實質性的減少，理論上，每一個非應用部分的組件都能駐留在容器以外。這意味著只需要購買一個Windows licenses，而不是每一個虛擬機上都要購買一個(如果不使用Docker,這是必要的過程)。

概念看似簡單，但是如何工作呢?

本質上，一個特殊的文件(稱為一個Docker文件)，包含一條或多條關于如何創立一個容器的指令。這個Docker文件作為程序的部分，在文件系統中產生容器，其包含一個單獨的應用以及相關聯的二進制代碼。這個容器(文件系統中的一個子目錄)作為任意的文件集會被傳送到目標環境并在目標環境中利用Docker的運行時庫開始運行，運行時庫可以通過命令行接口或者一個API(典型的基于REST，但是還有其他的實現)

系統管理員會很喜歡這點，因為容器易于部署(通過XCOPY命令就可以?)和維護(REST接口會很容易地集成到任何現代基礎架構管理平臺中)。

企業級發布自動化解決方案的需求

很不幸，當人們試圖使用它作為真正的應用發布管理的替代品時，這個概念又不行了。我們能夠使用每個人在高中學會的六個詞中的五個詞還描述應用發布管理：

• Who: 并不是組織中的任何人都可以將某一個應用部署到某個環境中。實際上，即使對于那些專職從事這個工作的人，也需要其他人的許可才能進行部署工作。
• What: 對于那些想真正引入敏捷業務概念的組織，

每一次都部署一個完整的應用也是不可接受的。那些被認為是低風險的工件(artifacts)(如內容更新)可以及時部署，而高風險的工件則需要在進行大量的測試和其他驗證工作后，排隊等待進行發布。Docker就屬于后者，但是還有一些限制，這會在后面提到。

• Where: 一個應用從開發到生產所經歷的環境經常與部署的目標環境是不同的。這些差異會在應用進行部署以后，通過更改應用的配置來解決。
• When： 發布窗口不是一個新概念。甚至在非生產環境中，也需要各自建立發布窗口，因為環境經常被同一個功能或者夸功能的多個團隊所共享(例如：測試和開發可能會使用相同的環境)
• How: 作為很可能是最難以完全集成到一個組織運行能力中的環節，部署一個應用的過程遠不是簡單的理解如何安裝或者配置它。例如，與一個IT服務管理(ITSM)應用集成，以確保所有的需求改變都已輸入并且處于正確的狀態，這些被吸納進部署過程以便操作環境的狀態一直被明確的理解。這個會在下面進行詳細的討論。

對于上面的5個疑問詞，Docker 只解決了其中的一個，而且是并沒有采用最有效的方式。以一個歐洲著名銀行為例，他們現在每個月發布的產品已經過千，這也只有在所有發布的產品都不是高風險的才能實現，在這個例子里，這意味著這些工件都是低風險類型。因此，這些類型工件的發布會很迅速，這有助于確保這個銀行的客戶的資產滿足他們的需要。

然而，如果他們在使用Docker,無論這些類型的工件是否獲得生產許可，整個應用都需要重建。對于大部分公司來說，直接將未獲許可的二進制文件發布到產品中而帶來的風險是不可接受的。這只是對于上面5項之一-Docker對于解決其他4項無能為力。

應用發布管理不只是應用

只從應用的角度考慮應用發布管理是很有趣的，而從業務的角度來看，忘記應用是更大場景的一部分。在上面How部分里，提到了ITSM，這不只是發布過程必須要集成的唯一技術。事實上，還有SDLC工具鏈與一系列適合特定需要的解決方案可供選擇：適用于連續集成的Hudson 和Jenkins;用于源代碼管理的Git和Subversion;用于工件管理的Nexus和Artifactory;用于配置管理的 Chef 和 Puppet 等等。

此外，在應用的生命周期中，發布應用的過程通常包括針對這過程的治理，但是這卻不是該過程的一部分。然而，這些構建應用所要經歷的階段都是必要的，這可以將高節奏進行發布的風險降到***，這包括許可、驗證和其他類型的活動。

自動化是一切的關鍵

我們提到的每一件事對于應用發布來說都是關鍵的，但是，***結果是什么。終端用戶需要新的功能，應用開發團隊能夠以什么樣的速度開發出新的功能并把它最終交付到終端用戶手上，決定了新的功能能以多快的速度變成附加的收入。

此外，過程的可重復性能夠保證應用發布更高的成功率，相反的，失敗的部署會消耗你的公司資金，在診斷和修復過程中開發的應用數量也會受影響而下降。過去3年，分析公司的兩項研究表明，財富1000強公司因變更、配置或其他與之相關的問題而導致應用中斷的成本在$200k-400k/小時。

上述部分中的每一個工具只與應用開發和發布過程的一小部分有關系。類似地，Docker解決了與應用程序發布相關的工件管理，這樣就可以簡化這些工件的部署，確實如此。這些與其他解決方案的協調能力，必須要通過一個統一的方案來進行管理，這就是應用發布自動化的目標。

總結

總的來說，Docker是一項令人興奮的技術，它應該被單純看作是在整個應用程序發布周期中存在的另一種機制。但是它不應該被看作是一個定義良好方法的替代品，它不僅包括“what”，還包括“who”、“where”、“when”以及“how”。

投資于企業級自動化解決方案，實現關鍵任務應用的自動發布，不但可以提高部署應用的速度，而且能提高公司數字化轉型的程度，隨著更多的應用發布通過自動化完成，也會為公司帶來更多的盈利。