运维小姐姐说这篇Consul集群和ACL配置超给力(保姆级)

转自博客：https://www.cnblogs.com/zoe-zyq/p/14580552.html

前言

上一篇简单介绍了Consul，并使用开发模式（dev）进行流程演示，但在实际开发中需要考虑Consul的高可用和操作安全性，所以接着来聊聊集群和ACL的相关配置，涉及到的命令会在环境搭建过程中详细介绍。

正文

关于集群，第一反应就是多搞几台机器(或者容器等)，将其关联在一块，提供功能即可；在搭建集群环境之前，需要对几个角色进行熟悉，因为在Consul中，它们至关重要。见下图(以一个数据中心为例)：

• 数据中心(DataCenter)：Consul运行的节点集连接在一起称为数据中心；在数据中心中，各个Consul节点可以以服务器(Server)或客户端模式(Client)运行；为了保证可用性和高性能，通常一个数据中心内推荐3~5个服务器(不超过5个)，客户端个数建议不要超过5000个(具体根据业务决定)。
• 客户端模式(Client)：客户端负责注册服务、运行健康检查并将相关RPC转发给服务器，相对来说是无状态的。Client+LAN gossip协议组成了一个数据中心中的节点集，通信效率高。
• 服务器模式(Server)：服务器包含客户端的功能，每个Server还参与选举，响应RPC查询，转发信息给ServerLeader等；另外还负责维护Consul的集群状态(持久化)：包括其他服务器和客户端的信息、哪些服务可供发现、哪些服务允许相互通信；每个Consul数据中心必须至少有一个服务器。
• 服务器领导者(Server Leader)：除了包含Server的功能外，还负责同步数据到各个Server；每一个集群中只能有一个ServerLeader，保证集群内数据一致。

在整个集群中是通过网络进行关联，需要多个端口实现对应功能，如上图；端口简介：

了解到Consul的架构及各个角色功能，接下来就是实操啦。

1. 搭建集群

在这里，就不搞那么多机器了，两台搭集群，一台服务器模式，一台客户端模式(电脑有限，不想搞那么多虚拟机)，原理是一样的，主要还是着重说说过程：

1.1 启动一个Server(就一台Server,那它肯定是Leader了)

这里演示在启动节点前，将配置文件目录和data创建好，如下：

使用命令启动：

consul agent -server -bootstrap-expect 1 -datacenter=dc_zoe -config-dir=./config -data-dir ./data -node=s1 -ui -rejoin -bind=192.168.1.6 -client 0.0.0.0

启动起来时包含一些节点信息，如下：

命令解析

• agent：Consul的核心进程，每个节点都需要代理的形式运行；
• -server：代表是Server模式，如果没有-server就代表是Client模式；
• -bootstrap-expect：在一个数据中心中期望的Server的节点个数，直到启动Server个数达到设置的个数时，集群才能起作用，并从中选举出一个ServerLeader;
• -bootstrap：手动指定Server为Leader；当Server个数大于0时，该参数不能和-bootstrap-expect一起使用(以上命令中没有用到)；
• -datacenter：指定数据中心的名称；
• -config-dir：指定配置文件目录，这里指定的是当前目录下的config目录，Consul会自动加载里面所有Json格式的配置文件(.json结尾)；
• -data-dir：指定节点运行时数据状态保存的路径，这里将其对应的数据保存在当前文件夹下的data目录中；
• -node：指定节点的名称，在集群中必须是唯一的，默认是主机名；
• -ui：使用默认UI界面，Consul提供一个UI项目，下载可以指定对应的目录，使用-ui-dir 指定对应的UI目录即可；
• -rejoin：忽略之前的断开，重新启动时会尝试加入集群；
• -bind：指定绑定的地址，该地址通常用来在集群内部通讯，集群内的所有节点地址都必须正常通讯；
• -client：Consul服务监听的地址，这个地址提供HTTP/DNS/RPC等服务，默认是127.0.0.1，所以外部不能访问，UI通过IP地址也不能访问；如果需要提供服务，将其指定为0.0.0.0即可。
• -encrypt：指定一个秘钥，在通讯时进行加密，这个秘钥可以通过consul keygen生成，在同一个集群中，各节点必须使用相同的秘钥；

以上列举常用的参数，还有一些不太常用的，小伙伴如果用到去官网上查查(偷偷告诉小伙伴，参数还可以统一放在配置文件中哦)。

如果是多个Server，只需在每台机器上执行以上命令即可，根据Server数量，修改bootstrap-expect后面的数量即可，然后再改改bind后面的地址即可。

1.2 启动一个Client

启动一个Client和Server几乎一样，只是不用指定Server参数，默认就是客户端模式，命令如下：

consul agent -datacenter=dc_zoe -config-dir=./config -data-dir ./data -node=c1 -bind=192.168.1.8 -client 0.0.0.0

这样Client 就启动起来了

如果是多个Client，在各台机器上执行以上命令即可，只是改改bind的地址即可。

1.3 将节点加入到集群中

上面只是将各节点启动，如果是Server节点，不是Leader的话，会一直提示找不到Leader；如果是Client节点，就会提示找不到对应的Server节点；因为一个集群中至少得有一个Server，在Server中必须得要有且只有一个ServerLeader。所以节点启动之后，下一步就是要将各节点加入到集群中，通常的做法是在各个节点上执行以下命令：

consul join 192.168.1.6 # 通常后面跟的地址是ServerLeader的地址

执行命令之后，对应的节点就加入到集群中了，可以通过UI看到节点：

也可以通过命令查看：

最终这样一个简单集群就搭建完成了，流程就是这样，其余的就是节点个数的问题。

2. ACL配置

Consul使用 Access Control Lists（ACL-访问控制列表）来保护对UI、API、CLI、服务通信和代理通信的访问；ACL的核心是将规则分组为策略，然后将一个或多个策略与令牌相关联。

Consul使用token的形式进行安全控制访问，这里的token就是随机的字符串，有了token就有对应的操作权限啦；就好比之前说到WebAPI接口加访问控制一样，通过一个授权token就可以访问相关的接口资源。

配置ACL的前提是所有节点都需要将ACL启用，然后还要一个bootstrap token，因为针对子权限(策略)生成token的时候需要用到，就好比MySQL中的root用户一样，只有有了root权限才能给其他用户分配更多的权限。接下就以UI的访问和Services的控制进行ACL配置演示，其他基本上都一样，重点就是规划好策略规则。

首先在各节点启动时将ACL启用，在配置文件夹目录中(这里目录名是config)增加acl.hcl文件(每个节点都需要加)，内容如下：

acl = {
  enabled = true
  default_policy = "deny"
  enable_token_persistence = true 
}

参数说明：

• enabled=true 代表开启ACL；
• default_policy=“deny”默认为allow，如果需要自定义权限，需要将其设置为deny；
• enable_token_persistence =true开启token持久化，将token持久化到磁盘上；

这里需要注意一点，之前说配置目录下的Json文件会被自动加载，其实还有hcl文件也会被自动加载，这里用hcl的形式演示一下。 配置文件准备好之后，重新启动节点即可(集群中的所有节点都需要用上)，访问UI试试，就会弹出如下界面：

点击登录，需要输入一个Token，如果是在配置文件中配置，输入配置的token即可，如果没有配置，可以在运行时生成一个bootstrap token，在任意一个Server中执行consul acl bootstrap命令获得该bootstrap token；Consul中token都很重要，需要保存好。

将生成的bootstrap token输入在登录框中，然后就可以正常获取信息啦；

bootstrap token权限很大，不可能每个小伙伴都拥有，就像MySQL的root权限一样，只能有个别的人知道。其他用户的权限需单独控制；Consul也是如此，针对不同权限策略，生成对应的token，使用这个token就只能访问或操作对应权限范围内的资源。

UI方式配置

ACL的配置其他token可以通过命令的形式，也可以通过UI界面的形式(因为现在有bootstrap token超级权限)，这里通过UI的形式很方便的，三步走：

• 创建策略：

  

  策略其他信息基本上没啥说的，主要是规则(Rules)的配置，通常主要针对节点(node)、服务(service)、键值对(K/V)进行配置，可以模糊指定，也可以具体指定，如下：

  node_prefix ""：节点前缀为空，代表所有的节点都使用策略；

  service_prefix ""：服务前缀为空，代表所有的服务都使用策略；

  service "Code6688Name"：指定对应的服务使用策略；

  key_prefix "redis/"：只对前缀有"redis/"的key使用对应策略；

  key "dashboard-app"：指定对应的key使用策略；

  以上指定策略的范围是比较常用的方式，具体可以参照官网；

  规则中关于策略(policy)通常有以下几种：

  read：只能查询；

  write：可查可写；

  deny：不能读不能写；

  其他细节可以参考ACL官方配置文档。

• 根据策略生成token:

  有了策略之后，接下来就要针对策略生成对应的token啦，如下：

  

  在对应弹出框中输入对应的信息即可，如下：

  

  保存之后就生成对应的token，可以进入到详细页看到生成的token，直接将token给别人用即可。

  

• 使用token：

  ui测试，直接将token发给其他小伙伴，登录时输入即可,如果是其他操作，带上token即可；对于自己界面测试，切换一下token就可以啦，如下：

  

  切换之后，界面中除了node能查出信息，其他都不能使用，操作Key/Value，还报如下错误：

  

  在服务注册或服务发现中使用该token，也不能注册和查询服务成功，如下：

  

  如果是用配置文件进行服务注册，在配置文件中也要指定token，否则注册服务不成功，如下：

  

  服务发现也是一个道理：

  

  直接使用HTTP API也是一样需要带上token：

  

  命令方式

UI配置的这种形式是不是够直接，命令的方式我就不演示的了吧，步骤的一样，只是全靠命令即可，如下：

• 编写规则文件；

  

• 根据规则文件生成策略；

  

• 根据策略生成token;

  

• 使用token；

  有了token就可以能干对应权限范围的事了，具体使用就不介绍了，不管是UI、还是API查询，小伙伴自己体验一下吧（上面已经说到）。

注： 以上步骤中开启ACL之后，没有统一配置好超级管理员的boostrap token，所以每次操作都需要带上-token参数。

总结

集群再加ACL访问控制配置就先说到这啦，文中更主要的是提供相关思路，并没有把所有权限配置方式举例演示(比较多)，剩下小伙伴自己尝试吧；通过上一篇(来，Consul 服务发现入个门(一看就会的那种))的使用，再加上这篇的集群环境和ACL配置思路介绍，小伙伴应该日常使用没问题了吧；其余的功能根据业务需要再去研究吧，我如果有对应的应用场景，依然会第一时间分享。下期聊聊网关吧~~~