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的