Docker最全教程——從理論到實戰(一)

Docker最全教程——從理論到實戰(一)

目錄

前言

隨着生產力的發展尤爲是彈性架構的普遍應用（好比微服務），許多一流開發者都將應用託管到了應用容器上，好比Google、微軟、亞馬遜、騰訊、阿里、京東和新浪。

 

從將來的發展方向來看，容器引擎將會愈來愈成爲主流，哪怕不是彈性架構，託管到應用容器也將是一種趨勢——由於更低的開發運維和託管成本以及對服務器的資源的優化配置。並且將來一個很大的趨勢是——無服務器計算服務。

由於相對於軟件、硬件在本地設備中的分裂，雲計算的一大特性就是將服務構建在雲上，供多種設備同時無縫調用。但事實上，雲服務在發展的過程當中還沒能實現共融共通的理想——好比，各家的雲服務是相對割裂的，開發者基於Google雲服務構建的軟件拿到亞馬遜的AWS上也許就不能用了，阿里雲的應用遷移到騰訊雲可能就存在問題了；在任務執行層面，爲防止互相干擾，雲服務廠商在同一臺服務器上執行多個任務時也會將它們隔離進行。很明顯，這樣的實際狀況和雲服務的初始理念相去甚遠。而利用容器技術，軟件能夠快速在各種雲服務和基礎設施上轉換。並且，當割裂問題被解決以後，軟件也有望在瞬間獲取大量的計算能力。

 

而Docker，就是容器引擎中的佼佼者，而且已經獲得了普遍的實踐和應用。有了Docker以後，軟件的開發工做將會變得更加容易。好比，開發者們在筆記本電腦上寫完一個軟件後，能夠將它轉移到雲服務上運行而無需作出更改；不管是本身的服務器、數據中心仍是Google、微軟、阿里雲的雲計算服務器，開發人員均可以按本身的想法在任何基礎設施之間轉移本身的軟件。這也是將來的一個願景——機器和基礎設施是能夠互相替代的，整個互聯網就是一個巨大的計算機。

Docker是如此使人嚮往和引人深刻，可是在國內，開發者廣泛遷移到雲端基本上也都是隻用到了虛擬機等基礎設施，其實你們都據說過Docker，可是老是有一道門檻擋在你們面前致使你們沒法逾越或者產生了一些偏見：

• 缺少完整的系統的教程和實踐，開發者廣泛認爲使用Docker很麻煩，只有大公司能用，門檻很高；

• 雲端容器服務產品用戶體驗不夠，對於初學者門檻過高——這個過高指的是消化這些概念和理念，而且可以掌握和可控；

• 對容器服務的認知還不夠，對它的好處以及吸引之處還不太瞭解；

• 認爲對現有系統、架構改造太大，成本過高；

• 認爲Docker只是一種單純的相對先進的技術，並不能給現有的開發帶來什麼改變；

 

什麼是Docker

Docker 是一個開源的應用容器引擎，能夠輕鬆的爲任何應用建立一個輕量級的、可移植的、自給自足的容器。開發者在本地編譯測試經過的容器能夠批量地在生產環境中部署，包括VMs（虛擬機）、bare metal、OpenStack 集羣和其餘的基礎應用平臺。

簡單的理解，Docker相似於集裝箱，各式各樣的貨物，通過集裝箱的標準化進行託管，而集裝箱和集裝箱之間沒有影響。也就是說，Docker平臺就是一個軟件集裝箱化平臺，這就意味着咱們本身能夠構建應用程序，將其依賴關係一塊兒打包到一個容器中，而後這容器就很容易運送到其餘的機器上進行運行，並且很是易於裝載、複製、移除，很是適合軟件彈性架構。

 

所以，就像船隻、火車或卡車運輸集裝箱而不論其內部的貨物同樣，軟件容器充當軟件部署的標準單元，其中能夠包含不一樣的代碼和依賴項。 按照這種方式容器化軟件，開發人員和 IT 專業人員只需進行極少修改或不修改，便可將其部署到不一樣的環境。

總而言之，Docker 是一個開放平臺，使開發人員和管理員能夠在稱爲容器的鬆散隔離的環境中構建鏡像、交付和運行分佈式應用程序。以便在開發、QA 和生產環境之間進行高效的應用程序生命週期管理。

 

Docker和虛擬機的區別

 

如上圖所示，因爲容器所需的資源要少得多（例如，它們不須要一個完整的 OS），因此它們易於部署且可快速啓動。這使你可以具備更高的密度，也就是說，這容許你在同一硬件單元上運行更多服務，從而下降了成本。

在同一內核上運行的反作用是，你得到的隔離比 VM 要少。

鏡像的主要目標是使環境（依賴項）在不一樣的部署中保持不變。 也就是說，能夠在計算機上調試它，而後將其部署到保證具備相同環境的另外一臺計算機上。

藉助容器鏡像，可打包應用或服務並採用可靠且可重現的方式對其進行部署。能夠說 Docker 不僅是一種技術，仍是一種原理和過程。

在使用Docker以前，咱們常常會聽到，「這個問題在開發環境是正常的！」。而在使用 Docker 後，你不會聽到開發人員說：「爲何它能在個人計算機上使用卻不能用在生產中？」。開發人員只需說「它在 Docker 上運行」，由於打包的 Docker 應用程序可在任何支持的 Docker 環境上執行，並且它在全部部署目標（例如，開發、QA、暫存和生產）上都按預期運行。

 

基本概念

鏡像：一個特殊的文件系統

操做系統分爲內核和用戶空間。對於 Linux 而言，內核啓動後，會掛載 root 文件系統爲其提供用戶空間支持。而 Docker 鏡像（Image），就至關因而一個 root 文件系統。

Docker 鏡像是一個特殊的文件系統，除了提供容器運行時所需的程序、庫、資源、配置等文件外，還包含了一些爲運行時準備的一些配置參數（如匿名卷、環境變量、用戶等）。

鏡像不包含任何動態數據，其內容在構建以後也不會被改變。

Docker 設計時，就充分利用 Union FS 的技術，將其設計爲分層存儲的架構。 鏡像實際是由多層文件系統聯合組成。

鏡像構建時，會一層層構建，前一層是後一層的基礎。每一層構建完就不會再發生改變，後一層上的任何改變只發生在本身這一層。

好比，刪除前一層文件的操做，實際不是真的刪除前一層的文件，而是僅在當前層標記爲該文件已刪除。

在最終容器運行的時候，雖然不會看到這個文件，可是實際上該文件會一直跟隨鏡像。

所以，在構建鏡像的時候，須要額外當心，每一層儘可能只包含該層須要添加的東西，任何額外的東西應該在該層構建結束前清理掉。

分層存儲的特徵還使得鏡像的複用、定製變的更爲容易。甚至能夠用以前構建好的鏡像做爲基礎層，而後進一步添加新的層，以定製本身所需的內容，構建新的鏡像。

 

容器：鏡像運行時的實體

鏡像（Image）和容器（Container）的關係，就像是面向對象程序設計中的類和實例同樣，鏡像是靜態的定義，容器是鏡像運行時的實體。容器能夠被建立、啓動、中止、刪除、暫停等 。

容器的實質是進程，但與直接在宿主執行的進程不一樣，容器進程運行於屬於本身的獨立的命名空間。前面講過鏡像使用的是分層存儲，容器也是如此。

容器存儲層的生存週期和容器同樣，容器消亡時，容器存儲層也隨之消亡。所以，任何保存於容器存儲層的信息都會隨容器刪除而丟失。

按照 Docker 最佳實踐的要求，容器不該該向其存儲層內寫入任何數據 ，容器存儲層要保持無狀態化。

全部的文件寫入操做，都應該使用數據卷（Volume）、或者綁定宿主目錄，在這些位置的讀寫會跳過容器存儲層，直接對宿主（或網絡存儲）發生讀寫，其性能和穩定性更高。

數據卷的生存週期獨立於容器，容器消亡，數據卷不會消亡。所以， 使用數據卷後，容器能夠隨意刪除、從新 run，數據卻不會丟失。

 

注意：

容器在整個應用程序生命週期工做流中提供如下優勢：隔離性、可移植性、靈活性、可伸縮性和可控性。 最重要的優勢是可在開發和運營之間提供隔離。

 

倉庫：集中存放鏡像文件的地方

鏡像構建完成後，能夠很容易的在當前宿主上運行，可是， 若是須要在其餘服務器上使用這個鏡像，咱們就須要一個集中的存儲、分發鏡像的服務，Docker Registry 就是這樣的服務。

一個 Docker Registry 中能夠包含多個倉庫（Repository）；每一個倉庫能夠包含多個標籤（Tag）；每一個標籤對應一個鏡像。

因此說，鏡像倉庫是 Docker 用來集中存放鏡像文件的地方，相似於咱們以前經常使用的代碼倉庫。

一般，一個倉庫會包含同一個軟件不一樣版本的鏡像，而標籤就經常使用於對應該軟件的各個版本 。

咱們能夠經過<倉庫名>:<標籤>的格式來指定具體是這個軟件哪一個版本的鏡像。若是不給出標籤，將以 latest 做爲默認標籤。

這裏補充一下 Docker Registry 公開服務和私有 Docker Registry 的概念：

Docker Registry 公開服務是開放給用戶使用、容許用戶管理鏡像的 Registry 服務。

通常這類公開服務容許用戶免費上傳、下載公開的鏡像，並可能提供收費服務供用戶管理私有鏡像。

最常使用的 Registry 公開服務是官方的 Docker Hub ，這也是默認的 Registry，並擁有大量的高質量的官方鏡像，網址爲：hub.docker.com/ 。

在國內訪問 Docker Hub 可能會比較慢，國內也有一些雲服務商提供相似於 Docker Hub 的公開服務。

除了使用公開服務外，用戶還能夠在本地搭建私有 Docker Registry 。Docker 官方提供了 Docker Registry 鏡像，能夠直接使用作爲私有 Registry 服務。

 

開源的 Docker Registry 鏡像只提供了 Docker Registry API 的服務端實現，足以支持 Docker 命令，不影響使用。但不包含圖形界面，以及鏡像維護、用戶管理、訪問控制等高級功能。

 

Docker的主要應用場景

簡化配置

虛擬機的最大好處是能在你的硬件設施上運行各類配置不同的平臺（軟件、系統），Docker在下降額外開銷的狀況下提供了一樣的功能。它能讓你將運行環境和配置放在代碼中而後部署，同一個Docker的配置能夠在不一樣的環境中使用，這樣就下降了硬件要求和應用環境之間耦合度。

 

簡單的來講，容器鏡像打包完成後，它就是個獨立的個體了，丟到哪裏都能跑，而無需針對各個平臺去獨立配置。

 

代碼流水線（Code Pipeline）管理

前一個場景對於管理代碼的流水線起到了很大的幫助。代碼從開發者的機器到最終在生產環境上的部署，須要通過不少的中間環境。而每個中間環境都有本身微小的差異，Docker給應用提供了一個從開發到上線均一致的環境，讓代碼的流水線變得簡單很多。

 

提升開發效率

不一樣的開發環境中，咱們都想把兩件事作好。一是咱們想讓開發環境儘可能貼近生產環境，二是咱們想快速搭建開發環境。

 

使用Docker很是簡單的就可以實現這兩點，並且哪怕是開發環境的機器配置通常的狀況下搭建多個生成服務應用。一臺通常配置服務器或開發機也能輕鬆的跑起多個Docker應用，而無需額外增長機器配置。由於Docker有個很是NB的特性，擁有虛擬化的特性，而幾乎沒有額外的開銷。

 

隔離應用

不少狀況下，咱們須要在一臺服務器上運行多個不一樣的應用，好比上面提到的提升開發效率的場景等。

 

咱們常常須要考慮三點，一是由於要下降成本而進行服務器整合，二是將一個總體式的應用拆分紅松耦合的單個服務（好比微服務架構），三是還須要考慮應用之間的兼容性。而對於Docker來講，支持起來就很是簡單了。同一臺機器，我能夠同時運行N個Docker web應用，託管到不一樣的Web服務器（Kestrel、Ngnix、Tomcat），而無需擔憂他們會搞起3Q大戰，也無需擔憂個人開發機器會跑不起來。

 

整合服務器

 

正如經過虛擬機來整合多個應用，Docker隔離應用的能力使得Docker能夠整合多個服務器以下降成本。因爲沒有多個操做系統的內存佔用，以及能在多個實例之間共享沒有使用的內存，Docker能夠比虛擬機提供更好的服務器整合解決方案。

 

這就意味着資源獲得更有效的利用——能夠作更多衣服，並且尚未邊角料，成本還更低。

 

調試能力

Docker提供了不少的工具，這些工具不必定只是針對容器，可是卻適用於容器。它們提供了不少的功能，包括能夠爲容器設置檢查點、設置版本和查看兩個容器之間的差異，這些特性能夠幫助調試Bug。

 

多租戶環境

在多租戶的應用中，它能夠避免關鍵應用的重寫。好比IoT（物聯網）的應用中，開發一個快速、易用的多租戶環境。這種多租戶的基本代碼很是複雜，很難處理，從新規劃這樣一個應用不但消耗時間，也浪費金錢。

 

使用Docker，能夠爲每個租戶的應用層的多個實例建立隔離的環境，這不只簡單並且成本低廉，固然這一切得益於Docker環境的啓動速度和其高效的diff命令。

 

就如同咱們如今寫了一個不支持多租戶的業務程序，而實際的業務中常常會出現須要支持多租戶或者有新客戶須要使用的場景，這是咱們一般的簡單作法是——部署一套新的代碼。當站點達到必定量的適合，要麼重寫程序，要麼維護人員Game over。

 

快速部署

在虛擬機以前，引入新的硬件資源須要消耗幾天的時間。虛擬化技術（Virtualization）將這個時間縮短到了分鐘級別。而Docker經過爲進程僅僅建立一個容器而無需啓動一個操做系統，再次將這個過程縮短到了秒級。

 

你能夠在服務器中或雲端建立銷燬資源而無需擔憂從新啓動帶來的開銷。一般狀況下，服務器的資源利用率只有30%，而經過使用Docker並進行有效的資源分配能夠提升資源的利用率。

 

 

市場實際反饋和調查

咱們來看一份2016年用戶調查結果。

Docker爲軟件供應鏈提供了應用程序開發的敏捷性，可控性和可移值性

 

－ 用戶如何使用 Docker？

• 90% 的用戶使用 Docker 進行應用開發

• 65% 的用戶使用 Docker 進行敏捷開發

• 58% 的用戶將 Docker 用於生產

• 48% 的用戶使用 Docker 控制應用環境

• 41% 的用戶使用 Docker 實現應用的可移植性 

 － Docker 的業務覆蓋：

• 78%：網頁應用

• 75%：網頁 API

• 70%：應用服務端

• 42％：傳統數據庫

• 27%：分佈式數據庫

• 13%：大數據

Docker 帶來的敏捷性（響應速度和靈活性）吸引了愈來愈多的開發者。他們不只能知道容器內部到底跑了什麼，也能進一步理解 Docker 如何加速了軟件開發進程。另外，41% 的用戶表示應用的可移植性是他們決定使用 Docker 的關鍵因素。

 

經過 DevOps 的實踐，Docker 正在給應用交付帶來不少能夠量化的提高

如圖所示：

• 93% 的 Docker 用戶已經在開發過程當中得到了益處

• 85% 的 Docker 用戶已經在運維過程當中得到了益處

• 57% 的 Docker 用戶見證了運維環境管理的提高

• 45% 的 Docker 用戶已經提升了軟件發佈的頻率

大約一半的受訪者表示已經採用了持續集成（CI）和 DevOps，而且但願把這些實戰經驗應用到生產環境的持續交付中。剩下的受訪者則準備儘快跟上步伐，儘快嘗試 DevOps 和持續集成。另外，據調查顯示，用戶使用 Docker 發佈應用的頻率平均提高了 13 倍。

 

Docker 對混合雲策略相當重要，它使得用戶能夠根據需求自由選擇私有和公有環境

 

如圖所示：

• 80％ 的用戶表示 Docker 已是雲策略的一部分

• 60% 的用戶則正在計劃使用 Docker 將業務遷移到雲端。

• 41% 的用戶但願實現跨環境的應用移植

• 35+% 的用戶但願避免被雲供應商綁定

經過容器來交付的應用能夠在任何基礎設施之上靈活遷移，同時這些基礎設施又能夠提供不一樣層次的應用管理方式，而當業務在多個服務供應商之中尋求混合雲或全雲模式時，又能夠完美避免被平臺捆綁。

 

對於按需部署或部署到雲環境，Docker 提供了獨一無二的選擇。 80% 的用戶表示 Docker 已經成爲他們雲策略的一部分，超過 35% 的用戶使用 Docker 來避免被雲服務供應商綁定。

 

Docker 實現了微服務架構，也讓遺留的單體應用轉變爲現代應用

 

如圖所示：

• 65% 的組織面對遺留應用這一難題

• 59% 的組織受到遺留應用和基礎設施僵化的影響

• 44% 的組織正在使用微服務架構

• 39% 的組織讓遺留應用煥發新生

Docker 使得微服務架構的快速發展成爲可能，同時它也將傳統的業務遷移到容器環境中，以此使得應用程序變得更加可移植。使用微服務架構進行交付是 Docker 的關鍵優點！

 

Docker改變了什麼？

綜上所述，Docker到底改變了什麼？筆者是這麼理解的：

• Docker改變了雲服務，使雲服務的共融共通的理想逐步成爲了可能。而且Docker 已是雲策略的一部分，許多開發者正在計劃使用 Docker 將業務遷移到雲端。另外，爲了不被雲服務供應商綁定，Docker成爲不少開發者的首選。

• Docker改變了產品交付，爲產品的整個生命週期提供了一整套的解決方案和流程。

• Docker改變了開發方式，提供了簡化的環境配置、封裝的運行環境以及統一的環境。而且提供了快速部署的方式。

• Docker改變了測試，多版本測試變得極爲方便，快速構建測試環境也變得更加簡單而且無需開發人員干預或者搭建。

• Docker改變了運維，環境的一致性讓運維變得更加簡單，同時熱更新的支持讓運維再也不須要半夜加班部署更新，更新能夠隨時進行。當出現重大問題時，還能快速回滾到指定版本。

• Docker改變了架構，自動化擴容支持讓架構變得更加簡單，分佈式系統也更加易於搭建和支持。同時遺留的單體應用也很易於轉變爲現代應用。

總之，在某種程度上，Docker改變了產品開發中的一些遊戲規則。雖然Docker是一項技術，可是它也帶來了新的思惟，新的流程和工做方法，Docker在推進行業的發展，Docker已經在改變世界，而且在逐步的變爲事實……

 

 

 做者：雪雁
出處：http://www.cnblogs.com/codelove/ 
溝通渠道：編程交流羣<85318032> 產品交流羣<897857351> 
若是喜歡做者的文章，請關注「magiccodes」訂閱號以便第一時間得到最新內容。本文版權歸做者和湖南心萊信息科技有限公司共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，不然保留追究法律責任的權利。
靜聽鳥語花香，漫賞雲捲雲舒。