您當前位置：首頁 > php開源 > 綜合技術 > Consul入門04 － Consul集群

Consul入門04 － Consul集群

來源：程序員人生發布時間：2016-06-30 08:45:22 閱讀次數：5784次

Part 1：轉載自：https://segmentfault.com/a/1190000005040904

我們已啟動了我們的第1個代理并且在這個代理上注冊和查詢了服務。這些顯示了使用Consul是多么的容易但是并沒有展現Consul的可擴大性和可用于產品級別的服務發現的基礎設施。在本篇向導中，我們將建立我們第1個多成員的真實的集群。

當1個Consul代理啟動后，它對任何其他的節點都1無所知：它是個單獨的隔離集群。為了讓它感知其他的集群成員，代理必須加入1個現有的集群中去。為了加入1個現有的集群，它只需要知道1個單個的現有成員。它加入后，代理將廣播該成員，并且快速發現集群中的其它成員。1個Consul代理能夠加入任何其它的代理，不單單是那些運行在服務模式下的代理。

啟動代理

為了摹擬1個相對真實的集群，我們將通過Vagrant啟動兩個節點的集群。接下來使用的Vagrantfile可以在Consul倉庫demo中找到。

我們首先啟動兩個節點：

$ vagrant up

1旦該系統可用了，我們就可以通過ssh登錄到該系統，并開始配置我們的集群。我們開始登錄到第1個節點：

$ vagrant ssh n1

在我們之前的例子里，我們使用＊-dev 標志來快速地設置1個開發服務器。不管如何它其實不能用于1個集群的環境下。我們將移除 -dev* 標志，而是替換成指定的用于集群的標志，下面就回觸及該標志。

每一個集群節點都必須有1個唯1的名稱。默許下Consul使用計算機的主機名，不過我們可使用 -node 命令行選項手動地覆蓋它。

我們也能夠指定綁定地址：Consul將在該地址偵聽，并且改地址可以被集群中所有其它的節點訪問到。雖然1個綁定的地址不是1個嚴格需要的（Consul將默許偵聽在系統中第1個私有的IP），不過最好提供1個。1個生產環境下的服務通常有多個網絡接口，所以指定1個綁定地址將保證你不會把Consul綁定到毛病的網絡接口上。

第1個節點現在將作為我們集群中的唯1服務器，我們指定它運行在server模式下。

-bootstrap-expect 標志暗示Consul服務器我們會有其它的服務節點將會加入。這個標志的目的是延遲復制日志的引導直到預期的服務節點成功加入。你可以在引導教程里查閱到更多的信息。

最后，我們增加 config-dir，指定將在哪里可以找到服務和檢查定義。

所有的標志都指定后，將這些設置加入 consul ageng 命令行：

vagrant@n1:~$ consul agent -server -bootstrap-expect 1 \
    -data-dir /tmp/consul -node=agent-one -bind=172.20.20.10 \
    -config-dir /etc/consul.d
...

現在，在另外一終端里，我們連接到第2個節點：

$ vagrant ssh n2

這次，我們設置綁定地址是第2個節點的IP地址。由于該節點將不會是1個Consul的服務器，所以我們不指定它啟動為服務器模式。

所有的標志都指定后，將這些設置加入 consul ageng 命令行：

vagrant@n2:~$ consul agent -data-dir /tmp/consul -node=agent-two \
    -bind=172.20.20.11 -config-dir /etc/consul.d
...

這時候，我們已有了兩個Consul代理在運行：1個服務器和1個客戶端。這兩個Consul代理現在還對彼此沒有任何感知，它們都為兩個單節點的集群。你可以運行 consul members 來驗證它們，每一個集群都僅包括1個成員。

加入集群

現在，我們將告知第1個代理加入第2個代理，在1個新的終端中運行以下命令：

$ vagrant ssh n1
...
vagrant@n1:~$ consul join 172.20.20.11
Successfully joined cluster by contacting 1 nodes.

你應當可以在各自的代理日志中看到1些日志的輸出。如果你仔細的查看，你將會看到有節點加入的日志信息。如果你再次運行consul members，你會看到兩個代理都已感知到了另外一個節點的存在。

vagrant@n2:~$ consul members
Node       Address            Status  Type    Build  Protocol
agent-two  172.20.20.11:8301  alive   client  0.5.0  2
agent-one  172.20.20.10:8301  alive   server  0.5.0  2

記住：為了加入1個集群，1個Consul代理只需要知道1個現有的成員。在加入指定的集群后，各個代理睬相互傳播完全的成員信息。

啟動時自動加入1個集群

理想情況下，不管甚么時候1個新的節點加入了你的數據中心中，它應當自動地加入Consul集群而無需手動操作。為了到達這個目的，你可使用Atlas by HashiCorp并且指定 -atlas-join 標志。下面就是1個配置例子：

$ consul agent -atlas-join \
  -atlas=ATLAS_USERNAME/infrastructure \
  -atlas-token="YOUR_ATLAS_TOKEN"

這需要1個Atlas的用戶名和token，在這里創建帳號，然后在你的Consul配置中使用你認證信息的替換各自的值。現在，不管什么時候1個通過Consul代理啟動的節點加入，它將自動加入你的Consul集群而無需硬編碼任何的配置信息。

另外一個可以選擇的是，你可以在啟動的時候使用 -join 標志或 start_join 指定1個已知Consul代理的地址來加入1個集群。

查詢節點

就像查詢服務1樣，Consul有1個API用戶查詢節點信息。你可以通過DNS或HTTP API來查詢。

對DNS API，名稱結構是 NAME.node.consul 或 NAME.node.DATACENTER.consul。如果數據中心被移除，Consul將僅僅查詢本地數據中心。

例如，從“agent-one”，我們可以查詢節點"agent-two"的地址：

vagrant@n1:~$ dig @127.0.0.1 -p 8600 agent-two.node.consul
...

;; QUESTION SECTION:
;agent-two.node.consul. IN  A

;; ANSWER SECTION:
agent-two.node.consul.  0 IN    A   172.20.20.11

這類查找節點的能力對系統管理任務而言是非常有用的。例如知道了節點的地址，我們可使用ssh登錄到該節點并且可以非常容易地使得該節點成為Consul集群中的1部份并且查詢它。

離開集群

為了離開指定的集群，你可以優雅地退出1個代理（使用 Ctrl-C）或強迫殺死代理進程。優雅地離開可使得節點轉換成離開狀態；其它情況下，其它的節點檢測這個節點將失敗。其不同的地方在這里有詳細的描寫。

下1步

現在有了1個多節點的Consul集群已啟動并且運行著。讓我們通過[健康檢測]()使我們的服務具有更強的魯棒性。

Part 2：根據Part1、Windows安裝Linux虛擬機（CentOS7）及Consul入門01-03，我們使用虛擬機來實現集群（3臺：3臺機器才能滿足基礎的集群，當有1臺主服務退出時，另外兩臺重新選舉新的主服務）。

1、啟動3臺虛擬機,為了方便演示，我這邊使用PUTTY來分別連接這3臺機器，并統1使用root登錄。

2、為了方便演示，我們分別將3臺機器上的web.json中的serviceName重新命名為web、web1、web2（可以1開始的時候就這么命名或使用vi編輯器），并分別在3臺機器上運行consul：

我們先將consul定義為server（服務器模式）：

consul agent -server -bootstrap-expect 1 -data-dir /tmp/consul/ -node=web -bind=192.168.240.129 -config-dir /etc/consul.d/

另外兩臺機器使用以下命令啟動（不將他們定義為服務器模式）：

consul agent -data-dir /tmp/consul/ -node=web1 -bind=192.168.240.130 -config-dir /etc/consul.d/

consul agent -data-dir /tmp/consul/ -node=web2 -bind=192.168.240.131 -config-dir /etc/consul.d/

啟動好以后，我們會發現，非server的兩臺機器web1和web2會時不時的在控制臺輸出信息，這是由于還沒有加入到web的server中，沒有找到集群的主服務，不用擔心，我們繼續看：

3、再打開3個putty客戶端（上下匹配：左上1是web的consul server，左下1是新開的web putty客戶端），并分別在里面運行consul members查看集群內成員，此時只能分別查看到本機的信息，type分別為server和client：

4、加入集群：

1個consul agent就是1個獨立的程序。1個長時間運行的守護進程，運行在concul集群中的每一個節點上。
啟動1個consul agent ，只是啟動1個孤立的node，如果想知道集群中的其他節點，應當將consul agent加入到集群中去 cluster。
agent有兩種模式：server與client。server模式包括了1致性的工作：保證1致性和可用性（在部份失敗的情況下），響應RPC，同步數據到其他節點代理。
client 模式用于與server進行通訊，轉發RPC到服務的代理agent，它僅保存本身的少許1些狀態，是非常輕量化的東西。本身是相對無狀態的。
agent除去設置server/client模式、數據路徑以外，還最好設置node的名稱和ip。

在web1和web2的client機器上，使用consul join IP加入consul server，我這里是這樣的：

consul join 192.168.240.129

5、加入集群后，再次使用consul members 我們發現，集群中的機器已可以相互發現了。1個server，其它是client：

Part 3：Server之間的leader自動選舉功能：這次我們需要4臺機器，其中web、web1、web2都定義為server，1臺client。（虛擬機安裝及基本配置請看：Windows安裝Linux虛擬機（CentOS7）及Consul入門01-03）

1開始學習consul，我們需要讓consul 運行起來。consul server推薦最少在3~5個之間，推薦的方法是1開始啟動其中1臺server，并且配置到bootstrap的模式，該模式node可以指定自己作為leader，而不用進行選舉。然后再順次啟動其他server，配置為非bootstrap的模式。最后把第1個serverbootstrap模式停止，重新以非bootstrap模式啟動，這樣server之間就能夠自動選舉leader。

web：

consul agent -server -bootstrap -data-dir /tmp/consul -node=web

web1、web2：用以下命令啟動consul，不需要帶bootstrap 選項：

consul agent -server -data-dir /tmp/consul -node=web1 consul agent -server -data-dir /tmp/consul -node=web2

PS：3臺server都啟動以后，會發現web1和web2在控制臺也會有消息更新，提示NO cluster leader，說明沒法選舉leader，分別查看各自的集群信息時，也是沒法相互查看的。

web1、web2需要加入到web的集群中：consul join 192.168.240.129：

當3臺server都加入到集群，我們需要配置這3臺機子為同等的server，并且讓它們自己選擇leader，這時候可以停止第1臺(web)的consul，然后運行以下命令：

consul agent -server -data-dir /tmp/consul -node=web

consul join 192.168.240.130

PS:此時，我們在每臺機子上輸入consul info，我們會發現此時的leader是web2；我們并沒有指定，是集群自己選擇的：

這時候，我們摹擬異常或服務器退出，將web2關閉，這時候我們再次輸入consul info會發現，web和web1自動選舉了web作為leader：

最后，將client機器連入集群，就是1個小型的完全集群了。

參考文章：http://www.cnblogs.com/yatingyang/p/4495098.html

Part 4：已組建過的集群服務器，在退出集群以后，將沒法加入之前的cluster中，而是照舊如第1次啟動那樣，看不到peers。

參考地址：http://tonybai.com/2015/07/06/implement-distributed-services-registery-and-discovery-by-consul/?utm_source=tuicool&utm_medium=referral

問題描寫：我這邊由于電腦重啟了，所以集群就都退出了，但是依照上面的步驟，沒法重新組建集群，沒法選出leader，通過info命令看，兩個節點都變成了Follower，集群依然處于無leader狀態。

問題解釋：這個問題在consul的github repository issues中被對人次提及，但作者似乎不將此作為bug。產生這個問題的緣由是當server退出時，consul會將/tmp/consul/raft/peers.json的內容由["192.168.240.129:8300","192.168.240.130:8300","192.168.240.131:8300"]=====改成=====》》》》null.當server重啟后，該文件并未改變，照舊為null，所以沒法重新弄自動join到cluster中，也就沒法選取leader了。

問題解決：打開對應的serve中/tmp/consul/raft/peers.json文件，將內容統1修改成["192.168.240.129:8300","192.168.240.130:8300","192.168.240.131:8300"]，然后重啟，使用-rejoin命令加入集群或重復Part3中的步驟便可。