前兩篇東西，我們分別介紹了Mesos和Dockers的安裝和使用。在《Mesos實戰》這篇的結尾，我說過將會介紹如何在Mesos集群之上跑幾個任務。這趟就著重說說如何在Mesos中通過Docker跑幾個Container。
說到Docker的Container，個人理解其實就是將軟件和系統環境一并打包發布的機制，這樣做的原因是通過一個統一的封裝，加快開發，測試，運維的流程，減少了重復配置環境的過程。如果說對于實驗室環境來說，Docker的命令行界面其實已經很方便了，但如果作為生產環境中部署docker來說有幾個明顯的軟肋：
缺乏故障監控，資源調度，故障自動轉移的平臺。
沒有一個相對友好的用戶界面和相對完整的API。
網絡管理不完善。
而這些缺點就是我們將docker遷入Mesos集群中的原因所在。
安裝Mesos
這一部分的內容，包括環境介紹請參見《Mesos實戰》，這里不再贅述。
不過要說明一下，之后的zk和marathon的安裝從道理上應該是在獨立的一套主機上，但我這里考慮到僅僅只是實驗環境，而且mesos的master節點非常空閑，于是便把之后的安裝集中在了master，下文中除了特指的主機之外，全部在master節點上操作。
安裝 Zookeeper
上文中對于Mesos的管理，其實我們并沒有用到zoopkeeper，不過這次要補上Zookeeper的安裝了。
真心不復雜，屬于下載來就能用的那種。唯一的依賴包是JAVA環境，不過如果你的Mesos裝好了，自然也有了JAVA環境。
$ tar vzxf zookeeper-xxx.tar.gz$ mv zookeeper-xxx /usr/local/zookeeper$ cd /usr/local/zookeeper$ bin/zkServer.sh
正常情況下應該不會有報錯，系統會監聽2181端口。
安裝 Marathon
Marathon即馬拉松，從字面上就看得出，這是一個保持系統長時間運行的服務。安裝也不是很復雜。
$ wget http://downloads.mesosphere.com/marathon/v0.10.0/marathon-0.10.0.tgz$ tar vzxf marathon-0.10.0.tgz$ mv marathon-0.10.0 /usr/local/marathon
這里有個地方要修改一下要把兩句Memeos的lib位置寫到/usr/local/marathon/bin/start 啟動腳本的頭部（Line2~Line5之間即可）：
export MESOS_NATIVE_JAVA_LIBRARY=/usr/local/mesos/lib/libmesos.soexport MESOS_NATIVE_LIBRARY=/usr/local/mesos/lib/libmesos.so
啟動Marathon(10.239.21.100是Mesos-master的IP)
$ cd /usr/local/marathon$ bin/start --master 10.239.21.100:5050 --zk zk://10.239.21.100:2181/marathon
訪問一下8080端口，查看Marathon主界面（圖片是后抓的，已經有了任務，請無視）
執行Shell腳本
點擊首頁那個碩大的綠色按鈕彈出層中
ID，要求全小寫，小寫字母開頭，允許數字和“-”。好吧，要求不少。
command，寫入一段shell命令，要求在所有的slave上都可以執行才可以。
這個時候訪問Mesos的的控制臺http://10.239.21.100:5050應該可以看到有一個任務出現，說明Marathon已經work。
PS：如果你發現在Mesos的頭部出現如下圖所示的警示框，說明你的主機不能通過主機名的方式訪問Mesos集群中的節點。所以，我的建議是對于Mesos和你的工作機都要在hosts中加入對應的主機。
配置Slave支持Docker
本質上講，一個task在marathon端被發布出來，扔給Mesos master，master根據自己的調度扔給其中的一個slave去執行。這就是我剛才說的“命令要求所有的Slave都能執行”的原因。所以理所當然的要求所有的slave上都要支持docker。
到每個slave上執行
$ apt-get update$ apt-get install docker.io
還記得我之前在mesos-slave-env.sh配置中的那個伏筆嗎？
export MESOS_containerizers=docker,mesos
這個配置決定了Mesos可以直接支持Docker。如果沒有啟用這個配置的話需要在每個Slave上修改這個配置，并在master上通過兩條命令重啟。
$ /usr/local/mesos/sbin/mesos-start-cluster.sh$ /usr/local/mesos/sbin/mesos-start-cluster.sh
這里有個題外話就是mesos的一個有意思的特性：如果你有一個環境變量叫做MESOS_cluster的話，在啟動服務且不被覆蓋的話這個值等價于–cluster的入參。所有的參數都可以通過這種方式輸入。修改的mesos-slave-env.sh和mesos-master-env.sh兩個文件其實是用來啟用環境變量的。
在docker中啟用Container
Marathon作為一個還沒有到1.0版本的項目來說，啟動一個container還是最好用API來實現吧。要把一個Json post到http://10.239.21.100:5050/v2/apps 。我習慣上用Chrome的postman插件實現。
以下是我啟動一個nginx的例子：
請注意，這是一個標準的RESTful API，一定要加上”Content-type: application/json”的Http header！
幾個重要的filed解釋：
id：其實是task name，字母開頭，支持字母數字和‘-’。
docke.image：docker的鏡像，默認會從dockerhub上去下載。
portMappings：對應的是一個container到主機port的mapping。但和傳統的docker -p參數不太一樣——只能制定開放哪幾個端口的對外訪問，但不能指定映射到local的什么端口。不過好在從API文檔上來看，這只是現階段沒有完成而已，相信之后會完善的。
回到marathon主界面，如果看到對應的task已經啟動，點擊task名稱，進入task描述。
你會看到下面的那個灰色的 mesos-slaver-01 : 31345，點擊它就會看到mapping之后的nginx首頁。
Swarm項目是Docker公司發布三劍客中的一員，用來提供容器集群服務，目的是更好的幫助用戶管理多個Docker Engine，方便用戶使用，像使用Docker Engine一樣使用容器集群服務。這次分享內容從Swarm項目現狀、Swarm社區現狀和Swarm未來的一些規劃三方面介紹Swarm，目的是能讓大家對Swarm有個完整的認識，并且希望更多的人采用到Swarm項目中來。Swarm背景
現實中我們的應用可能會有很多，應用本身也可能很復雜，單個Docker Engine所能提供的資源未必能夠滿足要求。而且應用本身也會有可靠性的要求，希望避免單點故障，這樣的話勢必需要分布在多個Docker Engine。在這樣一個大背景下，Docker社區就產生了Swarm項目。Swarm是什么
Swarm這個項目名稱特別貼切。在Wiki的解釋中，Swarm behavior是指動物的群集行為。比如我們常見的蜂群，魚群，秋天往南飛的雁群都可以稱作Swarm behavior。
Swarm項目正是這樣，通過把多個Docker Engine聚集在一起，形成一個大的docker-engine，對外提供容器的集群服務。同時這個集群對外提供Swarm API，用戶可以像使用Docker Engine一樣使用Docker集群。Swarm 特點
對外以Docker API接口呈現，這樣帶來的好處是，如果現有系統使用Docker Engine，則可以平滑將Docker Engine切到Swarm上，無需改動現有系統。
Swarm對用戶來說，之前使用Docker的經驗可以繼承過來。非常容易上手，學習成本和二次開發成本都比較低。同時Swarm本身專注于Docker集群管理，非常輕量，占用資源也非常少。 *“Batteries included but swappable”，簡單說，就是插件化機制，Swarm中的各個模塊都抽象出了API，可以根據自己一些特點進行定制實現。
Swarm自身對Docker命令參數支持的比較完善，Swarm目前與Docker是同步發布的。Docker的新功能，都會第一時間在Swarm中體現。
Swarm對外提供兩種API， 一種是Docker API，用于負責容器鏡像的生命周期管理， 另外一種是Swarm集群管理CLI，用于集群管理。
Scheduler模塊，主要實現調度功能。在通過Swarm創建容器時，會經過Scheduler模塊選擇出一個最優節點，里面包含了兩個子模塊，分別是Filter和Strategy， Filter用來過濾節點，找出滿足條件的節點（比如資源足夠，節點正常等等），Strategy用來在過濾出的節點中根據策略選擇一個最優的節點（比如對找出的節點進行對比，找到資源最多的節點等等）, 當然Filter/Strategy用戶可以定制。
Swarm對集群進行了抽象，抽象出了Cluster API，Swarm支持兩種集群，一種是Swarm自身的集群，另外一種基于Mesos的集群。
LeaderShip模塊用于Swarm Manager自身的HA，通過主備方式實現。
Discovery Service 服務發現模塊，這個模塊主要用來提供節點發現功能。
在每一個節點上，都會有一個Agent，用于連接Discovery Service，上報Docker Daemon的IP端口信息，Swarm Manager會直接從服務發現模塊中讀取節點信息。
Swarm各個模塊介紹
集群管理
Swarm Manager CLI用于集群管理。大家可以看這張圖，通過三步就可以將集群創建起來。
Swarm容器集群創建完成后，就可以采用Docker命令，像使用Docker Engine一樣使用Swarm集群創建容器了。 服務發現
服務發現，在Swarm中主要用于節點發現，每一個節點上的Agent會將docker-egine的IP端口注冊到服務發現系統中。Manager會從服務發現模塊中讀取節點信息。Swarm中服務發現支持已下3種類型的后端：第一種，是hosted discovery service，是Docker Hub提供的服務發現服務，需要連接外網訪問。 第二種，是KV分布式存儲系統，現在已支持etcd、ZooKeeper、Consul三種。 第三種，是靜態IP。可以使用本地文件或者直接指定節點IP，這種方式不需要啟動額外使用其他組件,一般在調試中會使用到。 Scheduler
調度模塊主要用戶容器創建時，選擇一個最優節點。在選擇最優節點過程中，分為了兩個階段： 第一個階段，是過濾。根據條件過濾出符合要求的節點，過濾器有以下5種：Constraints，約束過濾器，可以根據當前操作系統類型、內核版本、存儲類型等條件進行過濾，當然也可以自定義約束，在啟動Daemon的時候，通過Label來指定當前主機所具有的特點。
Affnity，親和性過濾器，支持容器親和性和鏡像親和性，比如一個web應用，我想將DB容器和Web容器放在一起，就可以通過這個過濾器來實現。
Dependency，依賴過濾器。如果在創建容器的時候使用了--volume-from/--link/--net某個容器，則創建的容器會和依賴的容器在同一個節點上。
Health filter，會根據節點狀態進行過濾，會去除故障節點。
Ports filter，會根據端口的使用情況過濾。
調度的第二個階段是根據策略選擇一個最優節點。有以下三種策略：Binpack，在同等條件下，選擇資源使用最多的節點，通過這一個策略，可以將容器聚集起來。
Spread，在同等條件下，選擇資源使用最少的節點，通過這一個策略，可以將容器均勻分布在每一個節點上。
Random，隨機選擇一個節點。
Leadership
Leadership模塊，這個模塊主要用來提供Swarm Manager自身的HA。
為了防止Swarm Manager單點故障，引入了HA機制，Swarm Manager自身是無狀態的，所以還是很容易實現HA的。 實現過程中采用主備方式，當主節點故障以后，會從新選主提供服務，選主過程中采用分布式鎖實現，現在支持etcd、ZooKeeper、Consul三種類型的分布式存儲，用來提供分布式鎖。 當備節點收到消息后，會將消息轉發給主節點。 以上就是框架中各個模塊的相關介紹，下來和大家一起再看一下，Swarm與周邊項目的集成。首先看一下，與三劍客之間的集成。Swarm與周邊項目集成
三劍客是Docker公司去年底發布的三個項目，這三者是可以緊密協作的。可以看一下這張圖：
最下面是Machine，通過Machine可以在不同云平臺上創建出包含docker-engine的主機。Machine通過driver機制，目前支持多個平臺的docker-egine環境的部署，比如亞馬遜、OpenStack等。 Docker Engine創建完以后，就該Swarm上場了，Swarm將每一個主機上的docker-egnine管理起來，對外提供容器集群服務。最上面是Compose項目，Compose項目主要用來提供基于容器的應用的編排。用戶通過yml文件描述由多個容器組成的應用，然后由Compose解析yml，調用Docker API，在Swarm集群上創建出對應的容器。 我們知道現在圍繞Docker已經產生了很大的一個生態圈。 因此Swarm不僅在和自家兄弟集成，也能積極和周邊的一些項目集成。比如，Swarm現在已經可以和Mesos進行集成。Swarm與Mesos集成時，也是以Framework方式集成，實現了Framework所需的接口。這個大特性處在experiment階段。Swarm社區的現狀
Swarm項目去年底發布，發展了短短半年時間，已經到了0.4版本，目前還處于正在快速演進階段。 Swarm發布版本周期目前是跟著Docker一起發布，基本上兩個月一個版本，在開發過程中，采用迭代方式開發，基本上每兩個星期完成一輪迭代。參與社區的方法基本上和其他社區一致。當遇到問題時，可以在社區創建issue，然后描述問題，最好能上環境信息以及問題重現的步驟，這樣有利于問題的定位。當然也可也直接通過IRC或者郵件直接交流。 Swarm社區很歡迎大家的參與，不論是使用中遇到的問題以及Bug，還是Swarm功能上目前無法滿足大家的地方。都歡迎大家提出來，一起討論。如果對代碼感興趣的話，可以參考Docker社區的提交代碼流程來提交代碼，也非常歡迎大家能夠參與到Swarm社區中提交代碼。Swarm未來規劃
首先是支持所有的Docker API，現在支持率大概在95%，其中一些實現還存在問題，需要改進。
第二塊是網絡部分，通過Libnetwork項目，實現overlay network。
第三塊是Self healing，通過這一個功能可以實現，當一個節點故障以后，會將故障節點上的容器在另外一些節點上創建。
第四塊是Global Scheduler。這個特性主要用來將一個容器在每一個節點上進行創建。比如，想將一個log容器在每一個節點創建，用來記錄日志，則可以通過這一特性實現。
最后是volume，這一塊社區最近在討論。
