轉載於嘉爲科技https://baijiahao.baidu.com/s?id=1614385619899407709&wfr=spider&for=pc
目錄
Docker與容器
初識容器與Docker爲什麼要使用DockerDocker優勢簡介
Docker核心概念
Docker客戶端和服務器Docker鏡像Docker倉庫Docker容器Docker的核心實現技術數據卷容器網絡技術DcokfileDocker命令彙總
Docker與虛擬化
Docker爲什麼能夠成功？研發、測試和運維該如何看待Docker？Docker與虛擬化各自邊界在哪裏？Docker能取代虛擬化嗎？
Docker學習資源彙總
Docker與容器
1 初識容器與Docker
容器技術起源於Linux開源平臺，並且經歷了比較長時間的發展階段，其中最重要的成果是Linux容器（Linux Containers，LXC）技術。
IBM DeveloperWorks網站關於容器技術的描述是這樣的：“容器有效地將由單個操作系統管理的資源劃分到孤立的組中，以更好地在孤立的組之間平衡有衝突的資源使用需求。與虛擬化相比，這樣既不需要指令級模擬，也不需要即時編譯。容器可以在覈心CPU本地運行指令，而不需要任何專門的解釋機制。此外，也避免了準虛擬化（paravirtualization）和系統調用替換中的複雜性。”
聽不明白，是吧？
直白的翻譯過來就是這樣的：如果認爲虛擬機是模擬運行的一整套操作系統（包括內核、應用運行態環境和其他系統環境）和跑在上面的應用，那麼容器就是獨立運行的一個（或一組）應用，以及它們必需的運行環境。
容器中運行的就是一個或者多個應用程序，以及應用運行所需要的環境。容器直接運行在操作系統內核之上的用戶空間。容器技術可以讓多個獨立的用戶空間運行在同一臺宿主機上。容器既可以運行在物理機也可以運行在虛擬機上，當然也可以運行在公有云主機上。
在LXC之前，這些相關技術經過多年的演化已經十分成熟和穩定，但是由於種種原因，它們並沒有被很好地集成到主流的Linux內核中，用戶使用起來並不方便。例如，如果用戶要使用OpenVZ技術，需要先手動給操作系統打上特定的內核補丁方可使用，而且不同版本並不一致。類似的困難造成在很長一段時間內，這些優秀的技術只流傳於技術人員的小圈子中。
後來LXC項目借鑑了前人成熟的容器設計理念，並基於一系列新引入的內核特性，實現了更具擴展性的虛擬化容器方案。更加關鍵的是，LXC終於被集成到了主流Linux內核中，進而成爲了Linux系統輕量級容器技術的事實標準。從技術層面來看，LXC已經趟過了絕大部分的“坑”，完成了容器技術實用化的大半歷程。
那麼Docker又是什麼呢？
Docker是輕量級容器管理引擎，它的出現爲軟件開發和雲計算平臺之間建立了橋樑。我們如果把容器對標爲虛擬機的話，Docker可以對標爲hypervisor管理層，它是一個容器管理引擎技術，而不是容器本身。這一點是經常被混淆的。它的作用是提供了一套優雅、簡潔的工具，利用linux開源生態已有技術，實現容器橫向和縱向生命週期的完整、簡單、高效、快捷的管理。
在前述LXC的基礎上，Docker進一步優化了容器的使用體驗，讓它進入了尋常百姓家。
首先，Docker提供了各種容器管理工具（如分發、版本、移植等）讓用戶無需關注底層的操作，可以更簡單明瞭地管理和使用容器；其次，Docker通過引入分層文件系統構建和高效的鏡像機制，降低了遷移難度，極大地提升了用戶體驗。用戶操作Docker容器就像操作應用自身一樣簡單。
Docker是基於Go語言實現的開源容器項目，誕生於2013年年初，最初發起者是dotCloud公司。Docker自開源後受到廣泛的關注和討論，目前已有多個相關項目（包括Docker三劍客、Kubernetes 等），逐漸形成了圍繞Docker容器的生態體系。 由於Docker在業界造成的影響力實在太大，dotCloud公司後來也直接改名爲Docker Inc，並專注於Docker相關技術和產品的開發。
Docker的構想是要實現“Build，Ship and Run Any App， Anywhere”，即通過對應用的封裝（Packaging）、分發 （Distribution）、部署（Deployment）、運行（Runtime）生命週期進行管理，達到應用組件“一次封裝，到處運行”的目的。這裏的應用組件，既可以是一個Web應用、一個編譯環境，也可以是一套數據庫平臺服務，甚至是一個操作系統或集羣。
基於Linux平臺上的多項開源技術，Docker提供了高效、敏捷和輕量級的容器方案，並支持部署到本地環境和多種主流雲平臺。可以說，Docker首次爲應用的開發、運行和部署提供了“一站式”的實用解決方案。
2 爲什麼要使用Docker
（1）提供一種簡單、輕量的應用建模方式
在雲時代，開發者創建的應用必須要能很方便地在網絡上傳播，也就是說應用必須脫離底層物理硬件的限制；同時必須是“任何時間、任何地點”可獲取的。因此，開發者需要一種新型的創建分佈式應用程序的方式，快速分發和部署，這正是Docker所能夠提供的最大優勢。
Docker通過容器來打包應用，解耦應用和運行平臺。意味着遷移的時候，只需要在新的服務器上啓動需要的容器就可以了，無論新舊服務器是否是同一類型的平臺。這無疑將節約大量的寶貴時間，並降低部署過程出現問題的風險。
（2）職責的邏輯分離
使用 Docker,開發人員只需要關心容器中運行的應用程序，而運維人員只需要關心如何管理容器。Docker設計的目的就是要加強開發人員寫代碼的開發環境與應用程序要部署的生產環境的一致性，從而降低那種“開發時一切都正常，肯定是運維的問題”的風險。
（3）快速、高效的開發生命週期
Docker的目標之一就是縮短代碼從開發、測試到部署、上線運行的週期，讓你的應用程序具備可移植性，易於構建，並易於協作。
（4）鼓勵使用面向服務的架構
Docker還鼓勵面向服務的架構和微服務架構。Docker推薦單個容器只運行一個應用程序或進程，這樣就形成了一個分佈式的應用程序模型，在這種模型下，應用程序或服務都可以表示爲一系列內部互聯的容器，從而使分佈式部署應用程序，擴展或調試應用程序都變得非常簡單，同時也提高了程序的內省性。
Docker核心概念集合
1 Docker客戶端和服務器
Docker 架構如下圖所示：
Docker 採用的是 Client/Server 架構。客戶端向服務器發送請求，服務器負責構建、運行和分發容器。客戶端和服務器可以運行在同一個 Host 上，客戶端也可以通過 socket 或 REST API 與遠程的服務器通信。
最常用的 Docker 客戶端是 docker 命令。通過 docker 我們可以方便地在 Host 上構建和運行容器。docker 支持很多操作（子命令）。除了 docker 命令行工具，用戶也可以通過 REST API 與服務器通信。
關於Docker API我們後續會詳細介紹。
Docker 服務器：Docker daemon 是服務器組件，以 Linux 後臺服務的方式運行。
Docker daemon 運行在 Docker host 上，負責創建、運行、監控容器，構建、存儲鏡像。
默認配置下，Docker daemon 只能響應來自本地 Host 的客戶端請求。如果要允許遠程客戶端請求，需要在配置文件中打開 TCP 監聽。
2 Docker鏡像
Docker的大部分操作都圍繞着它的三大核心概念——鏡像、容器和倉庫而展開。因此，準確把握這三大核心概念對於掌握Docker技術尤爲重要。
Docker鏡像類似於虛擬機鏡像，可以將它理解爲一個只讀的模板。例如，一個鏡像可以包含一個基本的操作系統環境，裏面僅安裝了Apache應用程序（或用戶需要的其他軟件）。可以把它稱爲一個Apache鏡像。
鏡像是創建Docker容器的基礎。通過版本管理和增量的文件系統，Docker提供了一套十分簡單的機制來創建和更新現有的鏡像，用戶甚至可以從網上下載一個已經做好的應用鏡像，並直接使用。
Docker鏡像與傳統xen虛擬化中提到的鏡像或者虛擬機模板底層實現原理是截然不同的。聯合文件系統是實現Docker鏡像的技術基礎。
Docker鏡像是由文件系統疊加而成。最底端是一個引導文件系統，即bootfs，這很像典型的Linux/Unix的引導文件系統。Docker用戶幾乎永遠不會和引導文件系統有什麼交互。實際上，當一個容器啓動後，它將會被移到內存中，而引導文件系統則會被卸載（unmount），以留出更多的內存供 initrd磁盤鏡像使用。
Docker鏡像的第二層是root文件系統rootfs ,它位於引導文件系統之上。rootfs可以是一種或多種操作系統(如 Debian或者Ubuntu文件系統)。
在傳統的Linux引導過程中，root文件系統會最先以只讀的方式加載，當引導結束並完成了完整性檢查之後，它纔會被切換爲讀寫模式。但是在Docker裏，root文件系統永遠只能是隻讀狀態，並且Docker利用聯合加載(union mount)技術又會在root文件系統層上加載更多的只讀文件系統。
聯合加載指的是一次同時加載多個文件系統，但是在外面看起來只能看到一個文件系統。聯合加載會將各層文件系統疊加到一起，這樣最終的文件系統會包含所有底層的文件和目錄。
Docker將這樣的文件系統稱爲鏡像。一個鏡像可以放到另一個鏡像的頂部。位於下面的鏡像稱爲父鏡像(parent image),可以依次類推，直到鏡像棧的最底部，最底部的鏡像稱爲基礎鏡像(base image)。
最後，當從一個鏡像啓動容器時，Docker會在該鏡像的最頂層加載一個讀寫文件系統。我們想在Docker中運行的程序就是在這個讀寫層中執行的。
當 Docker第一次啓動一個容器時，初始的讀寫層是空的。當文件系統發生變化時，這些變化都會應用到這一層上。比如，如果想修改一個文件，這個文件首先會從該讀寫層下面的只讀層複製到該讀寫層。該文件的只讀版本依然存在，但是已經被讀寫層中的該文件副本所隱藏。
通常這種機制被稱爲寫時複製(copy on write)，這也是使Docker如此強大的技術之一。 每個只讀鏡像層都是隻讀的，並且以後永遠不會變化。當創建一個新容器時，Docker會構建出一個鏡像棧，並在棧的最頂端添加一個讀寫層。這個讀寫層再加上其下面的鏡像層以及一些配置數據，就構成了一個容器。
3 Docker容器
Docker容器類似於一個輕量級的沙箱，Docker利用容器來運行和隔離應用。容器是從鏡像創建的應用運行實例。可以將其啓動、開始、停止、刪除，而這些容器都是彼此相互隔離的、互不可見的。
可以把容器看做是一個簡易版的Linux系統環境（包括root用戶權限、進程空間、用戶空間和網絡空間等）以及運行在其中的應用程序打包而成的盒子。
鏡像自身是隻讀的。容器從鏡像啓動的時候，會在鏡像的最上層創建一個可寫層。
Docker可以幫用戶構建和部署容器，用戶只需要把自己的應用程序或服務打包放進容器即可。容器是基於鏡像啓動起來的，容器中可以運行一個或多個進程。我們可以認爲，鏡像是Docker生命週期中的構建或打包階段，而容器則是啓動或執行階段。
總結起來，Docker容器就是：
一個鏡像格式；一系列標準的操作；一個執行環境。
Docker借鑑了標準集裝箱的概念。標準集裝箱將貨物運往世界各地，Docker將這個模型運用到自己的設計哲學中，唯一不同的是：集裝箱運輸貨物，而 Docker運輸軟件。 每個容器都包含一個軟件鏡像，也就是容器的“貨物”，而且與真正的貨物一樣，容器裏的軟件鏡像可以進行一些操作。例如，鏡像可以被創建、啓動、關閉、重啓以及銷燬。
和集裝箱一樣，Docker在執行上述操作時，並不關心容器中到底塞進了什麼，它不管裏面是Web服務器，還是數據庫，或者是應用程序服務器什麼的。所有容器都按照相同的方式將內容“裝載”進去。
Docker也不關心用戶要把容器運到何方：用戶可以在自己的筆記本中構建容器，上傳到 Registry，然後下載到一個物理的或者虛擬的服務器來測試，再把容器部署到Amazon EC2 主機的集羣中去。像標準集裝箱一樣，Docker容器方便替換，可以疊加，易於分發，並且儘量通用。
使用 Docker,可以快速構建一個應用程序服務器、一個消息總線、一套實用工具、一個持續集成(continuous integration, CI)測試環境或者任意一種應用程序、服務或工具。可以在本地構建一個完整的測試環境，也可以爲生產或開發快速複製一套複雜的應用程序棧。
可以說，Docker的應用場景相當廣泛。
4 Registry與Docker倉庫
Docker倉庫類似於代碼倉庫，它是Docker集中存放鏡像文件的場所。
有時候會看到有資料將Docker倉庫和倉庫註冊服務器 （Registry）混爲一談，並不嚴格區分。實際上，倉庫註冊服務器是存放倉庫的地方，其上往往存放着多個倉庫。每個倉庫集中存放某一類鏡像，往往包括多個鏡像文件，通過不同的標籤（tag）來進行區分。例如存放Ubuntu操作系統鏡像的倉庫稱爲Ubuntu倉庫，其中可能包括14.04、12.04等不同版本的鏡像。
Registry與Docker之間關係如下圖所示：
根據所存儲的鏡像公開分享與否，Docker倉庫可以分爲公開倉庫 （Public）和私有倉庫（Private）兩種形式。目前，最大的公開倉庫是官方提供的Docker Hub，其中存放了數量龐大的鏡像供用戶下載。 國內不少雲服務提供商（如時速雲、阿里雲等）也提供了倉庫的本地源，可以提供穩定的國內訪問。
當然，用戶如果不希望公開分享自己的鏡像文件，Docker也支持用戶在本地網絡內創建一個只能自己訪問的私有倉庫。當用戶創建了自己的鏡像之後就可以使用push命令將它上傳到指定的公有或者私有倉庫。這樣用戶下次在另外一臺機器上使用該鏡像時，只需要將其從倉庫上pull下來就可以了。
可以看出，Docker利用倉庫管理鏡像的設計理念與Git非常相似，實際上在理念設計上借鑑了Git的很多優秀思想。
5 Docker的技術組件
Docker可以運行於任何安裝了現代Linux內核的x64主機上。推薦的內核版本是3.8或者更高。Docker的開銷比較低，可以用於服務器、臺式機或筆記本。
Docker的技術組件主要包括以下幾個部分。事實上，每個技術組件展開都是非常長的篇幅，這裏我們就不展開論述，有興趣的同學可以通過末尾提供的學習資源彙總，自行查看相關更加詳細的資料。
一個原生的Linux容器格式，Docker中稱爲libcontainer。Linxu內核的命名空間（namespace） , 用於隔離文件系統、進程和網絡。文件系統隔離：每個容器都有自己的root文件系統。進程隔離：每個容器都運行在自己的進程環境中。網絡隔離：容器間的虛擬網絡接口和IP地址都是分開的。資源隔離和分組：使用cgroups（即 control group, Linux的內核特性之一）將 CPU 和內存之類的資源獨立分配給每個Docker容器。寫時複製:文件系統都是通過寫時複製創建的，這就意味着文件系統是分層的、快速的，而且佔用的磁盤空間更小。日誌：容器產生的STDOUT、STDERR和 STDIN這些IO流都會被收集並記入日誌， 用來進行日誌分析和故障排錯。交互式shell：用戶可以創建一個僞tty終端，將其連接到STDIN ,爲容器提供一個交互式的shell。
6 數據卷：數據持久保持、容器間共享和遷移
數據卷是一個可供容器使用的特殊目錄，它將主機操作系統目錄直接映射進容器，類似於Linux中的mount操作。
數據卷可以提供很多有用的特性，如下所示：
數據卷可以在容器之間共享和重用，容器間傳遞數據將變得高效方便；對數據卷內數據的修改會立馬生效，無論是容器內操作還是本地操作；對數據卷的更新不會影響鏡像，解耦了應用和數據；卷會一直存在，直到沒有容器使用，可以安全地卸載它。
在用docker run命令的時候，使用-V標記可以在容器內創建一個數據卷。多次重複使用-v標記可以創建多個數據卷。
如果用戶需要在多個容器之間共享一些持續更新的數據，最簡單的方式是使用數據卷容器。數據卷容器也是一個容器，但是它的目的是專門用來提供數據卷供其他容器掛載。
首先，創建一個數據卷容器dbdata，並在其中創建一個數據卷掛載到/dbdata：
然後，可以在其他容器中使用--volumes-from來掛載dbdata容器中的數據卷，例如創建db1和db2兩個容器，並從dbdata容器掛載數據卷：
此時，容器db1和db2都掛載同一個數據捲到相同的/dbdata目錄。 三個容器任何一方在該目錄下的寫入，其他容器都可以看到。
7 容器網絡技術：外部訪問與容器互聯
總體而言，在容器中大致可以通過以下幾種虛擬網絡技術實現外部對於容器的訪問以及容器之間的互聯互通。
（1） 宿主機端口映射
在啓動容器的時候，如果不指定對應的參數，在容器外部是無法通過網絡來訪問容器內的網絡應用和服務的。
當容器中運行一些網絡應用，要讓外部訪問這些應用時，可以通過-P或-p參數來指定端口映射。當使用-P（大寫的）標記時，Docker 會隨機映射一個49000~49900的端口到內部容器開放的網絡端口：
（2）容器互聯
容器的互聯（linking）是一種讓多個容器中應用進行快速交互的方式。它會在源和接收容器之間創建連接關係，接收容器可以通過容器名快速訪問到源容器，而不用指定具體的IP地址。
使用--link參數可以讓容器之間安全地進行交互。
下面先創建一個新的數據庫容器：
然後創建一個新的web容器，並將它連接到db容器：
Docker相當於在兩個互聯的容器之間創建了一個虛機通道，而且不用映射它們的端口到宿主主機上。在啓動db容器的時候並沒有使用-p和-P標記，從而避免了暴露數據庫服務端口到外部網絡上。
Docker通過兩種方式爲容器公開連接信息：
更新環境變量；更新/etc/hosts文件。
（3）使用Docker虛擬網橋
Docker啓動時會在主機上自動創建一個docker0虛擬網橋，實際上是一個Linux網橋，可以理解爲一個軟件交換機，它會在掛載其上的接口之間進行轉發，如圖所示。
同時，Docker隨機分配一個本地未佔用的私有網段（在RFC1918 中定義）中的一個地址給docker0接口。比如典型的172.17.42.1，掩碼爲255.255.0.0。此後啓動的容器內的網口也會自動分配一個同一網段（172.17.0.0/16）的地址。
當創建一個Docker容器的時候，同時會創建了一對veth pair接口（當數據包發送到一個接口時，另外一個接口也可以收到相同的數據包）。這對接口一端在容器內，即eth0；另一端在本地並被掛載到docker0網橋，名稱以veth開頭（例如vethAQI2QT）。
通過這種方式，主機可以跟容器通信，容器之間也可以相互通信。如此一來，Docker就創建了在主機和所有容器之間一個虛擬共享網絡。
除了默認的docker0網橋，用戶也可以指定網橋來連接各個容器。在啓動Docker服務的時候，使用-b BRIDGE或--bridge=BRIDGE來指定使用的網橋。
（4）libnetwork插件化網絡功能
從1.7.0版本開始，Docker正式把網絡跟存儲這兩部分的功能實現都以插件化形式剝離出來，允許用戶通過指令來選擇不同的後端實現。這也是Docker希望構建圍繞着容器的強大生態系統的一些積極的嘗試。
剝離出來的獨立容器網絡項目叫libnetwork，從名字就能看出來，它希望將來爲不同容器定義統一規範的網絡層標準。事實上，這套網絡虛擬化邏輯與Vmware等傳統虛擬化廠商的大致是一樣的。
libnetwork中容器網絡模型（Container Networking Model，CNM）十分簡潔，可以讓上層使用網絡的大量應用容器最大程度上不去關心底層實現。容器網絡模型的結構如圖所示。
包括三種基本元素：
Sandbox（沙盒）：代表一個容器（準確地說，是其網絡命名空間）；Endpoint（接入點）：代表網絡上可以掛載容器的接口，會分配IP地址；Network可以連通多個接入點的一個子網。
可見，對於使用CNM的容器管理系統來說，具體底下網絡如何實現，不同子網彼此怎麼隔離，有沒有QoS，都可以不關心。只要插 件能提供網絡和接入點，只需把容器給接上或者拔下，剩下的都是插件驅動自己去實現。這樣就解耦和容器和網絡功能，十分靈活。
CNM的典型生命週期如下圖所示。首先，是驅動註冊自己到網絡控制器，網絡控制器使用驅動類型，來創建網絡，然後在創建的網絡上創建接口，最後把容器連接到接口上即可。銷燬過程則正好相反，先把容器從接入口上卸載，然後刪除接入口和網絡即可。
目前CNM支持的驅動類型有四種：Null、Bridge、Overlay、Remote。簡單介紹如下：
Null：不提供網絡服務，容器啓動後無網絡連接；Bridge：就是Docker傳統上默認用Linux網橋和Iptables實現的單機網絡；Overlay：是用vxlan隧道實現的跨主機容器網絡；Remote：擴展類型，預留給其他外部實現的方案，比如有一套第三方的SDN方案（如OpenStack Neutron），就可以接進來。
8 Dcokfile：創建鏡像
創建鏡像的方法主要有三種：基於已有鏡像的容器創建、基於本地模板導入、基於Dockerfile創建。
創建Docker鏡像的第一種方法是使用docker com m it命令。可以將此想象爲我們是在往版本控制系統裏提交變更。
用戶也可以直接從一個操作系統模板文件導入一個鏡像，主要使用docker import命令。命令格式爲docker import[OPTIONS]file|URL|-[REPOSITORY[:TAG]]。
並不推薦使用 docker commit的方法來構建鏡像。相反，推薦使用被稱爲 Dockerfile的定義文件和docker build命令來構建鏡像。
Dockerfile使用基本的基於DSL (Domain Specific Language)) 語法的指令來構建一個Docker鏡像，推薦使用 Dockerfile方法來代替docker commit.因爲通過前者來構建鏡像更具備可重複性、 透明性以及冪等性。
一旦有了 Dockerfile，我們就可以使用docker build命令基於該Dockerfile 中的指令構建一個新的鏡像。
Dockerfile由一行行命令語句組成，並且支持以#開頭的註釋行。 一般而言，Dockerfile分爲四部分：基礎鏡像信息、維護者信息、鏡像操作指令和容器啓動時執行指令。例如：
其中，一開始必須指明所基於的鏡像名稱，接下來一般是說明維護者信息。後面則是鏡像操作指令，例如RUN指令，RUN指令將對鏡像執行跟隨的命令。每運行一條RUN指令，鏡像就添加新的一層，並提交。最後是CMD指令，用來指定運行容器時的操作命令。
Dockerfile指令說明
9 Docker API
除了通過Docker客戶端與Docker引擎進行交互之外，Docker還支持通過API的方式來與Docker的各個組件進行交互，包括Docker Registry、Docker Hub和Docker 守護進程等。
在 Docker生態系統中一共有3 種 API。
Registry API：提供了與來存儲Docker鏡像的Docker Registry集成的功能。Docker Hub API：提供了與 Docker Hub集成的功能。Docker Remote API：提供與Docker守護進程進行集成的功能。
所有這3 種 API都是RESTful風格的。其中Remote API進是通過程序與Docker進行集成和交互的核心內容。
通過API我們可以實現Docker的幾乎全方位的管理，包括鏡像管理、容器管理、公有倉庫管理、註冊服務器管理等，在大規模容器雲自動化管理、可視化運維管理以及DevOps等場景中，尤其有用。
並且自Docker 的 0.9版本開始Docker Remote API開始提供了認證機制。這種認證機制採用了 TLS/SSL證書來確保用戶與API之間連接的安全性。
10 Docker命令彙總
一張圖總結Docker的命令
Docker與虛擬化
1 Docker爲什麼能夠成功？
Docker實現的種種基礎技術（cgroups、namespace、分層文件系統）在Docker之前已經存在很多年。並且，LXC也在諸多企業的生產環境中得到了大量的應用實踐，並得到了極爲明顯的性能優勢。
Google大規模容器集羣的性能比傳統虛擬機要高很多，接近於Bare Metal。與傳統虛擬機相比，容器集羣讓這些公司擁有秒級而非分鐘級的彈性計算伸縮能力，同時使用更少的機器運行更多實例。
既然容器技術有如此大的優勢，爲什麼Docker之前，容器並沒有引發廣泛的關注呢？核心的問題在於易用性，而Docker解決了這個問題。
Docker首次創造了一種簡單易行並且覆蓋應用全生命週期的工作流，用戶可以通過簡單的指令或Restful API來拉取、打包、運行和維護容器。這種簡化從根本上降低了應用程序部署的難度，極大地提高了應用運行時環境的部署與維護的效率。
用戶可以不依賴類似Ansible、Chef、Puppet這類的配置管理和發佈系統，不需要在部署中同時關注基礎系統與軟件的安裝配置，以及應用的安裝調試。
Docker提供了一種統一的實踐方法，每個服務（或應用）維護一個Dockerfile文件。即便使用編排工具如Docker Compose，一個服務（或應用）也只需維護一個docker-compose.yml文件。應用程序及其運行時環境全部打包到一個簡單易讀的Dockerfile或Compose文件中， 開發團隊和運維團隊都可以透明地合作維護這個文件，極大降低了溝通成本與部署成本，極大滿足了研發團隊與DevOps團隊、運維團隊之間的溝通需求，清晰劃分了責任邊界。
Docker正以一種前所未有的方式讓用戶可以在各種Linux發行版、各種開發環境中快速切換，這對應用開發者來說真是一種福音。
使用各種開發環境的用戶，再也不必擔心破壞主機的系統環境（如環境變量）和應用程序。系統架構師們也可以使用Docker來快速搭建各種網絡架構的系統，且可以方便地管理這些系統之間的數據連接和共享。
目前Docker發展迅速，基於Docker的PaaS平臺也層出不窮。這讓技術創業者無需折騰服務器部署，只需專注業務代碼的實現即可。
真正解決用戶痛點，真正帶來效率的提升，是一個產品和技術能最終成功的關鍵！
2 Docker與虛擬化的區別
兩者的架構區別如下：
前人總結的兩者的主要區別如下：
關於Docker是否能夠取代虛擬化，是個被討論很久的問題，個人愚見：虛擬化和Docker並不是對立與相互取代的關係，場景化需求才是兩種技術選擇的關鍵。
虛擬機和容器技術本身並不對立，也不存在誰取代誰的問題，關鍵是企業是否合理運用技術在合理的應用場景當中解決相應的技術問題，未來的企業級雲平臺也應該囊括對這些技術的支持，以滿足企業對不同業務所需不同技術棧的靈活選擇！
關於這一點，我們後面還有文章深度探討。
事實上，Docker技術極大的改變了企業建設應用系統的流程和生態，Docker本身也與虛擬化、微服務架構、DevOps、自動化運維等之間有着千絲萬縷的聯繫。
我們將在後續的文章中，繼續探討兩個問題：
Docker容器技術在可見的未來，比如3-5年，能夠完全取代虛擬化技術嗎？Docker與微服務、DevOps之間有怎樣的關係？它們如何一起改變了企業應用開發的生態和工作流程？
附錄：Docker學習資源彙總
Docker官方主頁
http://www.docker.com/
Docker Hub
http://hub.docker.com
Docker官方博客
http://blog.docker.com/
Docker官方文檔
http://docs.docker.com/
Docker快速入門指南
https://www.docker.com/tryit/
Docker的GitHub源代碼
https://github.com/docker/docker
Docker Forge：收集了各種Docker工具、組件和服務
https://github.com/dockerforge
Docker郵件列
https://groups.google.com/forum/#!forum/docker-user
Docker的IRC頻道
irc.freenode.net
Docker的Twitter主頁
http://twitter.com/docker
Docker的StackOverflow問答主頁
http://stackoverflow.com/search?q=docker