Docker 是一個開源的應用容器引擎，讓開發者可以打包他們的應用以及依賴包到一個可移植的容器中，然后發布到任何流行的 Linux 機器上，也可以實現虛擬化。容器是完全使用沙箱機制，相互之間不會有任何接口（類似 iPhone 的 app）。幾乎沒有性能開銷，可以很容易地在機器和數據中心中運行。最重要的是，他們不依賴于任何語言、框架包括系統。

　　起源

　　Docker 是 PaaS 提供商 dotCloud 開源的一個基于 LXC 的高級容器引擎，源代碼托管在 Github 上，基于go語言并遵從 Apache2.0 協議開源。

　　Docker 自2013年以來非常火熱，無論是從 github 上的代碼活躍度，還是 Redhat 在 RHEL 6.5 中集成對 Docker 的支持，就連 Google 的 Compute Engine 也支持 docker 在其之上運行。

　　一款開源軟件能否在商業上成功，很大程度上依賴三件事：1）成功的user case，2）活躍的社區，3）一個好故事。 dotCloud 自家的 PaaS 產品建立在 docker 之上，長期維護且有大量的用戶，社區也十分活躍，接下來我們看看 docker 的故事。

• 環境管理復雜：從各種OS到各種中間件到各種App，一款產品能夠成功作為開發者需要關心的東西太多，且難于管理，這個問題幾乎在所有現代IT相關行業都需要面對。

• 云計算時代的到來：AWS的成功，引導開發者將應用轉移到 Cloud 上，解決了硬件管理的問題，然而中間件相關的問題依然存在 (所以OpenStack HEAT和 AWS CloudFormation 都著力解決這個問題)。為開發者思路變化提供了可能性。

• 虛擬化手段的變化：Cloud 時代采用標配硬件來降低成本，采用虛擬化手段來滿足用戶按需使用的需求以及保證可用性和隔離性。然而無論是KVM還是Xen在 docker 看來，都在浪費資源，因為用戶需要的是高效運行環境而非OS，GuestOS既浪費資源又難于管理，更加輕量級的LXC更加靈活和快速。

• LXC的移動性：LXC在 Linux 2.6 的 Kernel 里就已經存在了，但是其設計之初并非為云計算考慮的，缺少標準化的描述手段和容器的可遷移性，決定其構建出的環境難于遷移和標準化管理(相對于KVM之類image和snapshot的概念)。docker 就在這個問題上做出實質性的革新。這是docker最獨特的地方。

VM技術和容器技術對比

　　面對上述幾個問題，docker設想是交付運行環境如同海運，OS如同一個貨輪，每一個在OS基礎上的軟件都如同一個集裝箱，用戶可以通過標準化手段自由組裝運行環境，同時集裝箱的內容可以由用戶自定義，也可以由專業人員制造。這樣，交付一個軟件，就是一系列標準化組件的集合的交付，如同樂高積木，用戶只需要選擇合適的積木組合，并且在最頂端署上自己的名字(最后個標準化組件是用戶的app)。這也就是基于docker的PaaS產品的原型。

　　特性

　　在docker的網站上提到了docker的典型場景：

• Automating the packaging and deployment of applications

• Creation of lightweight, private PAAS environments

• Automated testing and continuous integration/deployment

• Deploying and scaling web apps, databases and backend services

　　由于其基于LXC的輕量級虛擬化的特點，docker相比KVM之類最明顯的特點就是啟動快，資源占用小。因此對于構建隔離的標準化的運行環境，輕量級的PaaS(如dokku)，構建自動化測試和持續集成環境，以及一切可以橫向擴展的應用(尤其是需要快速啟停來應對峰谷的web應用)。

1. 構建標準化的運行環境，現有的方案大多是在一個baseOS上運行一套puppet/chef，或者一個image文件，其缺點是前者需要base OS許多前提條件，后者幾乎不可以修改(因為copy on write 的文件格式在運行時rootfs是read only的)。并且后者文件體積大，環境管理和版本控制本身也是一個問題。

2. PaaS環境是不言而喻的，其設計之初和dotcloud的案例都是將其作為PaaS產品的環境基礎。

3. 因為其標準化構建方法(buildfile)和良好的REST API，自動測試和持續集成/部署能夠很好的集成進來。

4. 因為LXC輕量級的特點，其啟動快，而且docker能夠只加載每個container變化的部分，這樣資源占用小，能夠在單機環境下與KVM之類的虛擬化方案相比能夠更加快速和占用更少資源。

　　局限

　　Docker并不是全能的，設計之初也不是KVM之類虛擬化手段的替代品，簡單總結幾點：

1. Docker是基于Linux 64bit的，無法在Windows/Unix或32bit的Linux環境下使用。

2. LXC是基于cgroup等linux kernel功能的，因此container的guest系統只能是linux base的。

3. 隔離性相比KVM之類的虛擬化方案還是有些欠缺，所有container公用一部分的運行庫。

4. 網絡管理相對簡單，主要是基于namespace隔離。

5. cgroup的cpu和cpuset提供的cpu功能相比KVM的等虛擬化方案相比難以度量(所以dotcloud主要是按內存收費)

6. docker對disk的管理比較有限

7. container隨著用戶進程的停止而銷毀，container中的log等用戶數據不便收集。

　　針對1-2，有windows base應用的需求的基本可以pass了。3-5主要是看用戶的需求，到底是需要一個container還是一個VM，同時也決定了docker作為IaaS不太可行。針對6-7，雖然是docker本身不支持的功能，但是可以通過其他手段解決(disk quota, mount --bind)。總之，選用container還是vm，就是在隔離性和資源復用性上做權衡。

　　另外，即便docker 0.7能夠支持非AUFS的文件系統，但是由于其功能還不穩定，商業應用或許會存在問題，而AUFS的穩定版需要kernel 3.8，所以如果想復制dotcloud的成功案例，可能需要考慮升級kernel或者換用ubuntu的server版本(后者提供deb更新)。這也是為什么開源界更傾向于支持ubuntu的原因(kernel版本)。

　　原理

　　Docker核心解決的問題是利用LXC來實現類似VM的功能，從而利用更加節省的硬件資源提供給用戶更多的計算資源。同VM的方式不同, LXC其并不是一套硬件虛擬化方法 —— 無法歸屬到全虛擬化、部分虛擬化和半虛擬化中的任意一個，而是一個操作系統級虛擬化方法，理解起來可能并不像VM那樣直觀。所以我們從虛擬化要docker要解決的問題出發，看看它是怎么滿足用戶虛擬化需求的。

　　用戶需要考慮虛擬化方法，尤其是硬件虛擬化方法，需要借助其解決的主要是以下4個問題:

• 隔離性：每個用戶實例之間相互隔離，互不影響。 硬件虛擬化方法給出的方法是VM，LXC給出的方法是container，更細一點是kernel namespace。

• 可配額/可度量：每個用戶實例可以按需提供其計算資源，所使用的資源可以被計量。硬件虛擬化方法因為虛擬了CPU, memory可以方便實現，LXC則主要是利用cgroups來控制資源。

• 移動性：用戶的實例可以很方便地復制、移動和重建。硬件虛擬化方法提供snapshot和image來實現，docker(主要)利用AUFS實現。

• 安全性：這個話題比較大，這里強調是host主機的角度盡量保護container。硬件虛擬化的方法因為虛擬化的水平比較高，用戶進程都是在KVM等虛擬機容器中翻譯運行的，然而對于LXC，用戶的進程是lxc-start進程的子進程，只是在Kernel的namespace中隔離的，因此需要一些kernel的patch來保證用戶的運行環境不會受到來自host主機的惡意入侵，dotcloud(主要是)利用kernel grsec patch解決的。

　　方法

　　隨著Docker在云計算市場中領先地位的日益穩固，容器技術也成為了一種主流技術。為了對用戶的應用程序使用容器技術，可遵循以下五個步驟。

　　Docker容器技術已在云計算市場中風靡一時了，而眾多主流供應商則面臨著技術落后的窘境。那么，是什么讓Docker容器技術變得如此受歡迎呢？對于剛入門的新手來說，容器技術可實現不同云計算之間應用程序的可移植性，以及提供了一個把應用程序拆分為分布式組件的方法。此外，用戶還可以管理和擴展這些容器成為集群。

　　在企業用戶準備把應用程序遷往容器之前，理解應用程序的遷移過程是非常重要的。這里將介紹把用戶應用程序遷往Docker容器的五個基本步驟。

　　步驟1：分解

　　一般來說，應用程序都是復雜的，它們都有很多的組件。例如，大多數應用程序都需要數據庫或中間件服務的支持以實現對數據的存儲、檢索和集成。所以，需要通過設計和部署把這些服務拆分成為它們自己的容器。如果一個應用程序能夠被拆分成為越多的分布式組件，那么應用程序擴展的選擇則越多。但是，分布式組件越多也意味著管理的復雜性越高。

　　步驟2：選擇一個基礎映像

　　當執行應用程序遷移時，應盡量避免推倒重來的做法。搜索Docker注冊庫找到一個基本的Docker映像并將其作為應用程序的基礎來使用。

　　隨著時間的推移，企業將會發現這些Docker注冊庫中基本映像的價值所在。請記住，Docker支持著一個Docker開發人員社區，所以項目的成功與否很大程度上取決于用戶對于映像管理和改良的參與度。

　　步驟3：解決安全性和管理問題

　　安全性和管理應當是一個高優先級的考慮因素。企業用戶不應再把它們當作應用程序遷移至容器的最后一步。反之，企業必須從一開始就做好安全性和管理的規劃，把它們的功能納入應用程序的開發過程中，并在應用程序運行過程中積極主動地關注這些方面。這就是企業應當花大功夫的地方。

　　基于容器的應用程序是分布式應用程序。企業應當更新較老的應用程序以支持聯合身份管理方法，這將非常有利于確保分布式應用程序的安全性。為了做到這一點，應為每一個應用程序組件和數據提供一個唯一的標識符，這個標識符可允許企業在一個細粒度的級別上進行安全性管理。企業用戶還應當增加一個日志記錄的方法。

　　步驟4：增加代碼

　　為了創建映像，企業用戶需要使用一個Dockerfile來定義映像開發的必要步驟。一旦創建了映像，企業用戶就應將其添加至Docer Hub。

　　步驟5：配置、測試、部署

　　應對在容器中運行的應用程序進行配置，以便于讓應用程序知道可以在哪里連接外部資源或者應用程序集群中的其他容器。企業用戶可以把這些配置部署在容器中或使用環境變量。

　　對基于容器的應用程序進行測試類似于對其他分布式應用程序的測試。企業可以對每個容器進行組件測試，并將容器集群作為一個整體進行測試。 確定應用程序應如何能夠在負載增加的情況下進行擴展。如果用戶正在使用一個集群管理器（例如Swarm），則可測試其性能。

　　最后，把容器部署到實際生產環境中。為了積極主動地關注基于容器的應用程序的運行狀況，可考慮實施必要的監控和管理機制。確保打開日志記錄功能。

　　很多應用程序遷移至云計算都是采用容器技術的。雖然遷移有一點復雜，但是容器可以保護應用程序投資并賦予了它一個更長的使用壽命。

　　安全

　　1. 確保Docker環境安全

　　Docker十分火熱，很多人表示很少見到如此能夠吸引行業興趣的新興技術。然而，當興奮轉化為實際部署時，企業需要注意Docker的安全性。

　　了解Docker的人都知道，Docker利用容器將資源進行有效隔離。因此容器相當于與Linux OS，和hypervisor有著幾乎相同的安全運行管理和配置管理級別。但當涉及到安全運營與管理，以及具有保密性、完整性和可用性的通用控件的支持時，Docker可能會讓你失望。

　　當容器運行在本地系統上時，企業可以通過其安全規則確保安全性。但一旦容器運行在云端，事實就不會如此簡單了。

　　當Docker運行在云提供商平臺上時，安全性變得更加復雜。你需要知道云提供商正在做什么，或許你正在與別人共享一臺機器。

　　雖然容器沒有內置的安全因素，而且像Docker這樣的新興技術很難有比較全面的安全措施，但這并不意味著以后也不會出現。

　　2. 確保容器部署安全性

　　也有專家將Docker安全問題的實質定位于配置安全，認為Docker目前的問題是很難配置一個安全的容器。雖然現在Docker的開發人員通過創建非常小的容器來降低攻擊面，但問題在于大型企業內部在生產環境中運行Docker容器的員工需要有更多的可見性和可控性。

　　專家認為，大約90%的外部網絡攻擊并不是超級復雜的，攻擊者多是利用了管理員的行為漏洞，比如配置錯誤或者未及時安裝補丁。

　　因此，企業在部署數千或數萬臺容器時，能夠確保這些容器都遵守企業安全策略進行配置是至關重要的事情。

　　為解決這個問題，就需要增加Docker容器部署的實時可見性，同時實施企業制定的安全策略。

　　3. 硬件上的Docker安全中心

　　在新的功能中有硬件的部分，可以跨任何基礎架構，允許開發和隨后的升級中的數字編碼簽名。構建在Docker Trust框架之上用來進行鏡像發布者認證，同時進行新的鏡像掃描和官方漏洞檢測，以便能夠更好地理解容器內部是什么。

　　命名空間是本周發布的另外一個Docker安全升級。允許IT運用來為基于用戶群組的容器指派授權，約束了主機的訪問根源，并指定了系統管理員，限制了群組對于指定服務的訪問。

　　鏡像掃描對于Docker Hub上的所有官方版本都可用，同時命名空間和硬件簽名則在Docker的實驗渠道提供。

　　安全問題仍舊是容器采納要解決的最大問題，尤其是如果大量容器是便攜的，IDC研究經理Larry Carvalho說道。通過硬件解決這個問題很明智，因為這樣更難以介入，并且提供了未來可能被使用的大量容器的效率。

　　Carvhalho說：“他們還應該解決的一個問題是容量，你沒有辦法在軟件層面做大量的安全，因為要有很多開支。”

　　應用

　　有了docker這么個強有力的工具，更多的玩家希望了解圍繞docker能做什么。

　　1. Sandbox

　　作為sandbox大概是container的最基本想法了 —— 輕量級的隔離機制，快速重建和銷毀，占用資源少。用docker在開發者的單機環境下模擬分布式軟件部署和調試，可謂又快又好。

　　同時docker提供的版本控制和image機制以及遠程image管理，可以構建類似git的分布式開發環境。可以看到用于構建多平臺image的packer以及同一作者的vagrant已經在這方面有所嘗試了。

　　2. PaaS

　　dotcloud、heroku以及cloudfoundry都試圖通過container來隔離提供給用戶的runtime和service，只不過dotcloud采用docker，heroku采用LXC，cloudfoundry采用自己開發的基于cgroup的warden。基于輕量級的隔離機制提供給用戶PaaS服務是比較常見的做法，PaaS 提供給用戶的并不是OS而是runtime+service，因此OS級別的隔離機制向用戶屏蔽的細節已經足夠。而docker的很多分析文章提到『能夠運行任何應用的“PaaS”云』，只是從image的角度說明docker可以從通過構建image實現用戶app的打包以及標準服務service image的復用，而非常見的buildpack的方式。

　　由于對Cloud Foundry和docker的了解，接下來談談筆者對PaaS的認識。PaaS號稱的platform一直以來都被當做一組多語言的runtime和一組常用的middleware，提供這兩樣東西，即可被認為是一個滿足需求的PaaS。然而PaaS對能部署在其上的應用要求很高:

• 運行環境要簡單 - buildpack雖然用于解決類似問題，但仍然不是很理想。

• 要盡可能的使用service - 常用的mysql, apache倒能理解，但是類似log之類的如果也要用service就讓用戶接入PaaS平臺，讓用戶難以維護。

• 要盡可能的使用"平臺” - 單機環境構建出目標PaaS上運行的實際環境比較困難，開發測試工作都離不開"平臺”。

• 缺少可定制性 - 可選的中間件有限，難于調優和debug。

　　綜上所述部署在PaaS上的應用幾乎不具有從老平臺遷移到之上的可能，新應用也難以進入參數調優這種深入的工作。個人理解還是適合快速原型的展現，和短期應用的嘗試。

　　然而docker確實從另一個角度（類似IaaS+orchestration tools）實現了用戶運行環境的控制和管理，然而又基于輕量級的LXC機制，確實是一個了不起的嘗試。 筆者也認為IaaS + 靈活的orchestration tools（深入到app層面的管理，如bosh）是交付用戶環境最好的方式。