consul集羣搭建以及ACL配置

因爲時間匆忙，要是有什麼地方沒有寫對的，請大佬指正，謝謝。文章有點水，大佬勿噴
這篇博客不回去深度的講解consul中的一些知識，主要分享的我在使用的時候的一些操做和碰見的問題以及解決辦法。固然有些東西官方文檔上面也是有的

學習一種工具最好的方式仍是去看官方文檔，這是血與淚的經驗教訓。

1.consul集羣的搭建

consul是google開源的一個使用go語言開發的服務發現、配置管理中心服務。內置了服務註冊與發現框 架、分佈一致性協議實現、健康檢查、Key/Value存儲、多數據中心方案，再也不須要依賴其餘工具（好比ZooKeeper等）。固然與consul相似的工具還有不少幾個：ZooKeeper， etcd

這裏在講解以前，咱們須要知道的一些基本的東西，這裏引用別人的文章，
@client

CLIENT表示consul的client模式，就是客戶端模式。是consul節點的一種模式，這種模式下，全部註冊到當前節點的服務會被轉發到SERVER，自己是不持久化這些信息。

@server

SERVER表示consul的server模式，代表這個consul是個server，這種模式下，功能和CLIENT都同樣，惟一不一樣的是，它會把全部的信息持久化的本地，這樣遇到故障，信息是能夠被保留的。

@server-leader

中間那個SERVER下面有LEADER的字眼，代表這個SERVER是它們的老大，它和其它SERVER不同的一點是，它須要負責同步註冊的信息給其它的SERVER，同時也要負責各個節點的健康監測。

@raft

server節點之間的數據一致性保證，一致性協議使用的是raft，而zookeeper用的paxos，etcd採用的也是taft。

@服務發現協議

consul採用http和dns協議，etcd只支持http

@服務註冊

consul支持兩種方式實現服務註冊，一種是經過consul的服務註冊http API，由服務本身調用API實現註冊，另外一種方式是經過json個是的配置文件實現註冊，將須要註冊的服務以json格式的配置文件給出。consul官方建議使用第二種方式。

@服務發現

consul支持兩種方式實現服務發現，一種是經過http API來查詢有哪些服務，另一種是經過consul agent 自帶的DNS（8600端口），域名是以NAME.service.consul的形式給出，NAME即在定義的服務配置文件中，服務的名稱。DNS方式能夠經過check的方式檢查服務。

@服務間的通訊協議

Consul使用gossip協議管理成員關係、廣播消息到整個集羣，他有兩個gossip pool（LAN pool和WAN pool），LAN pool是同一個數據中心內部通訊的，WAN pool是多個數據中心通訊的，LAN pool有多個，WAN pool只有一個。

簡單來講就是：client至關於咱們平時說的LB,負責將請求轉發到Server,Server中有一個leader,負責Server集羣的同步和監測，這個server-leader在不指定的狀況下回隨機推舉出一個，固然也能夠手動指定。這個在ACL配置的時候須要保證Server-leader是同一個。

2.集羣搭建

首先咱們從https://releases.hashicorp.co...，這裏咱們最好選擇下載0.9.1或者更高的版本，由於他們能支持API操做。
咱們如今有3臺服務器，內網IP是 192.168.0.3 192.168.0.4 192.168.0.6
個人計劃是指定Server爲：192.168.0.4 192.168.0.3
指定Clinet: 192.168.0.6

如今完成以後，將文件解壓，會看獲得一個可執行文件consul,

移動到/user/local/bin下面（固然也能夠不用，主要是爲了方便操做嘛）。

咱們也能夠經過配置配置文件實現consul的啓動，[詳情請看][4]

192.168.0.3: consul agent -server -bootstrap-expect=2 -data-dir=/data/consul -node=node0 -bind=192.168.0.3 -dc=dc1 -config-dir=/data/consul.d

192.168.0.4: consul agent -server -bootstrap-expect=2 -data-dir=/data/consul -node=node1 -bind=192.168.0.4 -dc=dc1 -config-dir=/data/consul.d

192.168.0.6: consul agent -data-dir=/data/consul -node=node3 -bind=192.168.0.6 -client=192.168.0.6 -dc=dc1 -ui -config-dir=/data/consul.d

consul必須啓動agent才能使用，有兩種啓動模式server和client，還有一個官方自帶的ui。server用與持久化服務信息，集羣官方建議3或5個節點。client只用與於server交互。ui能夠查看集羣狀況的。

這裏解釋一下這裏個參數
-server 表示當前使用的server模式
-node：指定當前節點在集羣中的名稱
-config-dir：指定配置文件，定義服務的，默認全部一.json結尾的文件都會讀
-datacenter: 數據中心沒名稱，不設置的話默認爲dc
-client : 客戶端模式
ui 使用consul自帶的ui界面
-data-dir consul存儲數據的目錄

-bootstrap：用來控制一個server是否在bootstrap模式，在一個datacenter中只能有一個server處於bootstrap模式，當一個server處於bootstrap模式時，能夠本身選舉爲raft leader。
-bootstrap-expect：在一個datacenter中指望提供的server節點數目，當該值提供的時候，consul一直等到達到指定sever數目的時候纔會引導整個集羣，該標記不能和bootstrap公用

這兩個參數十分重要， 二選一，若是兩個參數不使用的話，會出現就算你使用join將agent加入了集羣仍然會報 2018/10/14 15:40:00 [ERR] agent: failed to sync remote state: No cluster leader

當輸入以後，三臺服務器上的consul啓動，可是目前這還不是一個集羣，而且你會看到consul會輸出大量爆錯

192.168.0.3：

192.168.0.4：

192.168.0.6：

報錯提示顯而易見，3,4中的報錯表示沒有leader,6中沒有server

雖然咱們開啓的consul,可是咱們並無把這裏個服務加入集羣裏面，，這個時候咱們使用-join參數，將啓動的服務加入到集羣之中

192.168.0.3：  consul join 192.168.0.4

192.168.0.3： consul join 192.168.0.6

這時候在192.168.0.3：

192.168.0.4：

192.168.0.6：

沒有出現報錯，並選出了leader node0也就是192.168.0.3所在的server

這裏須要說明的是 -bootstrap-expect參數，當加入的server數量達到了-bootstrap-expect所設置的數量，纔會發生選舉，推選出leader

這個時候咱們的consul服務就已經搭建完成了，咱們UI訪問client:192.168.0.6

2.ACL的開啓和配置

ACL的開啓和配置仍是建議去看官網，不推薦直接去看別人的其餘的博客，這是血與淚的教訓，固然，在看完官網的以後，能夠是看看這篇

這裏爲了簡單起見，我使用一個server:192.168.0.3和一個client:192.168.0.6,配置方法請看上面，注意-bootstrap着快參數的配置

首先咱們須要知道幾個概念，就是他的哪幾個token

簡單來講，就是
alc_master_token > acl_token， acl_master_token有最高權限。acl_token是默認的權限，用於當一些沒有帶token的請求想要請求consul獲取數據的時候所給的權限
acl_agent_master_token > acl_agent_token 這個是用於Client域Server交互的時候一些令牌

首先咱們在server上配置的 config_dir所配置的文件夾下面添加 acl.json文件

{
      "acl_datacenter": "dc1", //須要acl配置的數據中心
      "acl_master_token": "b1gs3113cr3t",  //這個是隨機生成的
      "acl_default_policy": "deny",  //默認策略全部的都禁止
      "acl_down_policy": "extend-cache"
     }
     
 從新啓動server

這時候咱們會看到：

server上：

client上：

Ui界面：

說明當前ACl配置以及成功了

咱們查當作員：

由於如今訪問都須要使用token 因此請求應該是

如今咱們來處理Cline和Server中的報錯，經過配置acl_agent_master_token 隨便在server或者Client其中一臺機器上請求，
這裏Name，Rules中你能夠更具你的須要進行配置。

curl \
    --request PUT \
    --header "X-Consul-Token: b1gs3113cr3t" \
    --data \
'{
  "Name": "Agent Token",
  "Type": "client",
  "Rules": "node \"\" { policy = \"write\" } service \"\" { policy = \"read\" }"
}' http://127.0.0.1:8500/v1/acl/create

會生成一個Token

將這個token手動配置到CLient和Server上（固然也可使用Api）
Client:

{
"acl_agent_token": "4ac10325-551b-5465-05e0-e0a48a04971a",
  "acl_datacenter": "dc1",
  "acl_down_policy": "extend-cache"

}

Server：

{
          "acl_datacenter": "dc1",
          "acl_master_token": "b1gs3113cr3t",
          "acl_default_policy": "deny",
          "acl_down_policy": "extend-cache",
 "acl_agent_token": "4ac10325-551b-5465-05e0-e0a48a04971a"
 }

而後重啓Server和Client,重啓Client以後記得要從新吧Client加入到集羣中哦。

要是有報錯的話。。。。。。。。。重裝系統能解決你百分之80的問題。

要是沒有報錯的話，好了到如今咱們的ACL已經配置成功了，並且咱們如今也有了一個Token，那就是 "acl_master_token": "b1gs3113cr3t",咱們把這個Token加入到UI的

完成。

接着咱們能夠更具咱們的需求進行配置了，方法很簡單，1是經過API，二是經過UI界面

3.多臺Server配置ACL

方式1：

每臺新接入的Server配置.json配置文件

{
"acl_agent_token": "4ac10325-551b-5465-05e0-e0a48a04971a",
  "acl_datacenter": "dc1",
  "acl_down_policy": "extend-cache"

}

這種配置形式要求咱們必須每次選舉都出來的Leader都是相同的，而且配置文件中帶有acl_master_token的

方式2：

每臺新接入的Server配置.json配置文件

{

          "acl_datacenter": "dc1",
          "acl_master_token": "b1gs3113cr3t",
          "acl_default_policy": "deny",
          "acl_down_policy": "extend-cache",
 "acl_agent_token": "4ac10325-551b-5465-05e0-e0a48a04971a"

}

這種形式就沒必要考慮要定死每次選舉出來的leader了

這個其實我不是很肯定那種必定正確，可是這兩種配置方式都是OK的