由于时间匆忙,要是有什么地方没有写对的,请大佬指正,谢谢。文章有点水,大佬勿喷
这篇博客不回去深度的讲解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的