摘要：其一將用于代理與面向公開的服務之間的通信。數據庫上線并開始運行后，我們接下來部署后端。現在，會幫助我們完成全部負載均衡工作。這樣所有來自代理的請求都將指向網絡，并由后者跨越全部實例執行負載均衡。

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

下面我們將共同探討如何利用其對各服務進行公開。我們還將嘗試將一套代理機制整合至Swarm網絡當中，從而更為充分地發揮1.12版本帶來的優勢。

在開始進行之前，我們需要設置一套用于演示的集群。

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

如果您是Windows用戶，請利用Git Bas運行全部示例（通過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`

現在我們已經擁有了一套Swarm集群，接下來是部署一項服務。

包含三個節點的Docker Swarm集群

為了檢驗新的Docker Swarm網絡功能，我們首先創建以下兩套網絡。

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

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

我們將從數據庫起步。由于其不會公共開放，因此不需要將其添加至代理當中。這里，我們直接將其附加至go-demo網絡。

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

數據庫上線并開始運行后，我們接下來部署后端。由于我們希望外部用戶能夠使用該API，因此應當將其納入代理。我們將其同時附加至兩套網絡（proxy與go-demo）。

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

由三臺節點、兩套網絡與多套容器構成的Docker Swarm集群

現在兩套容器都運行在集群當中，且能夠彼此通過go-demo網絡進行通信。下面將代理引入其中。我們這里使用HAProxy。

需要注意的是，我們并沒有指定端口，這意味著沒有任何一套容器能夠為go-demo網絡之外的請求所訪問。

我們可以通過多種方式建立代理機制。其一利用HAProxy創建一套新鏡像，其中包含各配置文件。這種方式比較適合服務數量相對固定的情況。否則，我們應當創建一套每當有新服務（而非新版本發布）出現時即進行新配置的鏡像。

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

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

下面一起來看：

  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將負責處理互聯網流量（HTTP與HTTPS）。第三個端口則為8080，我們將利用它向代理發送配置請求。另外，我們強調其應當歸屬于proxy網絡。如此一來，由于go-demo也被附加至同一套網絡，意味著代理能夠通過SDN對其進行訪問。

在這套代理的幫助下，我們實現了最實用的網絡路由功能之一。無論大家在哪臺服務器上運行該代理，我們都能夠向任意節點發送請求，而Docker網絡會確保其被重新定向至代理之一。

最后一項參數為環境變量MODE，其負責告知該代理，各容器將被部署至Swarm集群當中。請參閱項目的README文件以了解更多細節信息。

配合代理服務的Docker Swarm集群

需要注意的是，該代理即使已經運行在某一節點當中，仍會被放置于其外以表達其在邏輯上的分離特性。

在開始之前，首先確認代理正在運行。

docker service ps proxy

如果其“最新狀態（Last state）”為“運行（Running）”，則可繼續。如果不然，請等待直到該服務上線并開始運行。

現在代理已經部署完成，我們應當確保其知曉go-demo服務的存在。

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

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

現在我們可以測試代理是否按預期運行——發送一條HTTP請求進行驗證。

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

該curl命令的輸出結果如下所示。

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!

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

需要注意的是，這一過程與我們執行操作所在的具體節點無關。由于Docker網絡（路由體系）負責實現負載均衡，因此我們能夠前往任意服務器。作為示例，下面我們發送同樣的請求，但這一次立足于node-3。

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

結果仍然完全相同。

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

如果大家選擇自行構建代理解決方案，那么當然需要了解如何配置代理并利用Docker網絡中的各項新功能。

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

第一步，我們需要找到代理運行所在的具體節點。

docker service ps proxy

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

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

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

 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

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

接下來的問題是，如何實現負載均衡。舉例來說，我們要如何指定該代理跨越全部實例執行循環？

在開始進行負載均衡解釋之前，首先創建幾個go-demo服務實例。

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

稍等一會兒，就將有5個go-demo服務實例開始運行。

包含規模化go-demo服務與代理實例的Docker Swarm集群

我們該如何讓代理將請求均衡至全部實例當中？答案是不用——我們并不需要執行特別的操作。

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

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

然而在新的Docker網絡當中，我們將不再需要進行上述配置。原本的作法只會在新副本添加或者刪除時，給我們的實例監控與代理更新工作造成麻煩。

現在，Docker會幫助我們完成全部負載均衡工作。更準確地講，當該代理將某條請求重新定向至go-demo時，其實際將其發送至Docker網絡并由后者執行跨越全部服務副本（實例）的負載均衡。這套方案的意義在于，代理負責將端口80（或者443）重新定向至網絡中的正確服務處，其它任務則全部由Docker完成。

大家可以隨意向該服務發送更多請求，并檢查其中一套副本的日志記錄。在這里，大家會發現其接收到的請求約為總體請求數量的五分之一——與我們的服務實例數量恰好吻合。

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

但新的問題在于，這套方案的具體效率是否理想。畢竟我們在體系中引入了新的層。盡管過去我們也會使用代理以及服務，但現在Docker網絡會在二者之間建立負載均衡機制。答案是，由此帶來的運行負擔非常有限。Docker利用Linux IPVS實現負載均衡，其作為Linux內核的組成部分已經擁有超過15年歷史，而且事實證明其是一種極為高效的負載均衡實現方式。事實上，其速度表現遠遠優于nginx或者HAProxy。

下一個問題是，我們是否需要代理機制。是的，當然需要。DOcker所使用的IPVS只負責實現負載均衡。我們還需要一套代理以接收來自端口80與443的請求，并根據其實際路徑將其重新定向至各目標服務。在此基礎之上，我們還可以利用它執行多種任務，包括SSL握手以及驗證等等。

那么這種作法存在哪些缺點？首先想到的肯定是粘性會話。如果我們希望同一用戶向同一實例發送請求，那么這套方案顯然并不適用。另一個問題是，我們是否應當在服務之內實現粘性會話，或者應該將其作為獨立實體。這個問題我們在本文中暫時不作討論，只需要明確這里提到的方案并不適用于粘性會話即可。

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

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

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

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

今天我們已經總結了Docker v1.12帶來的一系列Swarm與網絡新功能，特別是在公開代理方面的改進。

那么我們是不是就能夠成功運行Swarm群集了呢？還差得遠！本文僅僅只是開始，我們還有大量問題有待回答。Docker Compose發生了哪些改變？我們該如何在不造成停機的前提下部署新版本？是否還有其它值得一試的工具？

后續的內容，也敬請大家期待！