摘要：利用分布式應(yīng)用捆綁包簡稱部署服務(wù)相較于利用大量參數(shù)創(chuàng)建網(wǎng)絡(luò)及服務(wù)，這里我們選擇使用一個文件。

在Docker 1.12版本中，全新的Swarm捆綁包相較于原有編排及調(diào)度機制做出了巨大改進(jìn)。它不再需要運行一組獨立的Swarm容器，這部分容器已經(jīng)被直接捆綁在Docker Engine當(dāng)中，故障轉(zhuǎn)移策略更為可靠，服務(wù)發(fā)現(xiàn)機制實現(xiàn)內(nèi)置，新的網(wǎng)絡(luò)功能極為順暢……看起來很棒是不是？    數(shù)人云這就帶大家一起去探索一二。

在之前的文章中，我們已經(jīng)介紹了如何利用命令在Swarm集群當(dāng)中運行Docker服務(wù)。相信Docker Compose所實現(xiàn)的簡化效果會令大家印象深刻。相較于強行記憶命令后的全部參考以實現(xiàn)服務(wù)運行，現(xiàn)在大家只需要將一切設(shè)置指定為Docker Compose文件，而后利用簡單的docker-compose up –d命令運行容器即可。毫無疑問，這樣的處理方式比在docker service create命令之后添加一大堆參數(shù)要簡單得多。

而在上手新的Swarm時，我個人的第一印象是“太棒了”，接下來則是“我不想硬背與服務(wù)相關(guān)的一大堆參數(shù)”。Compose文件的回歸簡直令人熱淚盈眶。

新版本的一大顯著變化在于，容器管理已經(jīng)由客戶端（Docker Compose）轉(zhuǎn)移至服務(wù)器端（Docker Serivce）。如此一來，Docker Compose就顯得有些過時了（至少在使用由Docker Serivce部署的容器時是如此）。當(dāng)然，大家還是可以在單一服務(wù)器環(huán)境下利用Docker Compose運行容器，但其作用恐怕也就僅限于此了。因此，我們到底要如何處理已經(jīng)創(chuàng)建完成的這一大堆docker-compose.yml文件？

好消息是，我們可以分布式應(yīng)用捆綁包或者簡稱dab文件替代docker service命令行中的參數(shù)。壞消息是……咱們還是先探索好的這部分內(nèi)容吧。

我們這里首先構(gòu)建一套由Docker設(shè)備構(gòu)成的演示Swarm集群。

在本示例中，我們假定大家已經(jīng)擁有包含有Docker Engine v1.12+的Docker Machine v0.8+版本。最簡單的獲取方式就是使用Docker Toolbox。

如果大家身為Windows用戶，則可利用Git Bash（同樣通過Docker Toolbox進(jìn)行安裝）運行全部示例。

這里將不再贅述環(huán)境的設(shè)置步驟。我們將創(chuàng)建三個節(jié)點，并利用其構(gòu)建起一套Swarm集群。

docker-machine create -d virtualbox node-1
 docker-machine create -d virtualbox node-2
 docker-machine create -d virtualbox node-3
 eval $(docker-machine env node-1)
 docker swarm init 
    --advertise-addr $(docker-machine ip node-1) 
    --listen-addr $(docker-machine ip node-1):2377
 TOKEN=$(docker swarm join-token -q worker)
 eval $(docker-machine env node-2)
 docker swarm join --token $TOKEN $(docker-machine ip node-1):2377
 eval $(docker-machine env node-3)
 docker swarm join --token $TOKEN $(docker-machine ip node-1):2377

包含三個節(jié)點的Docker Swarm集群

現(xiàn)在我們已經(jīng)擁有了Swarm集群，下面利用一個dab文件部署一項服務(wù)。

相較于利用大量參數(shù)創(chuàng)建網(wǎng)絡(luò)及Docker服務(wù)，這里我們選擇使用一個dab文件。大家可以將其作為Swarm當(dāng)中的Docker Compose。至于Swarm，我指的是docker swarm、docker service以及其它來自1.12+版本的新機制（而非以往作為獨立容器運行的Swarm）。

相較于指定新格式的具體細(xì)節(jié)以建立服務(wù)，這里我們直接使用docker-compose.yml文件完成設(shè)置。

讓我們首先檢查演示服務(wù)的代碼。

git clone https://github.com/vfarcic/go-demo.git
 cd go-demo
 cat docker-compose.yml

最后一項命令會輸出Docker Compose項目定義，其具體內(nèi)容如下。

version: "2"
 services:
  app:
    image: vfarcic/go-demo
    ports:
      - 8080
  db:
    image: mongo

如大家所見，這個項目非常簡單。其中只包含兩項服務(wù)，app服務(wù)為后端并公開一個API，其利用第二項服務(wù)（db）進(jìn)行數(shù)據(jù)存儲與檢索。app服務(wù)公開端口8080，并將其作為API的入口點。

將此Docker Compose定義轉(zhuǎn)化為捆綁包需要進(jìn)行兩步操作。首先，我們需要提取相關(guān)鏡像。該bundle的創(chuàng)建會首先進(jìn)行鏡像評估，而后將docker-compose.yml文件的內(nèi)容與之相合，最終輸出為dab文件。

下面進(jìn)行嘗試。

eval $(docker-machine env node-1) 
docker-compose pull
docker-compose bundle

現(xiàn)在這一流程已經(jīng)完成，看看結(jié)果如何。

cat godemo.dab

其輸出結(jié)果如下所示：

{
  "Services": {
    "app": {
      "Image": "vfarcic/go-demo@sha256:f7436796b1cd6812ba63ea82c6523a5164ae7f8a3c05daa9e4ac4bd78341d709",
      "Networks": [
        "default"
      ],
      "Ports": [
        {
          "Port": 8080,
          "Protocol": "tcp"
        }
      ]
    },
    "db": {
      "Image": "mongo@sha256:e599c71179c2bbe0eab56a7809d4a8d42ddcb625b32a7a665dc35bf5d3b0f7c4",
      "Networks": [
        "default"
      ]
    }
  },
  "Version": "0.1"
}

我們剛剛創(chuàng)建的godemo.dab文件非常簡單。其中包含的兩項服務(wù)與docker-compose.yml文件相匹配。每項服務(wù)都指定了與提取的哈希值相符合的鏡像。鏡像部分之后為默認(rèn)網(wǎng)絡(luò)，包括相關(guān)服務(wù)以及需要開啟的端口。

這部分輸出結(jié)果中至少包含兩個問題。第一，我們不需要開啟任何端口。相反，我們應(yīng)當(dāng)使用反向代理將全部請求重新定向至該服務(wù)。新的Docker Swarm網(wǎng)絡(luò)功能已經(jīng)整合了一項代理，我們應(yīng)當(dāng)直接加以利用。

第二個問題在于，我們并沒有指定任何約束條件。將不受約束的服務(wù)部署至集群當(dāng)中無疑會引發(fā)嚴(yán)重的問題。

大家可以參閱此docker-compose-swarm.yml文件以獲取一項更好但同樣非常簡單的Compose定義。其內(nèi)容如下所示：

version: "2" 
services: 
  app:
    image: vfarcic/go-demo
    mem_limit: 250m 
  db:
    image: mongo
    mem_limit: 500m

可以看到，我們移除了端口部分內(nèi)容并添加了一項mem_limit約束。這個Compose文件仍然非常簡單。

下面創(chuàng)建新的捆綁包輸出結(jié)果。

docker-compose -f docker-compose-swarm.yml bundle

運行bundle命令后的輸出結(jié)果如下所示：

WARNING: Unsupported key "mem_limit" in services.app - ignoring
WARNING: Unsupported key "mem_limit" in services.db - ignoring
Wrote bundle to godemo.dab

現(xiàn)在我們來談第一條壞消息。目前的bundle格式還存在諸多局限。我們可以利用其處理非常簡單的場景，然而一旦指定任何復(fù)雜的內(nèi)容，系統(tǒng)即會給出警告。在本示例中，我們忽略內(nèi)存限制警告。

現(xiàn)在我們暫時不理這一限制警告，嘗試部署剛剛創(chuàng)建的新捆綁包。

docker deploy godemo

運行deploy命令后的輸出結(jié)果如下所示：

Loading bundle from godemo.dab
Creating network godemo_default
Creating service godemo_app
Creating service godemo_db

現(xiàn)在網(wǎng)絡(luò)與服務(wù)都已經(jīng)創(chuàng)建完成。我們可以列出全部服務(wù)進(jìn)行確認(rèn)。

docker stack ps godemo

可以看到由兩項服務(wù)構(gòu)成的堆棧，每項服務(wù)都被部署在我們的這套三節(jié)點集群中的某個位置，而且當(dāng)前狀態(tài)為running。如果顯示的狀態(tài)與此不符，則請等待一會兒讓容器完成提取，再重新運行此命令。

不過其中仍存在功能缺失的問題。我們的內(nèi)存限制被忽略了，而且還沒有創(chuàng)建外部網(wǎng)絡(luò)proxy并將app服務(wù)附加至該代理處。

要解決這個問題，我們可以執(zhí)行service update命令。舉例來說，我們可以手動創(chuàng)建proxy網(wǎng)絡(luò)并將其中添加容器。我們也可以使用service update命令設(shè)置內(nèi)存限制。然而，如果我們進(jìn)行這樣的操作，那么一開始就不應(yīng)該使用捆綁包機制。

在大家決定放棄bundle之前，請注意這套方案尚處于實驗階段。本篇教程只是為了讓大家先嘗嘗鮮。我們預(yù)計其未來將迎來巨大改進(jìn)，且能夠全面支持Swarm提供的各項功能。

現(xiàn)在的問題是，我們當(dāng)前能夠做些什么。這里建議大家選擇以下幾種作法：其一，等待bundle完成實驗階段并支持Docker Swarm能夠提供的全部功能; 其二，使用Whaleprint項目，其基本上相當(dāng)于dab文件與其它功能（例如約束）以及Terraform方案的結(jié)合體。此項目很有前途，不過與bundle一樣，其同樣處于起步階段。

希望本篇文章能夠幫助大家了解全新Swarm的發(fā)展方向。目前bundle還在開發(fā)當(dāng)中，我們預(yù)計其未來將成為一種向集群部署服務(wù)的可靠備選方案?？偠灾⒆阌诋?dāng)下期待未來才是最重要的，千萬別被其簡陋的現(xiàn)狀所嚇退。

因此，我建議大家對頒式應(yīng)用捆綁包加以關(guān)注并靜待其發(fā)展成熟。在此期間，通過命令或者嘗試Wahleprint項目則是最好的選擇。

?
PS，數(shù)人云新一期的活動報名開始啦，聽大牛們談?wù)勅萜鞯那閼?，如何助力敏捷開發(fā)，高效運維，讓產(chǎn)品迭代力MAX！點擊下方鏈接快快報名吧！
數(shù)人云Meetup|容器助力產(chǎn)品迭代力MAX