Docker簡介（轉）

　　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）是交付用戶環境最好的方式。

http://kb.cnblogs.com/page/536387/