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

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

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

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

　　系統(tǒng)管理員會很喜歡這點，因為容器易于部署（通過XCOPY命令就可以？）和維護（REST接口會很容易地集成到任何現(xiàn)代基礎(chǔ)架構(gòu)管理平臺中）。

　　企業(yè)級發(fā)布自動化解決方案的需求

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

　　Who：并不是組織中的任何人都可以將某一個應(yīng)用部署到某個環(huán)境中。實際上，即使對于那些專職從事這個工作的人，也需要其他人的許可才能進(jìn)行部署工作。

　　What：對于那些想真正引入敏捷業(yè)務(wù)概念的組織，

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

　　Where：一個應(yīng)用從開發(fā)到生產(chǎn)所經(jīng)歷的環(huán)境經(jīng)常與部署的目標(biāo)環(huán)境是不同的。這些差異會在應(yīng)用進(jìn)行部署以后，通過更改應(yīng)用的配置來解決。

　　When：發(fā)布窗口不是一個新概念。甚至在非生產(chǎn)環(huán)境中，也需要各自建立發(fā)布窗口，因為環(huán)境經(jīng)常被同一個功能或者夸功能的多個團隊所共享（例如：測試和開發(fā)可能會使用相同的環(huán)境）

　　How：作為很可能是最難以完全集成到一個組織運行能力中的環(huán)節(jié)，部署一個應(yīng)用的過程遠(yuǎn)不是簡單的理解如何安裝或者配置它。例如，與一個IT服務(wù)管理（ITSM）應(yīng)用集成，以確保所有的需求改變都已輸入并且處于正確的狀態(tài)，這些被吸納進(jìn)部署過程以便操作環(huán)境的狀態(tài)一直被明確的理解。這個會在下面進(jìn)行詳細(xì)的討論。

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

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

　　應(yīng)用發(fā)布管理不只是應(yīng)用

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

　　此外，在應(yīng)用的生命周期中，發(fā)布應(yīng)用的過程通常包括針對這過程的治理，但是這卻不是該過程的一部分。然而，這些構(gòu)建應(yīng)用所要經(jīng)歷的階段都是必要的，這可以將高節(jié)奏進(jìn)行發(fā)布的風(fēng)險降到最低，這包括許可、驗證和其他類型的活動。

　　自動化是一切的關(guān)鍵

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

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

　　上述部分中的每一個工具只與應(yīng)用開發(fā)和發(fā)布過程的一小部分有關(guān)系。類似地，Docker解決了與應(yīng)用程序發(fā)布相關(guān)的工件管理，這樣就可以簡化這些工件的部署，確實如此。這些與其他解決方案的協(xié)調(diào)能力，必須要通過一個統(tǒng)一的方案來進(jìn)行管理，這就是應(yīng)用發(fā)布自動化的目標(biāo)。

　　總結(jié)

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

　　投資于企業(yè)級自動化解決方案，實現(xiàn)關(guān)鍵任務(wù)應(yīng)用的自動發(fā)布，不但可以提高部署應(yīng)用的速度，而且能提高公司數(shù)字化轉(zhuǎn)型的程度，隨著更多的應(yīng)用發(fā)布通過自動化完成，也會為公司帶來更多的盈利。