向您推薦
Dcoker入門與實踐系列文章
前言
本文的理論，僅僅是作者在實驗之後的一家之言，也許隻是管中窺豹。希望大家抱着保留的态度，來看這篇文章！
此文寫于2016年6月12日,一切都在快速變化，歡迎指正！
Docker生态系統
Docker簡介
Docker是什麼？
Docker是以docker容器為資源分割和排程的基本機關,封裝軟體的運作時環境.用于快速建構,釋出,運作分布式應用的平台。Docker的運作時容器的本質是程序.在linux中，通過namespace進行資源隔離,cgroups進行資源限制，使docker容器看上去像是一個運作在主控端中的虛拟機.
docker引擎的簡介
- 我們通常說的Docker是指Docker Engine
- Docker容器與虛拟機的根本差別在于，docker容器和主控端共用linux作業系統核心，不會在主控端上再次建立OS,輕量級.
- 容器采用分層的機制。如：最底層可能是一個linux發行版，如ubuntu.上面加上JDK層.JDK層之上可以安裝tomcat等各種java應用層
- 我們通常所說的docker是指docker引擎.本文主要介紹docker引擎周邊的生态系統，關于docker引擎的詳細介紹可以參考《docker-軟體工程中的集裝箱技術》.
筆者認為Docker四大特性
- Docker容器的秒級啟動
- Docker容器實作了應用環境的标準化
- Docker與mesos.k8s的結合，提供了雲服務能力.
- Docker的高資源使用率(與虛拟機相比)
以上的這些特性,使企業級的微服務架構的實作，提供了真實的具有實踐性的可能.
Docker及其生态系統為軟體行業帶來了什麼變化？
- 持續部署與內建.Docker封裝了軟體的運作時環境,消除了線上與線下的差異,保障了應用在開發,測試,生産運作整個生命周期的一緻性.結合jenkins等持續內建軟體使用,實作了code(代碼)到image(鏡像)的快速內建，大大的簡化了持續內建,測試,軟體釋出的過程.
- 環境标準化與版本控制.我們經常使用git,svn,cvs等版本控制工具實作代碼級别的版本控制.那有沒有想過有一天，可以實作對應用運作時環境進行版本控制呢？docker幫我們實作了,應用myapp的1.0版本使用JDK6(myapp-docker-1.0)，應用的2.0版本使用JDK8(myapp-docker-2.0).全部封裝到docker鏡像裡面.上線過程中，2.0版本出現問題怎麼辦,快速回退1.0版本.因為回退過程，不需要1.0應用環境的重新配置,隻是1.0應用版本的容器啟動，秒級實作.筆者做個展望：docker鏡像将成為未來軟體傳遞的唯一标準！
- 應用服務能力的伸縮性.舉個假設的例子，淘寶對于應用服務的能力要求，"雙11"期間肯定遠遠高于日常.docker結合k8s，mesos之類的資源管理及服務編排系統，結合負載均衡服務,可以實作應用規模的快速擴縮."雙11"啟動5000個容器，日常啟動2000個容器來滿足業務的需求.
- 資源的使用率提高上面的淘寶的例子,就避免了伺服器資源的浪費，在閑時将伺服器資源釋放出來.筆者在一台8G,8核心的PC機上,啟動了20個ubuntu容器(還可以更多)，你可以在這樣的一台PC上啟動20個虛拟機麼？答案顯然是否定的.
Docker鏡像庫
DockerHub
Docker 官方維護了一個公共倉庫 Docker Hub，其中已經包括了超過 15,000 的鏡像。大部分需求，都可以通過在 Docker Hub 中直接下載下傳鏡像來實作。
Docker registry 私有倉庫
Registry 作為 Docker 的核心元件之一負責鏡像内容的存儲與分發,是企業搭建私有docker鏡像倉庫的解決方案.
Docker Registry目前分為V1和V2兩個版本.V2版本相比V1版本有如下幾方面的改進：
- V1版本push layer操作隻判斷id，不判斷layer的内容.由于鏡像内容與id無關，是以重新build之後id變化，内容沒變的layer将會重複送出.造成存儲資源的浪費.V2采用哈希值方式,被稱為 digest 是一個和鏡像内容相關的字元串，相同的内容會生成相同的 digest。是以是鏡像layer判斷是内容相關的.
- 提供了鑒權管理和權限控制
-
V1 registry 中鏡像的每個layer 都包含一個json檔案包含了父親 layer 的資訊.是以當我們 pull 鏡像時需要串行下載下傳，下載下傳完一個 layer 後才知道下一個 layer 的 id 是多少再去下載下傳.
新版 registry 在 image 的 manifest 中包含了所有 layer 的資訊，用戶端可以并行下載下傳所有的 layer
推薦您看：《Docker registry V2私有倉庫搭建》
服務發現機制和全局配置存儲
為什麼需要服務發現？
當我們部署少量docker容器的時候，我們可以去指定容器的映射端口.但是我們啟動大規模的容器叢集的時候，我們希望容器的對外服務端口是随機配置設定的，并且同一台主機内不能發生端口沖突（服務編排及資源管理的系統可以幫我們完成端口的随機配置設定，這個不是這裡要說的事情）.
端口随機的配置設定實作了，那麼使用者該如何才能知道，這個随機的端口是什麼？哪個ip,哪個端口對應哪個服務?這就需要服務發現元件來實作！
基于上述的需求，服務發現的元件應該具備如下基本功能
- 提供全局的分布式容器資訊存儲，即鍵值對的存儲工作。
- 提供http的API來get or set值.即：提供注冊和查詢
常用的服務發現工具
- consul: 服務發現/全局的分布式key-value存儲。自帶DNS查詢服務,可以跨資料中心。提供節點的健康檢查,可以實作動态的consul節點增減.docker官方的用例推薦！
- etcd: 服務發現/全局的分布式key-value存儲.靜态的服務發現，如果實作動态的新增etcd節點，需要依賴第三方元件。
- zookeeper: 服務發現/全局的分布式key-value存儲.使用場景廣泛，java編寫，資源需求大，比起前兩者更加臃腫！
Docker 網絡
Docker 1.9釋出之前，網絡的問題一直是困擾docker愛好者的主要問題.實作的複雜度較高，這一切都在釋出docker1.9的overlay網絡之後得到改善.
docker 1.9之前提供了兩種容器之間的網絡連接配接方式
- 通過docker容器映射端口到主控端,即暴露端口到主控端.舉例：容器A映射8080到主控端xx.xx.xx.xx的80端口,其他的容器想通路容器A的端口,就通路xx.xx.xx.xx:80。
- 通過link的方式，連接配接容器網絡.這種方式隻适合，單個主控端之内，無法跨主控端實作容器之間的互訪！
砸一看，似乎有這兩種方式就夠了.雖然采用第二種無法跨主機，但是第一種還算ok吧？如果一個服務暴露出來很多的端口怎麼辦？都對外映射麼？那樣就會造成端口管理上的災難！
這顯然是不行的，這時很多的工具出現了，來做SDN(軟體定義網絡)網絡.容器之間的互訪網絡.比較有名氣的有：
- fannel–overlay
- weave–overlay
- pipework
但是，docker1.9釋出之後，這些Docker網絡工具的存在意義逐漸弱化（雖然這些軟體還是有一些自己的特點）。docker官方實作了自己的跨主機容器網絡方案。
實作方式,請看我的另外兩篇
《基于consul的Docker-overlay跨多主控端容器網絡》
《基于etcd的Docker-overlay跨多主控端容器網絡》
容器管理與編排
容器編排和管理系統主要解決以下幾個問題：
- 如何監控叢集資源？如何配置設定叢集資源？
- 如何監控容器運作狀态？如何進行應用健康狀态檢查？
- 提供同一服務的容器資源縮放？
- 我們需要工具來實作大規模容器分業務分組分服務管理.
- 我們需要指定容器去哪些主機上啟動部署
- 容器依賴按照什麼順序啟動？
- 自動化的實時擴充或減少分組容器的數量
- 根據叢集和節點的資源使用率排程容器的啟動位置
- 分組容器對外服務的負載均衡
- 産品應用支援，如大資料的docker化
- ……
目前容器編排與管理的系統主要是三個：
-
mesos + marathon,mesos的本質是一個基于資源的排程管理系統，可以實作docker容器的基于資源的細粒度的容器排程.marathon用來運作長服務，實作健康檢查與容器依賴啟動，擴充與縮放.在大型的容器叢集管理上，有更穩定的表現.
推薦一篇介紹mesos的文章:《煮餃子與mesos之間妙不可言的關系》
- kubernets是谷歌開發的容器編排管理系統.使用Golang開發，具有輕量化、子產品化、便攜以及可擴充的特點。它提出了一系列諸如：Pods,Replication Controllers,Labels,Services之類的概念，是以學習的曲線也相對陡峭.Kubernetes的性能要比Swarm差，是因為它擁有更加複雜的架構;性能比Mesos差，是因為它結構層次更深;
- docker + swarm + compose,docker原生的容器管理系統，簡單易用，學習的曲線低，和docker相容度高，但是實際用于生産環境的案例不多。
參考
- https://www.digitalocean.com/community/tutorials/the-docker-ecosystem-an-introduction-to-common-components