Docker Swarm羣集配置實戰（2）

前言：

---

這篇博文是基於docker Swarm羣集環境之上，延伸了Docker Swarm的功能。

博文大綱：
1、Docker Swarm網絡管理
2、Swarm的service管理及版本更新

這篇博文的環境仍是基於上一篇博文中搭建的環境，具體能夠參考博文：Docker Swarm羣集配置實戰（1） ，在進行接下來的操做以前，必需要保證訪問docker Swarm的web UI時，能夠看到如下界面：

1、Docker Swarm網絡管理

Swarm羣集會產生兩種不一樣類型的流量：

• 控制和管理層面：包括 Swarm 消息管理等，例如請求加入或離開Swarm，這種類型的流量老是被加密的。(涉及到集羣內部的hostname、ip-address、subnet、gateway等)；
• 應用數據層面：包括容器與客戶端的通訊等。（涉及到防火牆、端口映射、網口映射、VIP等）

在Swarm service中有三個重要的網絡概念：

• overlay networks 管理Swarm中docker守護進程間的通訊。能夠將容器附加到一個或多個已存在的overlay網絡上，使容器與容器之間可以通訊；
• ingress network 是一個特殊的 overlay 網絡，用於服務節點間的負載均衡。當任何 Swarm 節點在發佈的端口上接收到請求時，它將該請求交給一個名爲 IPVS 的模塊。IPVS 跟蹤參與該服務的全部IP地址，選擇其中的一個，並經過 ingress 網絡將請求路由到它；
  初始化或加入 Swarm 集羣時會自動建立 ingress 網絡，大多數狀況下，用戶不須要自定義配置，可是 docker 17.05 和更高版本容許你自定義。
• docker_gwbridge是一種橋接網絡，將 overlay 網絡（包括 ingress 網絡）鏈接到一個單獨的 Docker 守護進程的物理網絡。默認狀況下，服務正在運行的每一個容器都鏈接到本地 Docker 守護進程主機的 docker_gwbridge 網絡。
  docker_gwbridge 網絡在初始化或加入 Swarm 時自動建立。大多數狀況下，用戶不須要自定義配置，可是 Docker 容許自定義。

查看docker01上面的默認網絡，以下（注意其SCOPE列，確認其生效範圍）：

除了Swarm羣集默認建立的兩個網絡之外，咱們還能夠自定義建立overlay網絡，鏈接到此網絡的容器，便可互相通訊，可是須要注意，除了在docker01這個manager上能夠查看建立的overlay網絡外，其餘節點在沒有加入此網絡前，執行「docker network ls」命令是查看不到的。

建立自定義overlay網絡並驗證

[root@docker01 ~]# docker network create -d overlay --subnet 192.168.22.0/24 --gateway 192.168.22.1 --attachable my_net1
# 建立一個overlay網絡，名字爲my_net1；
# 「--subnet」：指定其網段（能夠不指定）；「--gateway」：指定其網關（能夠不指定）；
# 可是在docker  Swarm羣集中建立overlay網絡時，必須添加「--attachable」選項
# 不然，其餘節點的容器運行時，沒法使用此網絡

建立完成後，在其餘docker節點上是查看不到這個新建立的overlay網絡的，可是，可使用此網絡（在運行容器時，直接指定便可，等容器運行後，即可以查看到此網絡了）

測試剛剛建立的overlay網絡，是否可用，分別在docker0一、docker02上基於建立的overlay網絡運行一個容器，而後進行ping測試，確承認以ping通：

#docker01主機上基於overlay網絡建立一個容器：
[root@docker01 ~]# docker run -tid --network my_net1 --name test1 busybox
#同docker01的操做，在docker02上也建立一個：
[root@docker02 ~]# docker run -tid --network my_net1 --name test2 busybox

在容器建立後，在docker02主機上，使用test2這個容器去ping容器test1，測試結果以下（因爲是自定義網絡，因此能夠直接ping對端容器的容器名）：

2、Swarm的service管理及版本更新

一、指定某個service運行在同一臺docker服務器上

在第一篇的博文中測試過，若是Swarm羣集中的manager下發一個service任務，那麼，下發的任務將隨機分佈在羣集中的docker服務器之上運行， 若是說，因爲須要將本身的生產環境配置的統1、規範一些，某一臺docker服務器，我就只運行web服務，另外一臺docker主機，我就只運行PHP服務，那麼，怎麼解決呢？

解決方案一：

[root@docker01 ~]# docker service create --replicas 3 --constraint node.hostname==docker03 --name test nginx
#在docker03主機上，基於nginx鏡像，運行3個名爲test的容器

上述命令的執行後以下所示：

解決方案二：

[root@docker01 ~]# docker node update --label-add mem=max docker02
#以鍵值對的方式給docker02主機打上標籤「mem=max」，等號兩邊的內容是能夠自定義的
[root@docker01 ~]# docker service create --name test01 --replicas 3 --constraint 'node.labels.mem==max' nginx
#基於nginx鏡像在標籤爲「mem==max」的主機上運行3個名爲test01的服務
[root@docker01 ~]# docker node inspect docker02   #能夠執行此命令查看dokcer02主機的標籤
#標籤相關的信息，在Spec{  }中

查看web UI界面進行確認：

二、更新某個service版本

1）準備要使用的鏡像，並基於此鏡像運行service

[root@docker01 aa]# cat html/index.html    #準備網頁文件
127.0.0.1
[root@docker01 aa]# cat Dockerfile      
#基於nginx容器，將當前目錄下的html目錄掛載爲nginx的網頁根目錄
FROM nginx
ADD html /usr/share/nginx/html
[root@docker01 aa]# docker build -t 192.168.20.6:5000/testnginx:1.0 .     #生成一個鏡像
[root@docker01 aa]# docker push 192.168.20.6:5000/testnginx:1.0
#將新生成的鏡像上傳至私有倉庫
[root@docker01 aa]# docker service create --name newnginx -p 80:80 --replicas 3  192.168.20.6:5000/testnginx:1.0 
#基於上傳到私有倉庫的鏡像，運行三個service，並映射到本地80端口
#當上面的命令執行成功後，只要docker主機上運行着那個service，就能夠經過它的80端口訪問到nginx服務

運行後，web UI界面顯示以下：

能夠看到，每一個節點都運行了那個service，也就是說，訪問哪一個節點的80端口，均可以看到同樣的頁面，以下：

在docker01上查看service的詳細信息，以下：

[root@docker01 aa]# docker service ps newnginx    #查看service的詳細信息

命令執行的結果（須要注意的是其鏡像標籤，也就是說注意其是基於哪一個鏡像運行的）：

2）準備該鏡像的2.0版本（模擬在線版本升級）：

[root@docker01 aa]# docker tag nginx:latest 192.168.20.6:5000/testnginx:2.0 
#準備2.0版本的鏡像
[root@docker01 aa]# docker push 192.168.20.6:5000/testnginx:2.0 
#上傳到私有倉庫
[root@docker01 aa]# docker service update --image 192.168.20.6:5000/testnginx:2.0 newnginx 
#將newnginx服務的鏡像升級到2.0
[root@docker01 aa]# docker service ps newnginx    #再次查看service的詳細信息

命令執行的結果以下，發現基於1.0鏡像運行的newnginx的service狀態已經變成了shutdown，而基於2.0運行的service變爲了running，以下：

此時，若再次訪問其web頁面，就變爲了nginx的默認首頁（由於咱們的2.0鏡像只是更改了下nginx鏡像的標籤，並無修改其文件），以下：

其web UI界面能夠查看到該service的最後一次升級的時間。

3）升級2.0到3.0（升級時，對其進行精細的控制）

[root@docker01 aa]# docker tag nginx:latest 192.168.20.6:5000/testnginx:3.0 
#準備3.0版本的鏡像
[root@docker01 aa]# docker push 192.168.20.6:5000/testnginx:3.0 
#上傳到私有倉庫
[root@docker01 ~]# docker service update --replicas 6 --image 192.168.20.6:5000/testnginx:3.0 --update-parallelism 3 --update-delay 1m newnginx
#上述選項的含義以下：
# 「--replicas 6」：更新後的service數量爲6個（本來是3個）
# 「 --update-parallelism 2 」：設置並行更新的副本數。
# 「 --update-delay 1m 」：指定滾動更新的時間間隔爲1分鐘
[root@docker01 ~]# docker service ps newnginx    #自行對比newnginx服務的詳細信息

4）版本回滾操做

當咱們升級到新的版本後，發現新版本的鏡像有些問題，而不得不返回以前運行的版本，那麼能夠執行下面的操做：

[root@docker01 ~]# docker service update --rollback newnginx   #將newnginx的service回滾到前一個版本
[root@docker01 ~]# docker service ps newnginx   #自行查看

執行回滾命令後，回滾過程以下：

回滾成功後，我這裏就從原來的3.0變回了2.0，雖然在升級3.0的時候，指定的service數量是6個，可是以前只有3個，因此在執行回滾操做後，service數量也將變回3個。

注意：當咱們執行回滾操做的時候，默認是回滾到上一次操做的版本，而且不能夠連續回滾。

———————— 本文至此結束，感謝閱讀 ————————