docker和虛擬機的區別：docker應用場景和開發方向

過去的幾年時間，科技發生了巨大變化，從物理服務器到虛擬服務器，再到擁有PaaS環境的雲計算。不論是否採用了全新架構，Docker鏡像都可以在當前環境中很容易地被使用。要使用Docker，並不需要立即從單體應用程序遷移到面向服務架構。有很多用例允許在不同層次上集成Docker。

Docker常用於以下場景。

• 使用以鏡像為基礎的部署方式取代類似Capistrano的代碼部署系統。
• 安全地在同一台服務器中運行遺留應用和新應用。
• 使用一個工具鏈循序漸進地遷移到面向服務架構。
• 管理雲端或裸機上的水平擴展性和彈性。
• 確保從開發環境到預演環境到生產環境跨環境的一致性。
• 簡化開發人員的機器設置和一致性。

將應用的後台程序遷移到Docker集群中，同時保持網頁服務器和數據庫服務器不變是開始使用Docker的常見示例。另一示例是將應用的部分REST API遷移到Docker中運行，前端使用Nginx代理在遺留服務和Docker集群之間路由通信。通過使用此類技術，團隊可以漸進式地從單體應用無縫地遷移到面向服務架構。

如今的應用程序往往需要幾十個第三方庫，用於加速功能開發或連接第三方SaaS和數據庫服務。每個庫都可能產生bug，或是讓用戶陷入版本依賴的泥沼。再加上庫的頻繁更改，要在基礎設施上完成工作代碼的持續部署而不引起失敗，壓力巨大。

Docker可貴的鏡像思想使得技術團隊在部署工作代碼時，不論是單體架構、面向服務或是二者的混合，由於代碼及其依賴項捆綁在同一個鏡像中，所使用的方式對每次部署都是可測試、可重複、文檔化且一致的。一旦一個鏡像構建完畢，就可以部署到任意多個運行着Docker守護進程的服務器上。

另外一個常見的Docker用例是跨環境部署一個單一容器，其典型的代碼路徑是從開發環境到預演環境再到生產環境。容器為整個代碼路徑提供了一個一致的、可測試的環境。

作為一個開發人員，Docker模型允許在其個人電腦上調試與生產環境完全一致的代碼。開發人員可以很容易地下載、運行和調試有問題的生產環境鏡像，且無需事先對本地開發環境進行修改。

在生產環境中運行Docker容器困難不小，但還是能實現的。每天都有越來越多公司開始在生產環境中運行Docker。如同所有的基礎設施一樣，我們建議以小規模入手，然後漸進式地完成遷移。

為什麼在生產環境中運行Docker如此困難

Docker對生產環境有很多要求：安全可靠的部署、健康檢查、最小或零停機時間、從失敗中恢復的能力（回滾）、一個集中存儲日誌的方式、一種分析或調試應用的方式，以及一種聚合監控參數的方式。類似Docker這樣的新技術雖然使用起來非常有趣，但還需要時間來完善。

Docker在可移植性、一致性以及打包具有眾多依賴的服務方面非常有優勢。多數團隊會因為以下一個或多個痛點而堅持使用Docker。

• 一個應用的不同部分使用大量不同的依賴。
• 支持使用舊依賴的遺留應用程序。
• 開發團隊與DevOps之間的工作流問題。

警示：切勿嘗試在一個組織內讓採用Docker這事一蹴而就。即便運維團隊已經為採用Docker做好了充分的準備，也請記住，過渡到Docker通常意味着將管理依賴的重任推給了開發人員。雖然很多開發人員都渴求這種自主權，以便加快迭代，但並非每位開發人員都有能力或興趣將其列入自己的責任範圍。為了能有一個良好的Docker工作流，還是需要花些時間來轉變企業文化。

本文節選自《Docker生產環境實踐指南》

本書圍繞「Docker該如何應用到生產環境」這一核心問題展開。在本書中，讀者將接觸到多個IT企業應用Docker到生產環境的成功案例，了解Docker實際投產時將會面臨的問題，以及它與現有基礎設施存在的矛盾與衝突，了解構建Docker生態系統所需的配套設施，包括安全、構建鏡像、持續集成/持續交付、鏡像存儲、配置管理、網絡實現、服務發現、持久化存儲以及日誌監控等模塊的具體選型方案及利弊所在。本書編寫時一些案例參考的Docker版本是Docker 1.6或Docker 1.7。

本書要求讀者具備一定的容器管理和運維的基礎知識，適合在生產環境中使用Docker的相關技術人員閱讀，尤其適合具有中高級DevOps和運維背景的讀者閱讀。