Consul入門04 － Consul集羣

咱們已經啓動了咱們的第一個代理而且在這個代理上註冊和查詢了服務。這些顯示了使用Consul是多麼的容易可是並無展現Consul的可擴展性以及可用於產品級別的服務發現的基礎設施。在本篇嚮導中，咱們將創建咱們第一個多成員的真實的集羣。

當一個Consul代理啓動後，它對任何其餘的節點都一無所知：它是個單獨的隔離集羣。爲了讓它感知其餘的集羣成員，代理必須加入一個現有的集羣中去。爲了加入一個現有的集羣，它只須要知道一個單個的現有成員。它加入後，代理將廣播該成員，而且快速發現集羣中的其它成員。一個Consul代理可以加入任何其它的代理，不只僅是那些運行在服務模式下的代理。

啓動代理

爲了模擬一個相對真實的集羣，咱們將經過Vagrant啓動兩個節點的集羣。接下來使用的Vagrantfile能夠在Consul倉庫demo中找到。

咱們首先啓動兩個節點：

$ vagrant up

一旦該系統可用了，咱們就能經過ssh登陸到該系統，並開始配置咱們的集羣。咱們開始登陸到第一個節點：

$ vagrant ssh n1

在咱們之前的例子裏，咱們使用 ＊-dev 標誌來快速地設置一個開發服務器。不管如何它並不能用於一個集羣的環境下。咱們將移除 -dev* 標誌，而是替換成指定的用於集羣的標誌，下面就回涉及該標誌。

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

咱們也能夠指定 綁定地址：Consul將在該地址偵聽，而且改地址能夠被集羣中全部其它的節點訪問到。雖然一個 綁定 的地址不是一個嚴格須要的（Consul將默認偵聽在系統中第一個私有的IP），不過最好提供一個。一個生產環境下的服務一般有多個網絡接口，因此指定一個 綁定 地址將保證你不會把Consul綁定到錯誤的網絡接口上。

第一個節點如今將做爲咱們集羣中的惟一服務器，咱們指定它運行在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
...

如今，在另外一終端裏，咱們鏈接到第二個節點：

$ vagrant ssh n2

此次，咱們設置 綁定地址 是第二個節點的IP地址。由於該節點將不會是一個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代理在運行：一個服務器和一個客戶端。這兩個Consul代理如今還對彼此沒有任何感知，它們都爲兩個單節點的集羣。你能夠運行 consul members 來驗證它們，每一個集羣都僅包含一個成員。

加入集羣

如今，咱們將告知第一個代理加入第二個代理，在一個新的終端中運行下列命令：

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

你應該能夠在各自的代理日誌中看到一些日誌的輸出。若是你仔細的查看，你將會看到有節點加入的日誌信息。若是你再次運行 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

記住：爲了加入一個集羣，一個Consul代理只須要知道一個現有的成員。在加入指定的集羣后，各個代理會互相傳播完整的成員信息。

啓動時自動加入一個集羣

理想狀況下，不管何時一個新的節點加入了你的數據中心中，它應該自動地加入Consul集羣而無需手動操做。爲了達到這個目的，你可使用Atlas by HashiCorp而且指定 -atlas-join 標誌。下面就是一個配置例子：

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

這須要一個Atlas的用戶名和token，在這裏建立賬號，而後在你的Consul配置中使用你認證信息的替換各自的值。如今，不管什麼時候一個經過Consul代理啓動的節點加入，它將自動加入你的Consul集羣而無需硬編碼任何的配置信息。

另外一個能夠選擇的是，你能夠在啓動的時候使用 -join 標誌或者 start_join 指定一個已知Consul代理的地址來加入一個集羣。

查詢節點

就像查詢服務同樣，Consul有一個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集羣中的一部分而且查詢它。

離開集羣

爲了離開指定的集羣，你能夠優雅地退出一個代理（使用 Ctrl-C）或者強制殺死代理進程。優雅地離開可使得節點轉換成離開狀態；其它狀況下，其它的節點檢測這個節點將失敗。其不一樣的地方在這裏有詳細的描述。

下一步

如今有了一個多節點的Consul集羣已經啓動而且運行着。讓咱們經過[健康檢測]()使咱們的服務具備更強的魯棒性。

翻譯自這裏