摘要：其一將用于代理與面向公開的服務(wù)之間的通信。數(shù)據(jù)庫上線并開始運(yùn)行后，我們接下來部署后端。現(xiàn)在，會(huì)幫助我們完成全部負(fù)載均衡工作。這樣所有來自代理的請(qǐng)求都將指向網(wǎng)絡(luò)，并由后者跨越全部實(shí)例執(zhí)行負(fù)載均衡。

七夕大家過得怎么樣？今天數(shù)人云帶大家回歸技術(shù)和干貨。雖然我們能夠在Swarm集群當(dāng)中部署任意數(shù)量的服務(wù)，但這并不代表各項(xiàng)服務(wù)全部可為用戶所訪問。而新的Swarm網(wǎng)絡(luò)使得各項(xiàng)服務(wù)之間能夠更為輕松地實(shí)現(xiàn)彼此通信。

下面我們將共同探討如何利用其對(duì)各服務(wù)進(jìn)行公開。我們還將嘗試將一套代理機(jī)制整合至Swarm網(wǎng)絡(luò)當(dāng)中，從而更為充分地發(fā)揮1.12版本帶來的優(yōu)勢(shì)。

在開始進(jìn)行之前，我們需要設(shè)置一套用于演示的集群。

要完成本示例，我們假定大家已經(jīng)擁有一套版本為v0.8或者更高的Docker Machine，其中包含版本為v1.12或者更高的Docker Engine。最便捷的獲取方法就是通過Docker Toolbox下載。

如果您是Windows用戶，請(qǐng)利用Git Bas運(yùn)行全部示例（通過Docker Toolbox安裝）。

 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`

現(xiàn)在我們已經(jīng)擁有了一套Swarm集群，接下來是部署一項(xiàng)服務(wù)。

包含三個(gè)節(jié)點(diǎn)的Docker Swarm集群

為了檢驗(yàn)新的Docker Swarm網(wǎng)絡(luò)功能，我們首先創(chuàng)建以下兩套網(wǎng)絡(luò)。

 eval $(docker-machine env node-1)
 docker network create --driver overlay proxy
 docker network create --driver overlay go-demo

其一（proxy）將用于代理與面向API公開的服務(wù)之間的通信。而其二（go-demo）則面向全部用于構(gòu)建go-demo服務(wù)的容器。該服務(wù)包含兩套容器，且利用MongoDB用于存儲(chǔ)數(shù)據(jù)，而vfarcic/go-demo則作為配備API的后端。

我們將從數(shù)據(jù)庫起步。由于其不會(huì)公共開放，因此不需要將其添加至代理當(dāng)中。這里，我們直接將其附加至go-demo網(wǎng)絡(luò)。

  docker service create --name go-demo-db 
  --network go-demo 
  mongo

數(shù)據(jù)庫上線并開始運(yùn)行后，我們接下來部署后端。由于我們希望外部用戶能夠使用該API，因此應(yīng)當(dāng)將其納入代理。我們將其同時(shí)附加至兩套網(wǎng)絡(luò)（proxy與go-demo）。

  docker service create --name go-demo 
  -e DB=go-demo-db 
  --network go-demo 
  --network proxy 
  vfarcic/go-demo

由三臺(tái)節(jié)點(diǎn)、兩套網(wǎng)絡(luò)與多套容器構(gòu)成的Docker Swarm集群

現(xiàn)在兩套容器都運(yùn)行在集群當(dāng)中，且能夠彼此通過go-demo網(wǎng)絡(luò)進(jìn)行通信。下面將代理引入其中。我們這里使用HAProxy。

需要注意的是，我們并沒有指定端口，這意味著沒有任何一套容器能夠?yàn)間o-demo網(wǎng)絡(luò)之外的請(qǐng)求所訪問。

我們可以通過多種方式建立代理機(jī)制。其一利用HAProxy創(chuàng)建一套新鏡像，其中包含各配置文件。這種方式比較適合服務(wù)數(shù)量相對(duì)固定的情況。否則，我們應(yīng)當(dāng)創(chuàng)建一套每當(dāng)有新服務(wù)（而非新版本發(fā)布）出現(xiàn)時(shí)即進(jìn)行新配置的鏡像。

通過第二種方法，其將以分卷形式存在，我們能夠在必要時(shí)僅修改配置文件而非整套新鏡像。然而，這種作法也存在弊端。在部署至一套集群時(shí)，我們應(yīng)當(dāng)盡可能避免使用分卷。接下來大家會(huì)看到，代理就是不需要分卷的機(jī)制之一。另外，--volume可替換為docker service命令中的—mount參數(shù)。

第三種選項(xiàng)是使用專門與Docker Swarm協(xié)作的代理之一。在這種情況下，我們將使用vfarcic/docker-flow-proxy容器，其由Docker Flow: Proxy項(xiàng)目創(chuàng)建而成。其基于HAProxy且擁有多項(xiàng)其它功能，允許我們通過發(fā)送HTTP請(qǐng)求對(duì)其進(jìn)行重新配置。

下面一起來看：

  docker service create --name proxy 
    -p 80:80 
    -p 443:443 
    -p 8080:8080 
    --network proxy 
    -e MODE=swarm 
    vfarcic/docker-flow-proxy`

我們開啟的端口80與443將負(fù)責(zé)處理互聯(lián)網(wǎng)流量（HTTP與HTTPS）。第三個(gè)端口則為8080，我們將利用它向代理發(fā)送配置請(qǐng)求。另外，我們強(qiáng)調(diào)其應(yīng)當(dāng)歸屬于proxy網(wǎng)絡(luò)。如此一來，由于go-demo也被附加至同一套網(wǎng)絡(luò)，意味著代理能夠通過SDN對(duì)其進(jìn)行訪問。

在這套代理的幫助下，我們實(shí)現(xiàn)了最實(shí)用的網(wǎng)絡(luò)路由功能之一。無論大家在哪臺(tái)服務(wù)器上運(yùn)行該代理，我們都能夠向任意節(jié)點(diǎn)發(fā)送請(qǐng)求，而Docker網(wǎng)絡(luò)會(huì)確保其被重新定向至代理之一。

最后一項(xiàng)參數(shù)為環(huán)境變量MODE，其負(fù)責(zé)告知該代理，各容器將被部署至Swarm集群當(dāng)中。請(qǐng)參閱項(xiàng)目的README文件以了解更多細(xì)節(jié)信息。

配合代理服務(wù)的Docker Swarm集群

需要注意的是，該代理即使已經(jīng)運(yùn)行在某一節(jié)點(diǎn)當(dāng)中，仍會(huì)被放置于其外以表達(dá)其在邏輯上的分離特性。

在開始之前，首先確認(rèn)代理正在運(yùn)行。

docker service ps proxy

如果其“最新狀態(tài)（Last state）”為“運(yùn)行（Running）”，則可繼續(xù)。如果不然，請(qǐng)等待直到該服務(wù)上線并開始運(yùn)行。

現(xiàn)在代理已經(jīng)部署完成，我們應(yīng)當(dāng)確保其知曉go-demo服務(wù)的存在。

curl "$(docker-machine ip node-1):8080/v1/docker-flow-proxy/reconfigure?serviceName=go-demo&servicePath=/demo&port=8080"

這條請(qǐng)求的作用是重新配置代理以指定服務(wù)名稱（go-demo）、API的URL路徑（/demo）以及該服務(wù)的內(nèi)部端口（8080）。從現(xiàn)在開始，所有指向該代理且使用以/demo開頭路徑的請(qǐng)求都將被重新定向至go-demo服務(wù)。

現(xiàn)在我們可以測(cè)試代理是否按預(yù)期運(yùn)行——發(fā)送一條HTTP請(qǐng)求進(jìn)行驗(yàn)證。

curl -i $(docker-machine ip node-1)/demo/hello

該curl命令的輸出結(jié)果如下所示。

HTTP/1.1 200 OK
Date: Mon, 18 Jul 2016 23:11:31 GMT
Content-Length: 14
Content-Type: text/plain; charset=utf-8
 hello, world!

代理正常起效！它響應(yīng)了HTTP status 200并向API返回了hello，world！

需要注意的是，這一過程與我們執(zhí)行操作所在的具體節(jié)點(diǎn)無關(guān)。由于Docker網(wǎng)絡(luò)（路由體系）負(fù)責(zé)實(shí)現(xiàn)負(fù)載均衡，因此我們能夠前往任意服務(wù)器。作為示例，下面我們發(fā)送同樣的請(qǐng)求，但這一次立足于node-3。

curl -i $(docker-machine ip node-3)/demo/hello

結(jié)果仍然完全相同。

下面讓我們一起了解由該代理生成的配置。

如果大家選擇自行構(gòu)建代理解決方案，那么當(dāng)然需要了解如何配置代理并利用Docker網(wǎng)絡(luò)中的各項(xiàng)新功能。

下面首先檢查Docker Flow: Proxy為我們創(chuàng)建的配置。我們可以進(jìn)入當(dāng)前運(yùn)行的容器并通過/cfg/haproxy.cfg文件查看這部分信息。不過問題是，找到由Docker Swarm運(yùn)行的一套容器需要配合一點(diǎn)技巧。舉例來說，如果我們利用Docker Compose部署此容器，那么其名稱會(huì)存在一定規(guī)律，即使用__格式。而docker service命令會(huì)利用散列后的名稱運(yùn)行容器。在我的筆記本上，docker-flow-proxy的創(chuàng)建名稱為proxy.1.e07jvhdb9e6s76mr9ol41u4sn。因此，要進(jìn)入由Docker Swarm部署并運(yùn)行的容器，我們需要對(duì)鏡像名稱進(jìn)行過濾。

第一步，我們需要找到代理運(yùn)行所在的具體節(jié)點(diǎn)。

docker service ps proxy

需要注意的是該node列中的值，同時(shí)確保在以下命令中使用該正確值。

eval $(docker-machine env node-1) # Change node-1 with the node value previously obtained

此命令將給出以下代理配置輸出結(jié)果。

 docker exec -it 
    $(docker ps -q --filter "ancestor=vfarcic/docker-flow-proxy") 
    cat /cfg/haproxy.cfg
 exit

配置信息中最重要的部分如下所示。

 frontend services
    bind *:80
    bind *:443
    option http-server-close
    acl url_go-demo path_beg /demo
    use_backend go-demo-be if url_go-demo
 backend go-demo-be
    server go-demo go-demo:8080

對(duì)于第一部分（frontend），熟悉HAProxy的朋友應(yīng)該不會(huì)感到陌生。其接收來自端口80（HTTP）以及443（HTTPS）的請(qǐng)求。如果路徑以/demo開頭，其會(huì)被重新定向至后端go-demo處。在這里，各請(qǐng)求會(huì)被發(fā)送至go-demo在端口8080上的地址。此地址同時(shí)亦是我們所部署的服務(wù)名稱。由于go-demo同proxy存在于同一網(wǎng)絡(luò)當(dāng)中，因此Docker能夠確保該請(qǐng)求被重新定向至目標(biāo)容器。很簡(jiǎn)單，對(duì)吧？我們無需再另行指定IP以及外部端口。

接下來的問題是，如何實(shí)現(xiàn)負(fù)載均衡。舉例來說，我們要如何指定該代理跨越全部實(shí)例執(zhí)行循環(huán)？

在開始進(jìn)行負(fù)載均衡解釋之前，首先創(chuàng)建幾個(gè)go-demo服務(wù)實(shí)例。

 eval $(docker-machine env node-1)
 docker service scale go-demo=5

稍等一會(huì)兒，就將有5個(gè)go-demo服務(wù)實(shí)例開始運(yùn)行。

包含規(guī)?；痝o-demo服務(wù)與代理實(shí)例的Docker Swarm集群

我們?cè)撊绾巫尨韺⒄?qǐng)求均衡至全部實(shí)例當(dāng)中？答案是不用——我們并不需要執(zhí)行特別的操作。

正常來講，如果我們不使用Docker Swarm功能，則可使用以下配置方式：

backend go-demo-be
    server instance_1 :
    server instance_2 :
    server instance_3 :
    server instance_4 :
    server instance_5 :

然而在新的Docker網(wǎng)絡(luò)當(dāng)中，我們將不再需要進(jìn)行上述配置。原本的作法只會(huì)在新副本添加或者刪除時(shí)，給我們的實(shí)例監(jiān)控與代理更新工作造成麻煩。

現(xiàn)在，Docker會(huì)幫助我們完成全部負(fù)載均衡工作。更準(zhǔn)確地講，當(dāng)該代理將某條請(qǐng)求重新定向至go-demo時(shí)，其實(shí)際將其發(fā)送至Docker網(wǎng)絡(luò)并由后者執(zhí)行跨越全部服務(wù)副本（實(shí)例）的負(fù)載均衡。這套方案的意義在于，代理負(fù)責(zé)將端口80（或者443）重新定向至網(wǎng)絡(luò)中的正確服務(wù)處，其它任務(wù)則全部由Docker完成。

大家可以隨意向該服務(wù)發(fā)送更多請(qǐng)求，并檢查其中一套副本的日志記錄。在這里，大家會(huì)發(fā)現(xiàn)其接收到的請(qǐng)求約為總體請(qǐng)求數(shù)量的五分之一——與我們的服務(wù)實(shí)例數(shù)量恰好吻合。

Docker網(wǎng)絡(luò)與Docker 1.12及更高版本提供的Swarm相結(jié)合，無疑開啟了一道通向更多新機(jī)遇的大門。不同容器與負(fù)載均衡之間的內(nèi)部通信只是其中的一小部分，我們亦可以更為輕松地配置公開代理。另外，我們需要確保面向API進(jìn)行公開的全部服務(wù)皆以代理形式接入同一網(wǎng)絡(luò)。在此之后，我們要做的就是進(jìn)行配置以將所有請(qǐng)求重新定向至目標(biāo)服務(wù)名稱。這樣所有來自代理的請(qǐng)求都將指向Docker網(wǎng)絡(luò)，并由后者跨越全部實(shí)例執(zhí)行負(fù)載均衡。

但新的問題在于，這套方案的具體效率是否理想。畢竟我們?cè)隗w系中引入了新的層。盡管過去我們也會(huì)使用代理以及服務(wù)，但現(xiàn)在Docker網(wǎng)絡(luò)會(huì)在二者之間建立負(fù)載均衡機(jī)制。答案是，由此帶來的運(yùn)行負(fù)擔(dān)非常有限。Docker利用Linux IPVS實(shí)現(xiàn)負(fù)載均衡，其作為L(zhǎng)inux內(nèi)核的組成部分已經(jīng)擁有超過15年歷史，而且事實(shí)證明其是一種極為高效的負(fù)載均衡實(shí)現(xiàn)方式。事實(shí)上，其速度表現(xiàn)遠(yuǎn)遠(yuǎn)優(yōu)于nginx或者HAProxy。

下一個(gè)問題是，我們是否需要代理機(jī)制。是的，當(dāng)然需要。DOcker所使用的IPVS只負(fù)責(zé)實(shí)現(xiàn)負(fù)載均衡。我們還需要一套代理以接收來自端口80與443的請(qǐng)求，并根據(jù)其實(shí)際路徑將其重新定向至各目標(biāo)服務(wù)。在此基礎(chǔ)之上，我們還可以利用它執(zhí)行多種任務(wù)，包括SSL握手以及驗(yàn)證等等。

那么這種作法存在哪些缺點(diǎn)？首先想到的肯定是粘性會(huì)話。如果我們希望同一用戶向同一實(shí)例發(fā)送請(qǐng)求，那么這套方案顯然并不適用。另一個(gè)問題是，我們是否應(yīng)當(dāng)在服務(wù)之內(nèi)實(shí)現(xiàn)粘性會(huì)話，或者應(yīng)該將其作為獨(dú)立實(shí)體。這個(gè)問題我們?cè)诒疚闹袝簳r(shí)不作討論，只需要明確這里提到的方案并不適用于粘性會(huì)話即可。

那么其具備哪些優(yōu)勢(shì)？首先，整個(gè)實(shí)現(xiàn)過程非常簡(jiǎn)單。我們用不著在部署新副本時(shí)對(duì)代理進(jìn)行重新配置。如此一來，整個(gè)流程將非常便捷。由于我們不需要包含全部端口IP及端口的列表，因此也就無需使用Registrator以及Consul Template之類的工具。過去，我們需要利用Registrator以監(jiān)控Docker事件，并將IP及端口保存在鍵值存儲(chǔ)方案（例如Consul）當(dāng)中。信息存儲(chǔ)完成后，我們會(huì)利用Consul Template重新創(chuàng)建代理配置。雖然不少項(xiàng)目都能簡(jiǎn)化這一流程，但Docker Swarm與Docker網(wǎng)格的再現(xiàn)從根本上降低了其實(shí)施難度。

在本文中，我們講述了如何利用Docker Flow: Proxy項(xiàng)目配置HAProxy。其中包含HAProxy及一系列其它API，允許我們利用簡(jiǎn)單的HTTP請(qǐng)求對(duì)代理進(jìn)行重新配置。另外，其還消除了對(duì)手動(dòng)配置或者模板的依賴性。

在另一方面，建立自定義解決方案的流程也變得更為簡(jiǎn)單。本文只稍稍列舉幾項(xiàng)重點(diǎn)即解釋了整個(gè)構(gòu)建過程，這在nginx或者HAProxy配置工作中是完全無法想象的。

所以我的建議是先嘗試一下Docker Flow: Proxy，而后再做決定。

今天我們已經(jīng)總結(jié)了Docker v1.12帶來的一系列Swarm與網(wǎng)絡(luò)新功能，特別是在公開代理方面的改進(jìn)。

那么我們是不是就能夠成功運(yùn)行Swarm群集了呢？還差得遠(yuǎn)！本文僅僅只是開始，我們還有大量問題有待回答。Docker Compose發(fā)生了哪些改變？我們?cè)撊绾卧诓辉斐赏C(jī)的前提下部署新版本？是否還有其它值得一試的工具？

后續(xù)的內(nèi)容，也敬請(qǐng)大家期待！