consul知识梳理与环境搭建
一、 什么是consul
consul的基本介绍
在分布式架构中，服务治理是一个重要的问题。在没有服务治理的分布式集群中，各个服务之间通过手工或者配置的方式进行服务关系管理，遇到服务关系变化或者增加服务的时候，人肉配置极其麻烦且容易出错。之前在一个C/C++项目中，采用ZooKeeper进行服务治理，可以很好的维护服务之间的关系，但是使用起来较为麻烦。现在越来越多新的项目采用consul进行服务治理，各方面的评价都优于ZooKeeper，经过几天的研究，这里做一个总结。
zookeeper和consul比较
• 开发语言方面，zookeeper采用java开发，安装的时候需要部署java环境；consul采用golang开发，所有依赖都编译到了可执行程序中，即插即用。
• 部署方面，zookeeper一般部署奇数个节点方便做简单多数的选举机制。consul部署的时候分server节点和client节点（通过不同的启动参数区分），server节点做leader选举和数据一致性维护，client节点部署在服务机器上，作为服务程序访问consul的接口。
• 一致性协议方面，zookeeper使用自定义的zab协议，consul的一致性协议采用更流行的Raft。
• zookeeper不支持多数据中心，consul可以跨机房支持多数据中心部署，有效避免了单数据中心故障不能访问的情况。
• 链接方式上，zookeeper client api和服务器保持长连接，需要服务程序自行管理和维护链接有效性，服务程序注册回调函数处理zookeeper事件，并自己维护在zookeeper上建立的目录结构有效性（如临时节点维护）；consul 采用DNS或者http获取服务信息，没有主动通知，需要自己轮训获取。
• 工具方面，zookeeper自带一个cli_mt工具，可以通过命令行登录zookeeper服务器，手动管理目录结构。consul自带一个Web UI管理系统， 可以通过参数启动并在浏览器中直接查看信息。
Consul是一个用来实现分布式系统的服务发现与配置的开源工具。他主要由多个组成部分：
• 服务发现：客户端通过Consul提供服务，类似于API,MySQL,或者其他客户端可以使用Consul发现服务的提供者。使用类似DNS或者HTTP，应用程序和可以很轻松的发现他们依赖的服务。
• 检查健康：Consul客户端可以提供与给定服务相关的健康检查（Web服务器返回200 ok）或者本地节点（“内存利用率低于90%”）。这些信息可以监控集群的运行情况，并且使访问远离不健康的主机组件。
• 键值对存储：应用程序可以使用Cousul的层级键值对。
• 多数据中心：Consul有开箱及用的多数据中心。
Consul 的角色
client: 客户端, 无状态, 将 HTTP 和 DNS 接口请求转发给局域网内的服务端集群.
server: 服务端, 保存配置信息, 高可用集群, 在局域网内与本地客户端通讯, 通过广域网与其他数据中心通讯. 每个数据中心的 server 数量推荐为 3 个或是 5 个.
agent
组成 consul 集群的每个成员上都要运行一个 agent，可以通过 consul agent 命令来启动。agent 可以运行在 server 状态或者 client 状态。自然的，运行在 server 状态的节点被称为 server 节点；运行在 client 状态的节点被称为 client 节点。
client 节点
负责转发所有的 RPC 到 server 节点。本身无状态，且轻量级，因此，可以部署大量的 client 节点。
server 节点
负责组成 cluster 的复杂工作（选举、状态维护、转发请求到 lead），以及 consul 提供的服务（响应 RCP 请求）。考虑到容错和收敛，一般部署 3 ~ 5 个比较合适。
Consul内幕
术语
• 代理(agent)：代理是Consul集群上每个成员的守护进程，它是由consul agent开始运行。代理能够以客户端或服务器模式运行。由于所有节点都必须运行代理，所以将节点引用为客户端或服务器更为简单，但还有其他实例的代理。所有代理可以运行DNS或HTTP接口，并负责运行检查和保持服务同步。
• 客户端：客户端可以将所有RPC请求转发到服务器的代理。客户端是相对无状态的。客户端执行的唯一后台活动是LANgossip池。它消耗最小的资源开销和少量的网络带宽。
• 服务器端：服务器端是具有扩展的功能的代理，它主要参与维护集群状态，响应RPC查询，与其他数据中心交换WAN gossip ，以及向上级或远程数据中心转发查询。
• 数据中心：虽然数据中心的定义似乎很明显，但仍有一些细微的细节必须考虑。我们将一个数据中心定义为一个私有、低延迟和高带宽的网络环境。这不包括通过公共互联网的通信，但是为了我们的目的，单个EC2区域内的多个可用区域将被视为单个数据中心的一部分
• Gossip：consul是建立在serf之上的，它提供了一个完整的gossip协议，用在很多地方。Serf提供了成员，故障检测和事件广播。Gossip的节点到节点之间的通信使用了UDP协议。
• LAN Gossip：指在同一局域网或数据中心的节点上的LAN Gossip池。
• WAN Gossip：指包含服务器的WAN Gossip池，这些服务器在不同的数据中心，通过网络进行通信。
• 一致性协议采用 Raft 算法,用来保证服务的高可用.
• 成员管理和消息广播 采用GOSSIP协议，支持ACL访问控制。
ACL技术在路由器中被广泛采用，它是一种基于包过滤的流控制技术。控制列表通过把源地址、目的地址及端口号作为数据包检查的基本元素，并可以规定符合条件的数据包是否允许通过。
gossip就是p2p协议。他主要要做的事情是，去中心化。
这个协议就是模拟人类中传播谣言的行为而来。首先要传播谣言就要有种子节点。种子节点每秒都会随机向其他节点发送自己所拥有的节点列表，以及需要传播的消息。任何新加入的节点，就在这种传播方式下很快地被全网所知道。
什么是服务注册？
一个服务将其位置信息在“中心注册节点”注册的过程。该服务一般会将它的主机IP地址以及端口号进行注册，有时也会有服务访问的认证信息，使用协议，版本号，以及关于环境的一些细节信息。
什么是服务发现？
服务发现可以让一个应用或者组件发现其运行环境以及其它应用或组件的信息。用户配置一个服务发现工具就可以将实际容器跟运行配置分离开。常见配置信息包括：ip、端口号、名称等。
当一项服务存在于多个主机节点上时，client端如何决策获取相应正确的IP和port。
在传统情况下，当出现服务存在于多个主机节点上时，都会使用静态配置的方法来实现服务信息的注册。
而当在一个复杂的系统里，需要较强的可扩展性时，服务被频繁替换时，为避免服务中断，动态的服务注册和发现就很重要。
图中，客户端的一个接口，需要调用服务A-N。客户端必须要知道所有服务的网络位置的，以往的做法是配置是配置文件中，或者有些配置在数据库中。这里就带出几个问题：
• 需要配置N个服务的网络位置，加大配置的复杂性
• 服务的网络位置变化，都需要改变每个调用者的配置
• 集群的情况下，难以做负载（反向代理的方式除外）
总结起来一句话：服务多了，配置很麻烦，问题多多
既然有这些问题，那么服务发现就是解决这些问题的。话说，怎么解决呢？我们再看一张图
与之前一张不同的是，加了个服务发现模块。图比较简单，这边文字描述下。服务A-N把当前自己的网络位置注册到服务发现模块（这里注册的意思就是告诉），服务发现就以K-V的方式记录下，K一般是服务名，V就是IP:PORT。服务发现模块定时的轮询查看这些服务能不能访问的了（这就是健康检查）。客户端在调用服务A-N的时候，就跑去服务发现模块问下它们的网络位置，然后再调用它们的服务。这样的方式是不是就可以解决上面的问题了呢？客户端完全不需要记录这些服务网络位置，客户端和服务端完全解耦！
这个过程大体是这样，当然服务发现模块没这么简单。里面包含的东西还很多。这样表述只是方便理解。
图中的服务发现模块基本上就是微服务架构中服务发现的作用了。
consul 简介
做服务发现的框架常用的有
• zookeeper
• eureka
• etcd
• consul
这里就不比较哪个好哪个差了，需要的童鞋自己谷歌百度。
那么consul是啥？consul就是提供服务发现的工具。然后下面是简单的介绍：
consul是分布式的、高可用、横向扩展的。consul提供的一些关键特性：
• service discovery：consul通过DNS或者HTTP接口使服务注册和服务发现变的很容易，一些外部服务，例如saas提供的也可以一样注册。
• health checking：健康检测使consul可以快速的告警在集群中的操作。和服务发现的集成，可以防止服务转发到故障的服务上面。
• key/value storage：一个用来存储动态配置的系统。提供简单的HTTP接口，可以在任何地方操作。
• multi-datacenter：无需复杂的配置，即可支持任意数量的区域。
我们这里会介绍服务发现，健康检查，还有一些基本KV存储。多数据中心有机会另一篇文章再说。
总结：只要知道它是解决我上一部分提出的问题就行，其它的东西慢慢理解
consul的几个概念
上图是我从consul官方文档抠出来的。
我们只看数据中心1，可以看出consul的集群是由N个SERVER，加上M个CLIENT组成的。而不管是SERVER还是CLIENT，都是consul的一个节点，所有的服务都可以注册到这些节点上，正是通过这些节点实现服务注册信息的共享。除了这两个，还有一些小细节，一一简单介绍。
• CLIENT
CLIENT表示consul的client模式，就是客户端模式。是consul节点的一种模式，这种模式下，所有注册到当前节点的服务会被转发到SERVER，本身是不持久化这些信息。
• SERVER
SERVER表示consul的server模式，表明这个consul是个server，这种模式下，功能和CLIENT都一样，唯一不同的是，它会把所有的信息持久化的本地，这样遇到故障，信息是可以被保留的。
• SERVER-LEADER
中间那个SERVER下面有LEADER的字眼，表明这个SERVER是它们的老大，它和其它SERVER不一样的一点是，它需要负责同步注册的信息给其它的SERVER，同时也要负责各个节点的健康监测。
• 其它信息
其它信息包括它们之间的通信方式，还有一些协议信息，算法。它们是用于保证节点之间的数据同步，实时性要求等等一系列集群问题的解决。这些有兴趣的自己看看官方文档。
相关开源项目：Zookeeper，Doozer，Etcd，强一致性的项目，这些项目主要用于服务间的协调，同时又可用于服务的注册。
什么是强一致性协议？
按照某一顺序串行执行存储对象读写操作， 更新存储对象之后， 后续访问总是读到最新值。 假如进程A先更新了存储对象，存储系统保证后续A,B,C进程的读取操作都将返回最新值。强一致性模型有几种常见实现方法， 主从同步复制， 以及quorum复制等。
http://blog.csdn.net/shlazww/article/details/38736511
- consul的具体应用场景
- docker、coreos 实例的注册与配置共享
- vitess集群
- SaaS应用的配置共享
4.与confd服务集成，动态生成nignx与haproxy配置文件 - 优势
- 使用 Raft 算法来保证一致性，比poxes算法更直接。zookeeper采用的时poxes算法。
Raft大概将整个过程分为三个阶段，leader election，log replication和commit(safety)。
每个server处于三个状态：leader，follower，candidate。正常情况下，所有server中只有一个是leader，其它的都是follower。server之间通过RPC消息通信。follower不会主动发起RPC消息。leader和candidate(选主的时候)会主动发起RPC消息。
首先选择一个leader全权负责管理日志复制，leader从客户端接收log entries，将它们复制给集群中的其它机器，然后负责告诉其它机器什么时候将日志应用于它们的状态机。举个例子，leader可以在无需询问其它server的情况下决定把新entries放在哪个位置，数据永远是从leader流向其它机器。一个leader可以fail或者与其他机器失去连接，这种情形下会有新的leader被选举出来。
http://www.jdon.com/artichect/raft.html
http://blog.csdn.net/cszhouwei/article/details/38374603 - 支持多数据中心，内外网的服务采用不同的端口进行监听。这样可以避免单点故障。
zookeeper等不支持多数据中心功能的支持 - 支持健康检查
- 提供web界面
- 支持http协议与dns协议接口
• 使用 Raft 算法来保证一致性, 比复杂的 Paxos 算法更直接. 相比较而言, zookeeper 采用的是 Paxos, 而 etcd 使用的则是 Raft.
• 支持多数据中心，内外网的服务采用不同的端口进行监听。 多数据中心集群可以避免单数据中心的单点故障,而其部署则需要考虑网络延迟, 分片等情况等. zookeeper 和 etcd 均不提供多数据中心功能的支持.
• 支持健康检查. etcd 不提供此功能.
• 支持 http 和 dns 协议接口. zookeeper 的集成较为复杂, etcd 只支持 http 协议.
• 官方提供web管理界面, etcd 无此功能.
综合比较, Consul 作为服务注册和配置管理的新星, 比较值得关注和研究.
二、 Consul架构设计
只有一个数据中心的Consul的架构图如下：
我们可以看到，有三个不同的服务器由Consul管理。整个架构通过使用Raft算法工作，这有助于我们从三个不同的服务器中选出一个领导者。然后根据诸如Follower和Leader之类的标签标记这些服务器。顾名思义，Follower有责任遵循Leader的决定。这三个服务器之间进一步相互连接以进行通信。
每个服务器使用RPC与其自己的客户端进行交互。客户端之间的通信是使用Gossip协议。可以使用TCP或Gossip来提供与互联网设施的通信。
Raft算法
Raft是提供一致性的算法。它依赖于CAP定理的原理，该定理指出，在存在网络分区的情况下，必须在一致性和可用性之间进行选择。并非CAP定理的所有三个基本原理：Consistency(一致性)、Availability(可用性)、Partition Tolerance(分区容错性)，都可以在任何给定的时间点实现。人们必须在最好的情况下权衡其中任何两个。
一个Raft集群包含多个服务器，通常是奇数的。例如，如果我们有五台服务器，它将允许系统容忍两个故障。在任何给定时间，每个服务器都处于以下三种状态之一：Leader，Follower或Candidate。在正常操作中，只有一个领导者，所有其他服务器都是Follower。这些Follower处于被动状态，即他们自己不发出请求，而只是响应Leader和Candidate的请求。
下图描述了使用Raft算法工作的工作流模型
协议类型
Consul中有两种类型的协议，称为
• Consensus协议
• Gossip协议
现在让我们详细了解它们。
Consensus Protocol
Consul使用Consensus protocol来提供CAP定理所描述的一致性。该协议基于Raft算法，其中Raft节点始终处于三种状态中的任何一种：Follower, Candidate or Leader。
• Leader，负责Client交互和log复制，同一时刻系统中最多存在1个
• Follower，被动响应请求RPC，从不主动发起请求RPC
• Candidate，由Follower向Leader转换的中间状态
初始时所有节点都是以Follower启动。一个最小的 Raft 集群需要三个参与者，这样才可能投出多数票。当发起选举时，如果每方都投给了自己，结果没有任何一方获得多数票。之后每个参与方随机休息一阵（Election Timeout）重新发起投票直到一方获得多数票。这里的关键就是随机 timeout，最先从timeout中恢复发起投票的一方向还在 timeout 中的另外两方请求投票，这时它们就只能投给对方了，这样很快就能达成一致。
Gossip Protocol
Gossip协议可用于管理成员资格，跨群集发送和接收消息。在Consul中，Gossip协议的使用以两种方式发生，WAN（无线区域网络）和LAN（局域网）。有三个已知的库，可以实现Gossip算法来发现对等网络中的节点 ：
• teknek-gossip - 它与UDP一起使用，用Java编写。
• gossip-python - 它利用TCP堆栈，也可以通过构建的网络共享数据。
• Smudge - 它是用Go编写的，使用UDP来交换状态信息。
Gossip协议也被用于实现和维护分布式数据库一致性或与一致状态的其他类型数据，计算未知大小的网络中的节点数量，稳健地传播消息，组织节点等。
Remote Procedure Calls
RPC可以表示为远程过程调用的简写形式。它是一个程序用于从另一个程序请求服务的协议。此协议可以位于网络上的另一台计算机中，而无需确认网络详细信息。
在Consul中使用RPC的真正用处在于，它可以帮助我们避免大多数发现服务工具在一段时间之前所遇到的延迟问题。在RPC之前，Consul过去只使用基于TCP和UDP的连接，这对大多数系统都很好，但对于分布式系统则不行。RPC通过减少从一个地方到另一个地方的分组信息传输的时间段来解决这些问题。
三、 Consul系列之服务部署、搭建、使用
主要以linux来讲解其他操作平台见官网Download Consul
下载 wget https://releases.hashicorp.com/consul/1.4.0/consul_1.4.0_linux_amd64.zip
解压 unzip consul_1.4.0_linux_amd64.zip 得到目录consul
复制 consul到你的系统的任何一个地方如果你想使用命令行直接访问确保复制的目录在你的PATH里 cp consul /usr/local/bin/
验证consul是否安装成功出现以下窗口则安装成功
[root@iZbp1isjfk2rw8fpnxx8wgZ ~]# consul
Usage: consul [–version] [–help] []
Available commands are:
acl Interact with Consul’s ACLs
agent Runs a Consul agent
catalog Interact with the catalog
connect Interact with Consul Connect
debug Records a debugging archive for operators
event Fire a new event
exec Executes a command on Consul nodes
force-leave Forces a member of the cluster to enter the “left” state
info Provides debugging information for operators.
intention Interact with Connect service intentions
join Tell Consul agent to join cluster
keygen Generates a new encryption key
keyring Manages gossip layer encryption keys
kv Interact with the key-value store
leave Gracefully leaves the Consul cluster and shuts down
lock Execute a command holding a lock
maint Controls node or service maintenance mode
members Lists the members of a Consul cluster
monitor Stream logs from a Consul agent
operator Provides cluster-level tools for Consul operators
reload Triggers the agent to reload configuration files
rtt Estimates network round trip time between nodes
services Interact with services
snapshot Saves, restores and inspects snapshots of Consul server state
validate Validate config files/directories
version Prints the Consul version
watch Watch for changes in Consul
Consul Agent
执行consul agent -dev启动开发模式这个模式会快速启动一个单节点的Consul。注意这个模式不能数据持久化因此不能用于生产环境
启动命令简介
• -server定义agent运行在server模式每个数据中心的Server建议在35个避免失败情况下数据的丢失
• -client定义agent运行在client模式
• -bootstrap-expect在一个datacenter中期望提供的server节点数目当该值提供的时候consul一直等到达到指定sever数目的时候才会引导整个集群
• -bind节点的ip地址一般是0.0.0.0或云服务内网地址用于被集群中的其他节点所访问
• -node指定节点在集群中的唯一名称默认为机器的hostname
• -config-dir配置文件目录里面所有以.json结尾的文件都会被加载
• 更多可选参数参考Consul Command-line Options
Start Agent
[root@iZbp1isjfk2rw8fpnxx8wgZ ~]# consul agent -dev
==> Starting Consul agent…
==> Consul agent running!
Version: ‘v1.4.0’
Node ID: ‘9e05f4d6-56c1-e57c-c726-15d9ab1c0dd5’
Node name: ‘iZbp1isjfk2rw8fpnxx8wgZ’
Datacenter: ‘dc1’ (Segment: ‘’)
Server: true (Bootstrap: false)
Client Addr: [127.0.0.1] (HTTP: 8500, HTTPS: -1, gRPC: 8502, DNS: 8600)
Cluster Addr: 127.0.0.1 (LAN: 8301, WAN: 8302)
Encrypt: Gossip: false, TLS-Outgoing: false, TLS-Incoming: false
==> Log data will now stream in as it occurs:
看下 consul agent 输出的几个重要信息
• Node name代理的唯一名称默认是机器的hostname可以通过-node标志自定义例如consul agent -dev -node myNode
• Datacenter数据中心Consul支持多个数据中心为了有效的工作每个节点必须被配置且上报到数据中心-datacenter标志用来设置数据中心对于单一的DC配置这个代理默认为dc1
• Server表示代理是以服务器还是客户端的模式来运行。
• Client Addr用于代理的客户端接口地址。
• Cluster Addr用于集群中的Consul代理之间通信的地址和端口集改地址必须可供其它节点访问。
查看集群成员
打开一个新终端执行consul members可以看到集群的成员。
• Node节点名称
• Address节点地址
• Statusalive表示节点为健康状态
• Type节点的运行模式Server
Stop Agent
Agent两种停止方式gracefully或forcefully
gracefully方式停止则是发送中断信号到Agent进程两种方法Ctrl+C、kill -INT consul_pid
服务注册
Consul服务搭建好之后通过提供服务定义或HTTP API注册一个服务通用的模式是通过提供服务定义的方式下文还会介绍怎么应用Consul进行健康检查
提供服务定义方式服务注册
创建目录/etc/consul.d(.d 后缀意思是这个路径包含了一组配置文件Consul会载入该目录下的所有文件。
例如我现在有个测试服务test01端口为3010
sudo mkdir /etc/consul.d/test01.json
{
“service”:{
“name”:“test01”,
“tags”:[
“”,
“”
],
“address”:“127.0.0.1”,
“port”:3010,
“enable_tag_override”: false,
“check”:{
“deregisterCriticalServiceAfter”:“90m”,
“http”:“http://127.0.0.1:3010/health”,
“interval”:“10s”
}
}
}
服务定义配置文件含义
• name服务名
• tags服务的tag自定义可以根据这个tag来区分同一个服务名的服务
• address服务注册到consul的IP服务发现发现的就是这个IP
• port服务注册consul的PORT发现的就是这个PORT
• enable_tag_override标签是否允许覆盖
• check健康检查部分
o deregisterCriticalServiceAfter
o http指定健康检查的URL调用后只要返回20Xconsul都认为是健康的
o interval健康检查间隔时间每隔10s调用一次上面的URL
重启Agent设置配置目录
consul agent -dev -config-dir /etc/consul.d
看以下运行结果
启动之后控制台输出了Synced service "test01"意思是Agent从配置文件中载入了服务定义且成功注册到服务目录另外右边的服务test01也收到了健康检查接口调用
采用HTTP API服务注册
调用/v1/agent/service/register接口进行注册请求Method为PUT方式
请求Body值为服务定义中的service值看一下示例
curl -X PUT
http://127.0.0.1:8301/v1/agent/service/register
-H ‘cache-control: no-cache’
-H ‘content-type: application/json’
-H ‘postman-token: 6b672c02-350f-3d1c-7793-1a0d9e800fc9’
-d ‘{
“id”: “test01”,
“name”:“test01”,
“tags”:[
“”,
“”
],
“address”:“127.0.0.1”,
“port”:3010,
“check”:{
“deregisterCriticalServiceAfter”:“90m”,
“http”:“http://127.0.0.1:3010/health”,
“interval”:“10s”
}
}’
四、 Consul系列之集群搭建
测试用建议本地搭建几台虚拟机用于调试，这里的虚拟机分别为3台Server模式，1台Client模式，共以下4台：
• 192.168.6.128 Server模式（初始设置为Leader）
• 192.168.6.129 Server模式
• 192.168.6.130 Server模式
• 192.168.6.131 Client模式
下载相应平台版本的Consul解压copy至/usr/local/bin/（系统的环境变量）目录，这里以1.4.0版本为例，具体安装参照上篇-consul下载安装指南。
创建 /usr/src/consul目录，存放Consul的启动配置文件consul_config.json：
{
“datacenter”: “consul_cluster”,
“node_name”: “consul_1”,
“server”: true,
“bootstrap_expect”: 3,
“data_dir”: “/usr/src/consul/data”,
“log_level”: “DEBUG”,
“enable_syslog”: true,
“enable_script_checks”: true,
“bind_addr”: “192.168.6.128”,
“client_addr”: “192.168.6.128”,
}
• node_name：节点名称，等同于-node
• data_dir：数据存放目录
• enable_syslog：consul日志写入系统的syslog目录是否启用
• enable_script_checks：是否启用监控检测脚本
• bind_addr：等同于-bind
• client_addr：等同于-client
Server端部署
• 部署第一台192.168.6.128
注意：在第一台启动的时候加上-ui，只初始化一次，在其它2个节点进行相同操作，但是配置文件中的node_name、bind_addr、client_addr要进行更改，每台机器保持唯一。
$ sudo consul agent -ui -config-file=/usr/src/consul/consul_config.json
-config-file：加载启动的配置文件
• 部署第二台192.168.6.129
修改/usr/src/consul/consul_config.json：
{
“datacenter”: “consul_cluster”,
“node_name”: “consul_2”,
“server”: true,
“bootstrap_expect”: 3,
“data_dir”: “/usr/src/consul/data”,
“log_level”: “DEBUG”,
“enable_syslog”: true,
“enable_script_checks”: true,
“bind_addr”: “192.168.6.129”,
“client_addr”: “192.168.6.129”,
}
执行命令启动命令
$ sudo consul agent -config-file=/usr/src/consul/consul_config.json
• 部署第三台192.168.6.130
修改/usr/src/consul/consul_config.json：
{
“datacenter”: “consul_cluster”,
“node_name”: “consul_3”,
“server”: true,
“bootstrap_expect”: 3,
“data_dir”: “/usr/src/consul/data”,
“log_level”: “DEBUG”,
“enable_syslog”: true,
“enable_script_checks”: true,
“bind_addr”: “192.168.6.130”,
“client_addr”: “192.168.6.130”
}
执行命令启动命令
$ sudo consul agent -config-file=/usr/src/consul/consul_config.json
截止目前服务端已经全部启动，但是还没有加入集群，因此还只是单节点的集群，可以在某台机器上查看成员情况：
注意：直接使用consul members会报错，需要绑定ip地址
$ consul members --http-addr 192.168.6.128:8500
Node Address Status Type Build Protocol DC Segment
consul_1 192.168.6.128:8301 alive server 1.4.0 2 consul_cluster
Server端集群建立
每个Consul Agent之后，都是相对独立的并不知道其它节点的存在，现在我们要做的是加入集群，将上面创建的consul_2、consul_3加入到同一个集群consul_1中。
• 第二台192.168.6.129加入到consul_1中
$ consul join --http-addr 192.168.6.129:8500 192.168.6.128
Successfully joined cluster by contacting 1 nodes. # 成功返回的消息
• 第三台192.168.6.130加入到consul_1中
$ consul join --http-addr 192.168.6.130:8500 192.168.6.128
目前服务端的集群已经创建完毕，可以看下我们目前的集群成员情况：
consul members --http-addr 192.168.6.128:8500
Node Address Status Type Build Protocol DC Segment
consul_1 192.168.6.128:8301 alive server 1.4.0 2 consul_cluster
consul_2 192.168.6.129:8301 alive server 1.4.0 2 consul_cluster
consul_3 192.168.6.130:8301 alive server 1.4.0 2 consul_cluster
• 通过HTTP API的方式查看集群leader
$ curl 192.168.6.128:8500/v1/status/leader
“192.168.6.128:8300”
• 通过HTTP API的方式查看集群成员
$ curl 192.168.6.128:8500/v1/status/peers
[“192.168.6.129:8300”,“192.168.6.130:8300”,“192.168.6.128:8300”]
Client端部署
现在开始客户端的部署，方式同服务端有不同
修改/usr/src/consul/consul_config.json：
{
“datacenter”: “consul_cluster”,
“node_name”: “consul_4”,
//“server”: true, 不指定为服务端，默认走客户端
// “bootstrap_expect”: 3, 只在server模式有效
“data_dir”: “/usr/src/consul/data”,
“log_level”: “DEBUG”,
“enable_syslog”: true,
“enable_script_checks”: true,
“bind_addr”: “192.168.6.131”,
“client_addr”: “192.168.6.131”
}
执行启动命令：
通过-join参数也可以加入一个已经启动的集群
$ sudo consul agent -config-file=/usr/src/consul/consul_config.json -join=192.168.6.128
在查看当前集群成员，可以看到为3个Server模式和1个Client模式
$ consul members --http-addr 192.168.6.128:8500
Node Address Status Type Build Protocol DC Segment
consul_1 192.168.6.128:8301 alive server 1.4.0 2 consul_cluster
consul_2 192.168.6.129:8301 alive server 1.4.0 2 consul_cluster
consul_3 192.168.6.130:8301 alive server 1.4.0 2 consul_cluster
consul_4 192.168.6.131:8301 alive client 1.4.0 2 consul_cluster
管理工具中查看
在部署第一台192.168.6.128机器的时候，consul agent之后有跟一个-ui参数，这个是用于启动WebUI界面，这个是Consul本身所提供的Web可视化界面，浏览器输入http://192.168.6.128:8500进行访问
五、 Consul系列之服务注册与服务发现
以下是上节做Consul集群的时候列的机器列表，下面我们将192.168.6.131机器安装了Node服务，起了两个端口
机器 模式 节点名称
192.168.6.128 Server consul_1（初始设置为Leader）
192.168.6.129 Server consul_2
192.168.6.130 Server consul_3
192.168.6.131 Client consul_4
• 服务一：order_service
$ curl http://192.168.6.131:3010/health
ok
• 服务二：user_service
$ curl http://192.168.6.131:3011/health
ok
服务注册
对order_service、user_service两个服务在consul_4节点上进行服务定义，配置中包含了服务的名称、地址、端口以及每10秒中对服务进行一次健康检查。
• 注册服务一：order_service
order_service.json
{
“service”:{
“name”:“order_service”,
“address”:“192.168.1.131”,
“port”: 3010,
“enable_tag_override”: false,
“check”:{
“deregisterCriticalServiceAfter”:“90m”,
“http”:“http://192.168.1.131:3010/health”,
“interval”:“10s”
}
}
}
• 注册服务二：user_service
user_service.json
{
“service”:{
“name”:“user_service”,
“address”:“192.168.1.131”,
“port”: 3011,
“enable_tag_override”: false,
“check”:{
“deregisterCriticalServiceAfter”:“90m”,
“http”:“http://192.168.1.131:3011/health”,
“interval”:“10s”
}
}
}
• 启动consul_4进行服务注册
Consul Agent启动过程中通过指定-config-dir参数可以定位到配置文件所在目录，且目录下文件为.json的都会被Consul Agent配置文件所读取。
$ sudo consul agent -config-file=/usr/src/consul/consul_config.json -join=192.168.6.128 -config-dir=/etc/consul.d
服务注册成功之后查看我们的Web管理界面，在consul_4中展示了我们上面定义的两个服务及端口号
下图为Web管理界面展示的健康检查情况，可以看到进行了接口请求，且响应状态为200，输出结果为ok。
服务发现
Consul服务发现支持HTTP API和DNS两种方式
• HTTP API
$ curl http://192.168.6.128:8500/v1/catalog/service/order_service?passing=true
执行命令之后返回Consul的注册信息、服务信息及健康检查信息，且指定passing=true，表示返回时过滤掉一些不健康的节点。
[
{
“ID”:“cf35869a-edba-5e1f-77e0-922b55ddfad4”,
“Node”:“consul_4”,
“Address”:“192.168.6.131”,
“Datacenter”:“consul_cluster”,
“TaggedAddresses”:{
“lan”:“192.168.6.131”,
“wan”:“192.168.6.131”
},
“NodeMeta”:{
“consul-network-segment”:""
},
“ServiceKind”:"",
“ServiceID”:“order_service”,
“ServiceName”:“order_service”,
“ServiceTags”:[
],
"ServiceAddress":"192.168.6.131",
"ServiceWeights":{
"Passing":1,
"Warning":1
},
"ServiceMeta":{
},
"ServicePort":3010,
"ServiceEnableTagOverride":false,
"ServiceProxyDestination":"",
"ServiceProxy":{
},
"ServiceConnect":{
},
"CreateIndex":3818,
"ModifyIndex":3818
}
]
• DNS方式
现在使用第二种DNS方式查询具体的服务，Consul提供了默认的名字NAME.service.consul，NAME代指注册的服务名称。
对于上面注册的两个Web服务对应域名分别为order_service.service.consul和user_service.service.consul，下面先对于order_service.service.consul进行服务查询
$ dig @192.168.6.128 -p 8600 order_service.service.consul
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.168.6.128 -p 8600 order_service.service.consul
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31324
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;order_service.service.consul. IN A
;; ANSWER SECTION:
order_service.service.consul. 0 IN A 192.168.6.131
;; ADDITIONAL SECTION:
order_service.service.consul. 0 IN TXT “consul-network-segment=”
;; Query time: 1 msec
;; SERVER: 192.168.6.128#8600(192.168.6.128)
;; WHEN: Thu Mar 28 16:55:27 PDT 2019
;; MSG SIZE rcvd: 109
如上所示，ANSWER SECTION:一个A记录返回了一个服务所在的节点IP地址为：192.168.6.131
为了展示更详细的信息，在dig命令中我们可以加上SRV参数，可以返回服务所在的节点信息、端口号。
$ dig @192.168.6.128 -p 8600 order_service.service.consul SRV
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.168.6.128 -p 8600 order_service.service.consul SRV
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52707
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;order_service.service.consul. IN SRV
;; ANSWER SECTION:
order_service.service.consul. 0 IN SRV 1 1 3010 consul_4.node.consul_cluster.consul.
;; ADDITIONAL SECTION:
consul_4.node.consul_cluster.consul. 0 IN A 192.168.6.131
consul_4.node.consul_cluster.consul. 0 IN TXT “consul-network-segment=”
;; Query time: 1 msec
;; SERVER: 192.168.6.128#8600(192.168.6.128)
;; WHEN: Thu Mar 28 17:19:29 PDT 2019
;; MSG SIZE rcvd: 164
如上所示，ADDITIONAL SECTION:一个A记录不止，返回了一个服务所在的节点IP地址为：192.168.6.131，还有节点名称及数据中心，在ANSWER SECTION:中还可以看到服务的端口号信息。
服务异常情况
现在我们来做些处理将consul_4节点上的order_service服务停掉，此时可以看到故障服务order_service已经不在当前结果列表页了，保证了客户端在服务发现过程中只能获取当前可用的服务节点。
$ dig @192.168.6.128 -p 8600 order_service.service.consul
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.168.6.128 -p 8600 order_service.service.consul
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 45049
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;order_service.service.consul. IN A
;; AUTHORITY SECTION:
consul. 0 IN SOA ns.consul. hostmaster.consul. 1553830680 3600 600 86400 0
;; Query time: 0 msec
;; SERVER: 192.168.6.128#8600(192.168.6.128)
;; WHEN: Thu Mar 28 20:38:00 PDT 2019
;; MSG SIZE rcvd: 107
如上所示，已经没有了ADDITIONAL SECTION:区域信息。
再来看下在健康检查端，列出了不健康的节点consul_4，标注了哪些是健康状态和哪些是非正常状态的服务。
点击consul_4可以看到详细的健康检查信息结果，例如上面我们停掉的order_service服务返回链接被拒。
六、 Consul系列之问题汇总
Consul Agent 启动报错
$ consul agent -dev -config-dir /etc/consul.d
==> Starting Consul agent…
==> Error starting agent: Failed to start Consul server: Failed to start RPC layer: listen tcp 127.0.0.1:8300: bind: address already in use
这个地址已经在使用了，说明你已经启动了。
命令ps -ef | grep consul查看使用情况
$ ps -ef | grep consul
root 16140 1 0 Jan20 ? 09:22:26 consul agent -dev
root 21018 19751 0 16:45 pts/0 00:00:00 grep --color=auto consul
如果想要关闭，执行命令kill -9 consul_pid强制杀死进程，第一个元素（上面的16140）就是进程id
查看集群成员报错
$ consul members
Error retrieving members: Get http://127.0.0.1:8500/v1/agent/members?segment=_all: dial tcp 127.0.0.1:8500: connect: connection refused
原因是由于在启动Consul时候绑定了IP地址，而默认的为127.0.0.1:8500，解决办法其实就是进行显示绑定，看以下用法：
$ consul members --http-addr 192.168.6.128:8500
Node Address Status Type Build Protocol DC Segment
consul_1 192.168.6.128:8301 alive server 1.4.0 2 consul_cluster
关于开启Consul Web可视化界面的一些问题
这是最简单快速的启动方式，在启动consul时直接启动webui界面，跟上-ui参数参考以下示例，端口默认为8500
consul agent -server -bootstrap -ui -data-dir=/data/soft/consul_1.4/consul-data -bind=0.0.0.0 -client=0.0.0.0 -node=120.27.239.212
如果阿里云或其他云厂商服务器，在开启了Web 可视化界面之后，但是浏览器输入 http://127.0.0.1:8500/ui 无法访问，可能是链接被拒等情况，如果使用阿里云请注意安全组是否开启。
如上所述，为阿里云服务器在安全组规则里做以上设置开启端口。
七、 Consul配置参数大全
命令行选项
以下选项全部在命令行中指定。
• -advertise - 通告地址用于更改我们通告给集群中其他节点的地址。默认情况下，-bind地址是通告的。但是，在某些情况下，可能存在无法绑定的可路由地址。这个标志使闲聊不同的地址来支持这一点。如果此地址不可路由，则节点将处于持续振荡状态，因为其他节点会将非可路由性视为故障。在Consul 1.0和更高版本中，这可以设置为 go-sockaddr 模板。
• -advertise-wan - 广告WAN地址用于更改我们向通过WAN加入的服务器节点发布的地址。这也可以在与translate_wan_addrs配置选项结合使用时在客户端代理上设置。默认情况下，-advertise地址是通告的。但是，在某些情况下，所有数据中心的所有成员都不能位于同一个物理或虚拟网络上，尤其是混合云和专用数据中心的混合设置。该标志使服务器节点能够通过WAN的公共网络闲聊，同时使用专用VLAN来相互闲聊以及彼此的客户端代理，并且如果远程数据中心是远程数据中心，则允许客户端代理在从远程数据中心访问时访问此地址配置translate_wan_addrs。在Consul 1.0和更高版本中，这可以设置为 go-sockaddr 模板
• -bootstrap - 该标志用于控制服务器是否处于“引导”模式。每个数据中心最多只能运行一个服务器，这一点很重要。从技术上讲，一个处于引导模式的服务器可以自我选择为Raft领导者。只有一个节点处于这种模式非常重要; 否则，一致性不能保证，因为多个节点能够自我选择。不建议在引导群集后使用此标志。
• -bootstrap-expect - 此标志提供数据中心中预期服务器的数量。不应该提供此值，或者该值必须与群集中的其他服务器一致。提供时，Consul会等待指定数量的服务器可用，然后引导群集。这允许初始领导者自动选举。这不能与遗留-bootstrap标志结合使用。该标志需要-server模式。
• -bind - 应为内部集群通信绑定的地址。这是集群中所有其他节点都应该可以访问的IP地址。默认情况下，这是“0.0.0.0”，这意味着Consul将绑定到本地计算机上的所有地址，并将 第一个可用的私有IPv4地址通告给群集的其余部分。如果有多个私有IPv4地址可用，Consul将在启动时退出并出现错误。如果你指定“[::]”，领事将 做广告第一个可用的公共IPv6地址。如果有多个公共IPv6地址可用，则Consul将在启动时退出并出现错误。Consul同时使用TCP和UDP以及相同的端口。如果您有任何防火墙，请确保同时允许这两种协议。在Consul 1.0和更高版本中，可以将其设置为要绑定到的空间分隔的地址列表，或者可能会解析为多个地址的 go-sockaddr模板。
• -serf-wan-bind - 应该被绑定到Serf WAN八卦通信的地址。默认情况下，该值遵循与-bind命令行标志相同的规则，如果未指定该值，-bind则使用该选项。这在Consul 0.7.1及更高版本中可用。在Consul 1.0和更高版本中，这可以设置为 go-sockaddr 模板
• -serf-lan-bind - Serf LAN八卦通信应该绑定的地址。这是群集中所有其他LAN节点应可访问的IP地址。默认情况下，该值遵循与-bind命令行标志相同的规则，如果未指定该值，-bind则使用该选项。这在Consul 0.7.1及更高版本中可用。在Consul 1.0和更高版本中，这可以设置为 go-sockaddr模板
• -client - Consul将绑定客户端接口的地址，包括HTTP和DNS服务器。默认情况下，这是“127.0.0.1”，只允许回送连接。在Consul 1.0和更高版本中，可以将其设置为要绑定到的空间分隔的地址列表，或者 可能会解析为多个地址的 go-sockaddr模板。
• -config-file - 要加载的配置文件。有关此文件格式的更多信息，请阅读配置文件部分。该选项可以多次指定以加载多个配置文件。如果指定了多次，稍后加载的配置文件将与先前加载的配置文件合并。在配置合并期间，单值键（string，int，bool）将简单地将它们的值替换，而列表类型将被附加在一起。
• -config-dir - 要加载的配置文件的目录。Consul将加载后缀为“.json”的所有文件。加载顺序是按字母顺序排列的，并使用与上述config-file选项相同的合并例程 。可以多次指定此选项以加载多个目录。不加载config目录的子目录。有关配置文件格式的更多信息，请参阅 配置文件部分。
• -config-format - 要加载的配置文件的格式。通常，Consul会从“.json”或“.hcl”扩展名检测配置文件的格式。将此选项设置为“json”或“hcl”强制Consul解释任何带或不带扩展名的文件，以该格式解释。
• -data-dir - 此标志为代理存储状态提供了一个数据目录。这对所有代理都是必需的。该目录在重新启动时应该是持久的。这对于在服务器模式下运行的代理尤其重要，因为它们必须能够保持群集状态。此外，该目录必须支持使用文件系统锁定，这意味着某些类型的已装入文件夹（例如VirtualBox共享文件夹）可能不合适。注意：服务器和非服务器代理都可以在此目录中的状态下存储ACL令牌，因此读取访问权限可以授予对服务器上的任何令牌的访问权限，并允许访问非服务器上的服务注册期间使用的任何令牌。在基于Unix的平台上，这些文件使用0600权限编写，因此您应确保只有受信任的进程可以与Consul一样的用户身份执行。在Windows上，您应确保该目录具有适当的权限配置，因为这些权限将被继承。
• -datacenter - 此标志控制运行代理程序的数据中心。如果未提供，则默认为“dc1”。Consul对多个数据中心拥有一流的支持，但它依赖于正确的配置。同一个数据中心内的节点应该位于单个局域网中。
• -dev - 启用开发服务器模式。这对于在关闭所有持久性选项的情况下快速启动Consul代理非常有用，从而启用可用于快速原型开发或针对API进行开发的内存服务器。此模式不适合生产使用，因为它不会将任何数据写入磁盘。
• -disable-host-node-id - 将此设置为true将阻止Consul使用来自主机的信息生成确定性节点标识，并将生成随机节点标识，该标识将保留在数据目录中。在同一台主机上运行多个Consul代理进行测试时，这非常有用。Consul在版本0.8.5和0.8.5之前缺省为false，因此您必须选择加入基于主机的ID。基于主机的ID是使用https://github.com/shirou/gopsutil/tree/master/host生成的，与HashiCorp的Nomad共享 ，因此如果您选择加入基于主机的ID，则Consul和Nomad将使用信息在主机上在两个系统中自动分配相同的ID。
• -disable-keyring-file - 如果设置，密钥环不会被保存到文件中。任何已安装的密钥在关机时将丢失，只有在给定的 -encrypt密钥在启动时可用。这默认为false。
• -dns-port - 侦听的DNS端口。这将覆盖默认端口8600.这在Consul 0.7和更高版本中可用。
• -domain - 默认情况下，Consul响应“consul”中的DNS查询。域。该标志可用于更改该域。该域中的所有查询都假定由Consul处理，不会递归解决。
• -enable-script-checks这将控制是否在此代理上启用执行脚本的运行状况检查，并且默认为false运营商必须选择允许这些脚本。如果启用，建议启用ACL以控制允许哪些用户注册新的检查以执行脚本。这是在Consul 0.9.0中添加的。
• -encrypt - 指定用于加密Consul网络流量的密钥。该密钥必须是Base64编码的16字节。创建加密密钥的最简单方法是使用 consul keygen。群集中的所有节点必须共享相同的加密密钥才能进行通信。提供的密钥会自动保留到数据目录并在代理程序重新启动时自动加载。这意味着为了加密Consul的闲话协议，这个选项只需要在每个代理的初始启动序列中提供一次。如果Consul在使用加密密钥初始化后提供，则忽略提供的密钥并显示警告。
• -hcl - HCL配置片段。此HCL配置片段将附加到配置中，并允许在命令行上指定配置文件的全部选项。该选项可以多次指定。这是在Consul 1.0中添加的。
• -http-port - 要监听的HTTP API端口。这覆盖了默认端口8500.当将Consul部署到通过环境传递HTTP端口的环境时，此选项非常有用，例如像CloudFoundry这样的PaaS，允许您通过Procfile直接设置端口。
• -join - 启动时加入的另一位代理的地址。这可以指定多次以指定多个代理加入。如果Consul无法加入任何指定的地址，代理启动将失败。默认情况下，代理在启动时不会加入任何节点。请注意，retry_join在自动执行Consul集群部署时，使用 可能更适合帮助缓解节点启动竞争条件。
在Consul 1.1.0和更高版本中，这可以设置为 go-sockaddr 模板
• -retry-join- 类似于-join第一次尝试失败时允许重试连接。这对于知道地址最终可用的情况很有用。该列表可以包含IPv4，IPv6或DNS地址。在Consul 1.1.0和更高版本中，这可以设置为 go-sockaddr 模板。如果Consul正在非默认的Serf LAN端口上运行，则必须指定。IPv6必须使用“括号”语法。如果给出多个值，则按照列出的顺序尝试并重试它们，直到第一个成功为止。这里有些例子：
• # Using a DNS entry
• $ consul agent -retry-join “consul.domain.internal”
• # Using IPv4
• $ consul agent -retry-join “10.0.4.67”
• # Using IPv6
• $ consul agent -retry-join “[::1]:8301”
»云端自动加入
从Consul 0.9.1开始，retry-join使用go-discover库接受使用云元数据进行自动集群加入的统一接口 。有关更多信息，请参阅云端自动加入页面。
Using Cloud Auto-Joining
$ consul agent -retry-join “provider=aws tag_key=…”
• -retry-interval - 加入尝试之间的等待时间。默认为30秒。
• -retry-max- -join在退出代码1之前尝试执行的最大尝试次数。默认情况下，它设置为0，将其解释为无限次重试。
• -join-wan - 启动时加入的另一个WAN代理的地址。可以指定多次以指定要加入的多个WAN代理。如果Consul无法加入任何指定的地址，代理启动将失败。默认情况下，代理-join-wan启动时不会有任何节点。
在Consul 1.1.0和更高版本中，这可以设置为 go-sockaddr 模板。
• -retry-join-wan- 与retry-join第一次尝试失败时允许重试wan连接类似。这对于我们知道地址最终可用的情况很有用。截至领事0.9.3 云支持自动加入。
在Consul 1.1.0和更高版本中，这可以设置为 go-sockaddr 模板
• -retry-interval-wan- 两次-join-wan尝试之间的等待时间。默认为30秒。
• -retry-max-wan- -join-wan在退出代码1之前尝试执行的最大尝试次数。默认情况下，它设置为0，将其解释为无限次重试。
• -log-level - Consul代理启动后显示的日志级别。这默认为“信息”。可用的日志级别是“跟踪”，“调试”，“信息”，“警告”和“错误”。您始终可以通过consul monitor并使用任何日志级别连接到代理。另外，日志级别可以在配置重载期间更改。
• -node - 集群中此节点的名称。这在集群内必须是唯一的。默认情况下，这是机器的主机名。
• -node-id - 在Consul 0.7.3及更高版本中可用，即使节点或地址的名称发生更改，该节点仍然是该节点的唯一标识符。这必须采用十六进制字符串的形式，长度为36个字符，例如 adf4238a-882b-9ddc-4a9d-5b6758e4159e。如果未提供（最常见的情况），那么代理将在启动时生成一个标识符，并将其保存在数据目录中， 以便在代理重新启动时保持相同。如果可能，主机的信息将用于生成确定性节点ID，除非-disable-host-node-id设置为true。
• -node-meta- 在Consul 0.7.3及更高版本中可用，这指定了一个任意的元数据键/值对，与表单的节点相关联key:value。这可以指定多次。节点元数据对具有以下限制：
o 每个节点最多可注册64个键/值对。
o 元数据密钥的长度必须介于1到128个字符（含）之间
o 元数据键只能包含字母数字-，和_字符。
o 元数据密钥不能以consul-前缀开头; 这是保留供内部使用的领事。
o 元数据值的长度必须介于0到512（含）之间。
o 开头的密钥的元数据值rfc1035-在DNS TXT请求中逐字编码，否则元数据kv对将根据RFC1464进行编码。
• -pid-file - 此标志为代理存储其PID提供文件路径。这对发送信号很有用（例如，SIGINT 关闭代理或SIGHUP更新检查确定
• -protocol - 要使用的Consul协议版本。这默认为最新版本。这应该只在升级时设置。您可以通过运行查看Consul支持的协议版本consul -v。
• -raft-protocol - 它控制用于服务器通信的内部版本的Raft一致性协议。必须将其设置为3才能访问自动驾驶仪功能，但不包括cleanup_dead_servers。Consul 1.0.0及更高版本默认为3（以前默认为2）。有关 详细信息，请参阅 Raft协议版本兼容性。
• -raft-snapshot-threshold - 这将控制保存到磁盘的快照之间的最小数量的木筏提交条目。这是一个很少需要更改的低级参数。遇到磁盘IO过多的非常繁忙的群集可能会增加此值以减少磁盘IO，并最大限度地减少所有服务器同时进行快照的机会。由于日志会变得更大并且raft.db文件中的空间直到下一个快照才能被回收，所以增加这一点会使磁盘空间与磁盘IO之间的交易关闭。如果由于需要重播更多日志而导致服务器崩溃或故障切换时间延长，服务器可能需要更长时间才能恢复。在Consul 1.1.0和更高版本中，这个默认值为16384，在之前的版本中它被设置为8192。
• -raft-snapshot-interval - 控制服务器检查是否需要将快照保存到磁盘的频率。他是一个很少需要改变的低级参数。遇到磁盘IO过多的非常繁忙的群集可能会增加此值以减少磁盘IO，并最大限度地减少所有服务器同时进行快照的机会。由于日志会变得更大并且raft.db文件中的空间直到下一个快照才能被回收，所以增加这一点会使磁盘空间与磁盘IO之间的交易关闭。如果由于需要重播更多日志而导致服务器崩溃或故障切换时间延长，服务器可能需要更长时间才能恢复。在Consul 1.1.0及更高版本中，这个默认设置为30s，并且在之前的版本中设置为5s。
• -recursor - 指定上游DNS服务器的地址。该选项可以提供多次，功能上与recursors配置选项等效。
• -rejoin - 提供时，领事将忽略先前的休假，并在开始时尝试重新加入集群。默认情况下，Consul将休假视为永久意图，并且在启动时不会再尝试加入集群。该标志允许先前的状态用于重新加入群集。
• -segment - （仅限企业）此标志用于设置代理所属网段的名称。代理只能加入其网段内的其他代理并与其通信。有关更多详细信息，请参阅网络细分指南。默认情况下，这是一个空字符串，它是默认的网段。
• -server - 此标志用于控制代理是否处于服务器或客户端模式。提供时，代理将充当领事服务器。每个Consul集群必须至少有一个服务器，理想情况下每个数据中心不超过5个。所有服务器都参与Raft一致性算法，以确保事务以一致的，可线性化的方式进行。事务修改所有服务器节点上维护的集群状态，以确保节点发生故障时的可用性。服务器节点还参与其他数据中心中服务器节点的WAN八卦池。服务器充当其他数据中心的网关，并根据需要转发流量。
• -non-voting-server - （仅限企业）此标志用于使服务器不参与Raft仲裁，并使其仅接收数据复制流。在需要大量读取服务器的情况下，这可用于将读取可伸缩性添加到群集。
• -syslog - 该标志启用记录到系统日志。这仅在Linux和OSX上受支持。如果在Windows上提供，将会导致错误。
• -ui - 启用内置的Web UI服务器和所需的HTTP路由。这消除了将Consul Web UI文件与二进制文件分开维护的需要。
• -ui-dir - 此标志提供包含Consul的Web UI资源的目录。这将自动启用Web UI。目录必须对代理可读。从Consul版本0.7.0及更高版本开始，Web UI资产包含在二进制文件中，因此不再需要此标志; 仅指定-ui标志就足以启用Web UI。指定’-ui’和’-ui-dir’标志将导致错误。
»配置文件
除了命令行选项之外，配置还可以放入文件中。在某些情况下，这可能更容易，例如使用配置管理系统配置Consul时。
配置文件是JSON格式的，使得它们易于被人类和计算机读取和编辑。该配置被格式化为一个单独的JSON对象，并在其中进行配置。
配置文件不仅用于设置代理，还用于提供检查和服务定义。这些用于向其他群集宣布系统服务器的可用性。它们分别在检查配置和 服务配置下分别记录。服务和检查定义支持在重新加载期间进行更新。
»示例配置文件
{
“datacenter”: “east-aws”,
“data_dir”: “/opt/consul”,
“log_level”: “INFO”,
“node_name”: “foobar”,
“server”: true,
“watches”: [
{
“type”: “checks”,
“handler”: “/usr/bin/health-check-handler.sh”
}
],
“telemetry”: {
“statsite_address”: “127.0.0.1:2180”
}
}
»示例配置文件，带有TLS
{
“datacenter”: “east-aws”,
“data_dir”: “/opt/consul”,
“log_level”: “INFO”,
“node_name”: “foobar”,
“server”: true,
“addresses”: {
“https”: “0.0.0.0”
},
“ports”: {
“https”: 8080
},
“key_file”: “/etc/pki/tls/private/my.key”,
“cert_file”: “/etc/pki/tls/certs/my.crt”,
“ca_file”: “/etc/pki/tls/certs/ca-bundle.crt”
}
尤其请参阅ports设置的使用：
“ports”: {
“https”: 8080
}
除非https已为端口分配了端口号，否则Consul将不会为HTTP API启用TLS > 0。
»配置密钥参考
• acl_datacenter - 这指定了对ACL信息具有权威性的数据中心。必须提供它才能启用ACL。所有服务器和数据中心必须就ACL数据中心达成一致。将它设置在服务器上是集群级别强制执行所需的全部功能，但是为了使API正确地从客户端转发，它必须在其上进行设置。在Consul 0.8和更高版本中，这也可以实现ACL的代理级执行。有关更多详细信息，请参阅ACL指南。
• acl_default_policy - “允许”或“否认”; 默认为“允许”。默认策略在没有匹配规则时控制令牌的行为。在“允许”模式下，ACL是一个黑名单：允许任何未被明确禁止的操作。在“拒绝”模式下，ACL是白名单：任何未明确允许的操作都会被阻止。注意：在您设置acl_datacenter 为启用ACL支持之前，这不会生效。
• acl_down_policy - “允许”，“拒绝”或“扩展缓存”; “扩展缓存”是默认值。如果无法从令牌acl_datacenter或领导者节点读取令牌策略，则应用停机策略。在“允许”模式下，允许所有操作，“拒绝”限制所有操作，“扩展缓存”允许使用任何缓存ACL，忽略其TTL值。如果使用非缓存ACL，“extend-cache”就像“拒绝”一样。
• acl_agent_master_token- 用于访问需要代理读取或写入权限的代理端点或节点读取权限，即使Consul服务器不存在以验证任何令牌。这应该只在运行中断时使用，应用程序通常会使用常规ACL令牌。这是在Consul 0.7.2中添加的，只有在acl_enforce_version_8设置为true 时才会使用 。有关更多详细信息，请参阅 ACL Agent Master Token。
• acl_agent_token - 用于客户端和服务器执行内部操作。如果没有指定，那么 acl_token将被使用。这是在领事0.7.2中添加的。
该令牌至少必须具有对其将注册的节点名称的写入访问权限，以便设置目录中的任何节点级别信息，例如元数据或节点的标记地址。还有其他地方使用了这个令牌，请参阅ACL代理令牌 了解更多详情。
• acl_enforce_version_8 - 用于客户端和服务器，以确定在Consul 0.8之前预览新ACL策略是否应该执行。在Consul 0.7.2中添加，Consul版本在0.8之前默认为false，在Consul 0.8和更高版本中默认为true。这有助于在执行开始前允许策略就位，从而轻松过渡到新的ACL功能。有关更多详细信息，请参阅ACL指南。
• acl_master_token- 仅用于服务器acl_datacenter。如果该令牌不存在，将使用管理级权限创建该令牌。它允许运营商使用众所周知的令牌ID引导ACL系统。
在acl_master_token当服务器获取集群领导只安装。如果您想要安装或更改acl_master_token，请acl_master_token 在所有服务器的配置中设置新值。一旦完成，重新启动当前领导者以强制领导人选举。如果acl_master_token未提供，则服务器不会创建主令牌。当你提供一个值时，它可以是任何字符串值。使用UUID将确保它看起来与其他标记相同，但并非绝对必要。
• acl_replication_token- 仅用于acl_datacenter运行Consul 0.7或更高版本以外的服务器。如果提供，这将启用使用此令牌的ACL复制来检索ACL并将其复制到非权威本地数据中心。在Consul 0.9.1及更高版本中，您可以启用ACL复制enable_acl_replication ，然后使用每台服务器上的代理令牌API设置令牌。如果acl_replication_token在配置中设置，它将自动设置enable_acl_replication为true以实现向后兼容。
如果存在影响授权数据中心的分区或其他中断，并且 acl_down_policy设置为“extend-cache”，则可以使用复制的ACL集在中断期间解析不在缓存中的令牌。有关更多详细信息，请参阅 ACL指南复制部分。
• acl_token - 提供时，代理向Consul服务器发出请求时将使用此令牌。通过提供“？token”查询参数，客户端可以基于每个请求重写此令牌。如果未提供，则会使用映射到“匿名”ACL策略的空令牌。
• acl_ttl - 用于控制ACL的生存时间缓存。默认情况下，这是30秒。此设置会对性能产生重大影响：减少刷新次数会增加刷新次数，同时减少刷新次数。但是，由于缓存不会主动失效，所以ACL策略可能会过时到TTL值。
• addresses - 这是一个允许设置绑定地址的嵌套对象。在Consul 1.0和更高版本中，这些可以设置为要绑定的空间分隔的地址列表 ，也可以将可以解析为多个地址的go-sockaddr模板设置为空格分隔列表。
http支持绑定到Unix域套接字。套接字可以在表单中指定unix:///path/to/socket。一个新的域套接字将在给定的路径上创建。如果指定的文件路径已经存在，Consul将尝试清除该文件并在其位置创建域套接字。套接字文件的权限可以通过unix_socketsconfig结构调整。
在Unix套接字接口上运行Consul agent命令时，使用 -http-addr参数指定套接字的路径。您也可以将所需的值放在CONSUL_HTTP_ADDR环境变量中。
对于TCP地址，变量值应该是端口的IP地址。例如：10.0.0.1:8500而不是10.0.0.1。但是，ports在配置文件中定义端口时，端口将在结构中单独设置 。
以下键有效：
o dns - DNS服务器。默认为client_addr
o http - HTTP API。默认为client_addr
o https - HTTPS API。默认为client_addr
• advertise_addr等同于-advertise命令行标志。
• serf_wan等同于-serf-wan-bind命令行标志。
• serf_lan等同于-serf-lan-bind命令行标志。
• advertise_addr_wan等同于-advertise-wan命令行标志。
• autopilot在Consul 0.8中增加的这个对象允许设置多个子键，这些子键可以为Consul服务器配置操作友好的设置。有关自动驾驶仪的更多信息，请参阅自动驾驶仪指南。
以下子键可用：
o cleanup_dead_servers - 这可以控制定期和每当将新服务器添加到群集时自动删除已死的服务器节点。默认为true。
o last_contact_threshold - 在被认为不健康之前，控制服务器在没有与领导联系的情况下可以走的最长时间。必须是持续时间值，例如10s。默认为200ms。
o max_trailing_logs - 控制服务器在被认为不健康之前可以跟踪领导者的最大日志条目数。默认为250。
o server_stabilization_time - 在添加到集群之前，控制服务器在“健康”状态下必须稳定的最短时间。只有当所有服务器运行Raft协议版本3或更高时才会生效。必须是持续时间值，例如30s。默认为10s。
o redundancy_zone_tag- （仅限企业）-node-meta当Autopilot将服务器分为多个区域进行冗余时，这将控制使用的密钥。每个区域中只有一台服务器可以同时成为投票成员。如果留空（默认），则此功能将被禁用。
o disable_upgrade_migration- （仅限企业）如果设置为true，此设置将禁用Consul Enterprise中的Autopilot升级迁移策略，等待足够的新版本服务器添加到群集，然后再将其中的任何一个升级为选民。默认为false。
• bootstrap等同于 -bootstrap命令行标志。
• bootstrap_expect等同于-bootstrap-expect命令行标志。
• bind_addr等同于 -bind命令行标志。
• ca_file这为PEM编码的证书颁发机构提供了一个文件路径。证书颁发机构用于使用适当的verify_incoming或 verify_outgoing标志检查客户端和服务器连接的真实性。
• ca_path这提供了PEM编码证书颁发机构文件目录的路径。这些证书颁发机构用于检查具有适当verify_incoming或 verify_outgoing标志的客户端和服务器连接的真实性。
• cert_file这提供了一个PEM编码证书的文件路径。证书提供给客户或服务器来验证代理的真实性。它必须随同提供key_file。
• check_update_interval 此间隔控制检查稳定状态检查的输出与服务器同步的频率。默认情况下，它被设置为5分钟（“5米”）。许多处于稳定状态的检查会导致每次运行的输出略有不同（时间戳等），从而导致不断的写入。该配置允许推迟检查输出的同步，以减少给定时间间隔的写入压力。如果支票更改状态，则新状态和相关输出立即同步。要禁用此行为，请将该值设置为“0s”。
• client_addr等同于 -client命令行标志。
• datacenter等同于 -datacenter命令行标志。
• data_dir等同于 -data-dir命令行标志。
• disable_anonymous_signature禁止使用更新检查提供匿名签名以进行重复数据删除。看disable_update_check。
• disable_host_node_id 等同于-disable-host-node-id命令行标志。
• disable_remote_exec 禁用对远程执行的支持。设置为true时，代理将忽略任何传入的远程exec请求。在0.8版之前的Consul版本中，这个默认为false。在Consul 0.8中，默认值更改为true，以使远程exec选择加入而不是选择退出。
• disable_update_check 禁用自动检查安全公告和新版本发布。这在Consul Enterprise中被禁用。
• discard_check_output 在存储之前丢弃健康检查的输出。这减少了健康检查具有易失性输出（如时间戳，进程ID，…）的环境中Consul raft日志的写入次数。
o discovery_max_stale - 为所有服务发现HTTP端点启用陈旧请求。这相当于max_staleDNS请求的 配置。如果此值为零（默认值），则将所有服务发现HTTP端点转发给领导者。如果此值大于零，则任何Consul服务器都可以处理服务发现请求。如果领队服务器超过领导者discovery_max_stale，则将对领导者重新评估该查询以获得更多最新结果。Consul代理还会添加一个新的 X-Consul-Effective-Consistency响应标头，用于指示代理是否执行了陈旧的读取。discover-max-stale 在Consul 1.0.7中引入，作为Consul操作员在代理级别强制来自客户端的陈旧请求的方式，默认值为0，与先前Consul版本中的默认一致性行为相匹配。
• dns_config此对象允许设置多个可以调节DNS查询服务的子密钥。有关更多详细信息，请参阅DNS缓存指南 。
以下子键可用：
o allow_stale - 启用DNS信息的陈旧查询。这允许任何Consul服务器而不仅仅是领导者来服务请求。这样做的好处是您可以通过Consul服务器获得线性读取可扩展性。在0.7之前的Consul版本中，默认为false，意味着所有请求都由领导者提供服务，从而提供更强的一致性，但吞吐量更低，延迟更高。在Consul 0.7及更高版本中，为了更好地利用可用服务器，默认为true。
o max_stale- 什么时候allow_stale 被指定，这是用来限制陈旧结果被允许的。如果领队服务器超过领导者max_stale，则将对领导者重新评估该查询以获得更多最新结果。在领事0.7.1之前，这默认为5秒; 在Consul 0.7.1和更高版本中，默认为10年（“87600h”），这有效地允许任何服务器回答DNS查询，不管它多么陈旧。实际上，服务器通常只比领导者短几毫秒，所以这可以让Consul在没有领导者可以选举的长时间停工场景中继续提供请求。
o node_ttl - 默认情况下，这是“0”，因此所有节点查找均以0 TTL值提供服务。通过设置此值可以启用节点查找的DNS缓存。这应该用“s”后缀表示第二个或“m”表示分钟。
o service_ttl - 这是一个允许使用每项服务策略设置TTL服务查找的子对象。当没有特定的服务可用于服务时，可以使用“”通配符服务。默认情况下，所有服务均以0 TTL值提供服务。通过设置此值可启用服务查找的DNS缓存。
o enable_truncate - 如果设置为true，则将返回超过3条记录或超过适合有效UDP响应的UDP DNS查询将设置截断标志，指示客户端应使用TCP重新查询以获得满载记录集。
o only_passing - 如果设置为true，任何健康检查警告或严重的节点将被排除在DNS结果之外。如果为false，则默认情况下，只有健康检查失败的节点将被排除。对于服务查找，会考虑节点自身的运行状况检查以及特定于服务的检查。例如，如果某个节点的健康状况检查非常重要，则该节点上的所有服务都将被排除，因为它们也被视为关键。
o recursor_timeout - Consul在递归查询上游DNS服务器时使用的超时。查看recursors 更多细节。缺省值是2s。这在Consul 0.7和更高版本中可用。
o disable_compression - 如果设置为true，则不会压缩DNS响应。Consul 0.7中默认添加并启用了压缩。
o udp_answer_limit - 限制包含在基于UDP的DNS响应的答案部分中的资源记录数。此参数仅适用于小于512字节的UDP DNS查询。此设置已弃用，并由Consul 1.0.7替换a_record_limit。
o a_record_limit - 限制A，AAAA或ANY DNS响应（包括TCP和UDP）答案部分中包含的资源记录数。在回答问题时，Consul将使用匹配主机的完整列表，随机随机洗牌，然后限制答案的数量a_record_limit（默认：无限制）。此限制不适用于SRV记录。
在实施和实施RFC 3484第6节规则9的环境中（即DNS答案总是被排序并因此决不是随机的），客户端可能需要设置该值1以保留预期的随机分配行为（注意： RFC 3484已被过时 RFC 6724，因此它应该越来越不常见，需要用现代的解析器来改变这个值）。
• domain等同于 -domain命令行标志。
• enable_acl_replication在Consul服务器上设置时，启用ACL复制而不必通过设置复制令牌acl_replication_token。相反，启用ACL复制，然后在每台服务器上使用代理令牌API引入令牌。查看acl_replication_token更多细节。
• enable_agent_tls_for_checks 当设置时，使用代理人的TLS配置的一个子集（key_file，cert_file，ca_file，ca_path，和 server_name），以建立HTTP客户端的HTTP健康检查。这允许使用代理的凭证检查需要双向TLS的服务。这是在Consul 1.0.1中添加的，默认为false。
• enable_debug设置后，启用一些额外的调试功能。目前，这仅用于设置运行时概要分析HTTP端点。
• enable_script_checks等同于 -enable-script-checks命令行标志。
• enable_syslog等同于-syslog命令行标志。
• encrypt等同于 -encrypt命令行标志。
• encrypt_verify_incoming - 这是一个可选参数，可用于禁用对输入八卦执行加密，以便在正在运行的群集上从未加密的文件升级到加密的八卦。有关更多信息，请参阅此部分。默认为true。
• encrypt_verify_outgoing - 这是一个可选参数，可用于禁用强制执行传出八卦的加密，以便在正在运行的群集上从未加密的文件转换为加密的八卦文件。有关更多信息，请参阅此部分。默认为true。
• disable_keyring_file- 相当于 -disable-keyring-file命令行标志。
• key_file这提供了一个PEM编码私钥的文件路径。密钥与证书一起用于验证代理的真实性。这必须随同提供cert_file。
• http_config 该对象允许为HTTP API设置选项。
以下子键可用：
o block_endpoints 此对象是要在代理程序上阻止的HTTP API端点前缀的列表，默认为空列表，表示所有端点都已启用。与此列表中的一个条目具有共同前缀的任何端点将被阻止，并且在访问时将返回403响应代码。例如，为了阻断所有V1 ACL端点，此设定为 ["/v1/acl"]，这将阻止/v1/acl/create，/v1/acl/update以及与开始其它ACL端点/v1/acl。这只适用于API端点，而不是，/ui或者 /debug必须禁用它们各自的配置选项。任何使用禁用端点的CLI命令都将不再起作用。对于更通用的访问控制，Consul的ACL系统应该被使用，但是这个选项对于完全去除对HTTP API端点的访问是有用的，或者对特定的代理来说是非常有用的。这在Consul 0.9.0及更高版本中可用。
o response_headers 该对象允许向HTTP API响应添加标题。例如，可以使用以下配置在HTTP API端点上启用 CORS：
o {
o “http_config”: {
o “response_headers”: {
o “Access-Control-Allow-Origin”: ""
o }
o }
o }
• leave_on_terminate如果启用，当代理收到TERM信号时，它将向Leave群集的其余部分发送消息并正常离开。此功能的默认行为根据代理是否作为客户端或服务器运行而不同（在Consul 0.7之前默认值被无条件设置为false）。在客户端模式下的代理程序中，默认为true 服务器模式的代理程序，对于服务器模式中的代理程序，缺省为false。
• limits在Consul 0.9.3及更高版本中可用，这是一个嵌套对象，用于配置代理执行的限制。目前，这只适用于客户端模式的代理，而不是Consul服务器。以下参数可用：
o rpc_rate - 通过将此代理允许为Consul服务器发出的RPC请求的最大请求速率设置为每秒请求数，配置RPC速率限制器。默认为无限，这会禁用速率限制。
o rpc_max_burst - 用于对RPC速率限制器进行再充电的令牌桶的大小。默认为1000个令牌，并且每个令牌都适用于对Consul服务器的单个RPC调用。有关 令牌桶速率限制器如何操作的更多详细信息，请参阅https://en.wikipedia.org/wiki/Token_bucket。
• log_level等同于 -log-level命令行标志。
• node_id等同于 -node-id命令行标志。
• node_name等同于 -node命令行标志。
• node_meta可用于Consul 0.7.3及更高版本，此对象允许将任意元数据键/值对与本地节点相关联，然后可用于过滤某些目录端点的结果。有关更多信息，请参阅 -node-meta命令行标志。
• {
• “node_meta”: {
• “instance_type”: “t2.medium”
• }
• }
• performance在Consul 0.7和更高版本中可用，这是一个嵌套对象，允许调整Consul中不同子系统的性能。请参阅服务器性能指南获取更多详细信息 以下参数可用：
o leave_drain_time - 服务器在优雅休假期间居住的时间，以便允许对其他Consul服务器重试请求。在正常情况下，这可以防止客户在执行Consul服务器滚动更新时遇到“无领导者”错误。这是在Consul 1.0中添加的。必须是持续时间值，例如10秒。默认为5秒。
o raft_multiplier - Consul服务器用于缩放关键Raft时间参数的整数乘法器。忽略该值或将其设置为0将使用下面描述的默认时间。较低的值用于收紧时间并提高灵敏度，而较高的值用于放松时间并降低灵敏度。调整这会影响Consul检测领导者失败并执行领导者选举所花的时间，但需要更多的网络和CPU资源才能获得更好的性能。
默认情况下，Consul将使用适用于最小Consul服务器的较低性能时序，当前相当于将此值设置为5（此默认值可能会在未来版本的Consul中进行更改，具体取决于目标最小服务器配置文件是否更改）。将此值设置为1会将Raft配置为其最高性能模式，相当于Consul在0.7之前的默认时间，并且建议用于生产Consul服务器。有关调整此参数的更多详细信息，请参阅上次接触时间的说明。最大允许值是10。
o rpc_hold_timeout - 客户或服务器在领导者选举期间将重试内部RPC请求的持续时间。在正常情况下，这可以防止客户遇到“无领导者”的错误。这是在Consul 1.0中添加的。必须是持续时间值，例如10秒。默认为7秒。
• ports 这是一个嵌套对象，允许为以下键设置绑定端口：
o dns - DNS服务器，-1禁用。默认8600。
o http - HTTP API，-1禁用。默认8500。
o https - HTTPS API，-1禁用。默认-1（禁用）。
o serf_lan - Serf LAN端口。默认8301。
o serf_wan - Serf WAN端口。默认8302.设置为-1以禁用。注意：这将禁用不推荐的WAN联合。各种目录和广域网相关端点将返回错误或空的结果。
o server - 服务器RPC地址。默认8300。
• protocol等同于 -protocol命令行标志。
• raft_protocol等同于 -raft-protocol命令行标志。
• raft_snapshot_threshold等同于 -raft-snapshot-threshold命令行标志。
• raft_snapshot_interval等同于 -raft-snapshot-interval命令行标志。
• reap这将控制Consul的子进程自动收集，如果Consul在Docker容器中以PID 1的形式运行，这将非常有用。如果没有指定，则Consul会自动收集子进程，如果它检测到它正在以PID 1运行。如果设置为true或false，则无论Consul的PID如何，它都会控制收割（强制分别开启或关闭） 。Consul 0.7.1中删除了该选项。对于Consul的更高版本，您将需要使用包装器收获流程，请参阅 Consul Docker图像入口点脚本 以获取示例。如果您使用的是Docker 1.13.0或更高版本，则可以使用该命令的新–init选项，docker run并且docker将启用PID 1的初始化进程，以便为容器收集子进程。有关Docker文档的更多信息。
• reconnect_timeout这将控制从集群中彻底删除发生故障的节点需要多长时间。默认值为72小时，建议将其设置为至少为节点或网络分区的预期可恢复的最大停机时间的两倍。警告：将此时间设置得太低可能会导致Consul服务器在扩展节点故障或分区过程中从法定数中删除，这可能会使群集恢复复杂化。该值是一个带单位后缀的时间，可以是秒，分钟或小时的“s”，“m”，“h”。该值必须> = 8小时。
• reconnect_timeout_wan这是reconnect_timeout参数的WAN等效项，用于控制从WAN池中完全删除发生故障的服务器所需的时间。这也默认为72小时，并且必须> 8小时。
• recursors此标志提供用于递归解析查询（如果它们不在Consul的服务域内）的上游DNS服务器的地址。例如，节点可以直接使用Consul作为DNS服务器，并且如果该记录不在“领事”范围内。域，查询将在上游解决。从Consul 1.0.1开始，递归可以作为IP地址或go-sockaddr模板提供。IP地址按顺序解析，重复项被忽略。
• rejoin_after_leave等同于-rejoin命令行标志。
• retry_join- 相当于-retry-join命令行标志。
• retry_interval等同于 -retry-interval命令行标志。
• retry_join_wan等同于 -retry-join-wan命令行标志。每次尝试加入广域网地址列表，retry_interval_wan直到至少有一个加入工作。
• retry_interval_wan等同于 -retry-interval-wan命令行标志。
• segment（仅限企业）等同于 -segment命令行标志。
• segments（仅限企业）这是一个嵌套对象列表，它允许设置网段的绑定/通告信息。这只能在服务器上设置。有关更多详细信息，请参阅 网络细分指南。
o name - 细分受众群的名称。必须是长度介于1到64个字符之间的字符串。
o bind - 用于分组的八卦图层的绑定地址。-bind如果未提供，则缺省为该值。
o port - 用于细分的八卦图层的端口（必需）。
o advertise - 用于分组的八卦图层的广告地址。-advertise如果未提供，则缺省为该值。
o rpc_listener- 如果为true，则会-bind在rpc端口上的该段地址上启动单独的RPC侦听器。只有段的绑定地址与地址不同时才有效 -bind。默认为false。
• server等同于 -server命令行标志。
• non_voting_server- 相当于 -non-voting-server命令行标志。
• server_name提供时，将覆盖node_nameTLS证书。它可以用来确保证书名称与我们声明的主机名相匹配。
• session_ttl_min 允许的最小会话TTL。这确保会话不会在TTL小于指定的限制时创建。建议将此限制保持在默认值以上，以鼓励客户发送频繁的心跳。默认为10秒。
• skip_leave_on_interrupt这类似于leave_on_terminate但仅影响中断处理。当Consul收到一个中断信号（比如在终端上打Control-C）时，Consul会优雅地离开集群。将其设置为true禁用该行为。此功能的默认行为根据代理是否作为客户端或服务器运行而不同（在Consul 0.7之前默认值被无条件设置为false）。在客户端模式下的代理上，默认为false服务器模式下的代理，并且默认为true （即服务器上的Ctrl-C将服务器保留在群集中，因此是仲裁，并且客户端上的Ctrl-C将优雅地离开）。
• start_join-join启动时指定节点地址的字符串数组。请注意，retry_join在自动执行Consul集群部署时，使用 可能更适合帮助缓解节点启动竞争条件。
• start_join_wan-join-wan启动时指定WAN节点地址的字符串数组。
• telemetry 这是一个嵌套对象，用于配置Consul发送其运行时遥测的位置，并包含以下键：
o circonus_api_token 用于创建/管理支票的有效API令牌。如果提供，则启用度量标准管理。
o circonus_api_app 与API令牌关联的有效应用名称。默认情况下，它被设置为“consul”。
o circonus_api_url 用于联系Circonus API的基本URL。默认情况下，它被设置为“ https://api.circonus.com/v2 ”。
o circonus_submission_interval 指标提交给Circonus的时间间隔。默认情况下，它被设置为“10s”（十秒）。
o circonus_submission_urlcheck.config.submission_url来自先前创建的HTTPTRAP检查的Check API对象 的字段。
o circonus_check_id从先前创建的HTTPTRAP检查中 检查ID（不检查包）。check._cidCheck API对象中字段的数字部分。
o circonus_check_force_metric_activation 强制激活已存在且当前未激活的度量标准。如果启用了支票管理，则默认行为是在遇到新的指标时添加新指标。如果该指标已经存在于支票中，则不会被激活。此设置将覆盖该行为。默认情况下，它被设置为false。
o circonus_check_instance_id 唯一标识来自此实例的度量标准。当它们在基础架构内移动时，它可用于维护度量连续性，即瞬态或短暂实例。默认情况下，它被设置为主机名：应用程序名称（例如“host123：consul”）。
o circonus_check_search_tag 一个特殊的标签，当与实例ID结合使用时，有助于在未提供提交URL或检查ID时缩小搜索结果的范围。默认情况下，它被设置为service：application name（例如“service：consul”）。
o circonus_check_display_name 指定一个名称以在创建时进行检查。该名称显示在Circonus UI Checks列表中。可用于Consul 0.7.2及更高版本。
o circonus_check_tags 用逗号分隔的附加标签列表在创建时添加到支票中。可用于Consul 0.7.2及更高版本。
o circonus_broker_id 创建新支票时使用的特定Circonus Broker的ID。broker._cidBroker API对象中字段的数字部分。如果启用指标管理并且未提供提交URL和检查ID，则将尝试使用实例ID和搜索标记搜索现有检查。如果找不到，则会创建一个新的HTTPTRAP检查。默认情况下，不会使用此选项，并选择随机企业代理或默认的Circonus Public Broker。
o circonus_broker_select_tag 当未提供经纪人代码时，将使用特殊标签选择Circonus经纪人。这个最好的用途是作为代理应该基于针对所使用的提示，其中该特定的实例正在运行（例如一个特定的地理位置或数据中心，DC：SFO）。默认情况下，这是留空，不使用。
o disable_hostname 这将控制是否在计算机主机名的前面加上运行时间遥测，默认为false。
o dogstatsd_addr这提供了格式中DogStatsD实例的地址host:port。DogStatsD是statsd协议兼容的风格，增加了用标签和事件信息修饰指标的功能。如果提供，领事将发送各种遥测信息到该实例进行聚合。这可以用来捕获运行时信息。
o dogstatsd_tags这提供了将被添加到发送到DogStatsD的所有遥测包的全局标签列表。它是一个字符串列表，其中每个字符串看起来像“my_tag_name：my_tag_value”。
o filter_default 这将控制是否允许过滤器未指定的度量标准。默认为true，这将允许在没有提供过滤器时的所有指标。如果设置为false不使用过滤器，则不会发送指标。
o metrics_prefix 写入所有遥测数据时使用的前缀。默认情况下，它被设置为“consul”。这是在Consul 1.0中添加的。对于之前版本的Consul，使用statsite_prefix相同结构中的配置选项。由于此前缀适用于所有遥测提供商，因此它已重新命名为Consul 1.0，而不仅仅是statsite。
o prefix_filter 这是一个过滤规则列表，适用于通过前缀允许/屏蔽指标，格式如下：
o [
o “+consul.raft.apply”,
o “-consul.http”,
o “+consul.http.GET”
o ]
前导的“ + ”将使用给定前缀的任何度量标准，并且前导“ - ”将阻止它们。如果两个规则之间有重叠，则更具体的规则优先。如果多次列出相同的前缀，则阻塞将优先。
o prometheus_retention_time 如果该值大于0s（缺省值），则可以使Prometheus导出度量标准。持续时间可以使用持续时间语义来表示，并将在指定的时间内汇总所有计数器（这可能会影响Consul的内存使用情况）。此参数的价值至少是普罗米修斯刮擦间隔的2倍，但您也可能需要很长的保留时间，例如几天（例如744h才能保留至31天）。使用prometheus获取指标然后可以使用/v1/agent/metrics?format=prometheusURL 执行，或者通过发送值为Accept的Accept头来text/plain; version=0.0.4; charset=utf-8 执行/v1/agent/metrics（如普罗米修斯所做的那样）。格式与普罗米修斯本身兼容。在此模式下运行时，建议启用此选项disable_hostname以避免使用主机名的前缀度量标准。
o statsd_address这以格式提供statsd实例的地址host:port。如果提供，领事将发送各种遥测信息到该实例进行聚合。这可以用来捕获运行时信息。这仅发送UDP数据包，可以与statsd或statsite一起使用。
o statsite_address这提供了格式中的一个statsite实例的地址host:port。如果提供，领事将汇集各种遥测信息到该实例。这可以用来捕获运行时信息。这通过TCP流，只能用于statsite。
• syslog_facility何时 enable_syslog提供，这将控制向哪个设施发送消息。默认情况下，LOCAL0将被使用。
• tls_min_version在Consul 0.7.4中添加，它指定了TLS的最低支持版本。接受的值是“tls10”，“tls11”或“tls12”。这默认为“tls10”。警告：TLS 1.1及更低版本通常被认为不太安全; 避免使用这些如果可能。这将在Consul 0.8.0中更改为默认值“tls12”。
• tls_cipher_suites在Consul 0.8.2中添加，它将支持的密码组列表指定为逗号分隔列表。源代码中提供了所有支持的密码套件列表。
• tls_prefer_server_cipher_suites 在Consul 0.8.2中添加，这将导致Consul更喜欢服务器的密码套件而不是客户端密码套件。
• translate_wan_addrs如果设置为true，Consul 在为远程数据中心中的节点提供DNS和HTTP请求时，会优先使用配置的WAN地址。这允许使用其本地地址在其自己的数据中心内访问该节点，并使用其WAN地址从其他数据中心到达该节点，这在混合网络的混合设置中很有用。这是默认禁用的。
从Consul 0.7和更高版本开始，响应HTTP请求的节点地址在查询远程数据中心中的节点时也将优选节点配置的WAN地址。一个X-Consul-Translate-Addresses当翻译被启用，以帮助客户知道地址可以被翻译标题将出现在所有响应。在TaggedAddresses响应中域也有一个lan地址，需要该地址的知识，无论翻译的客户。
以下端点转换地址：
o /v1/catalog/nodes
o /v1/catalog/node/
o /v1/catalog/service/
o /v1/health/service/
o /v1/query//execute
• ui- 相当于-ui 命令行标志。
• ui_dir- 相当于 -ui-dir命令行标志。从Consul版本0.7.0及更高版本开始，此配置密钥不是必需的。指定此配置键将启用Web UI。没有必要指定ui-dir和ui。指定两者都会导致错误。
• unix_sockets - 这可以调整Consul创建的Unix域套接字文件的所有权和权限。只有在HTTP地址配置了unix://前缀时才使用域套接字。
需要注意的是，这个选项可能对不同的操作系统有不同的影响。Linux通常会观察套接字文件权限，而许多BSD变体会忽略套接字文件本身的权限。在特定的发行版上测试此功能非常重要。此功能目前在Windows主机上无法使用。
以下选项在此构造内有效，并全面应用于Consul创建的所有套接字：
o user - 将拥有套接字文件的用户的名称或ID。
o group - 套接字文件的组ID标识。该选项目前仅支持数字ID。
o mode - 在文件上设置的权限位。
• verify_incoming- 如果设置为true，Consul要求所有传入连接都使用TLS，并且客户端提供证书颁发机构从ca_fileor中签名的证书ca_path。这适用于服务器RPC和HTTPS API。默认情况下，这是错误的，Consul不会强制使用TLS或验证客户的真实性。
• verify_incoming_rpc- 如果设置为true，Consul要求所有传入的RPC连接都使用TLS，并且客户端提供由证书颁发机构从ca_fileor中签名的证书ca_path。默认情况下，这是错误的，Consul不会强制使用TLS或验证客户的真实性。
• verify_incoming_https- 如果设置为true，则Consul要求所有传入的HTTPS连接都使用TLS，并且客户端提供由证书颁发机构从ca_fileor中签名的证书ca_path。默认情况下，这是错误的，Consul不会强制使用TLS或验证客户的真实性。要启用HTTPS API，您必须通过ports配置定义HTTPS端口。默认情况下，HTTPS被禁用。
• verify_outgoing- 如果设置为true，则Consul要求所有传出连接都使用TLS，并且服务器提供由证书颁发机构从ca_fileor中签名的证书ca_path。默认情况下，这是错误的，Consul不会使用TLS进行传出连接。这适用于客户端和服务器，因为两者都会建立传出连接。
• verify_server_hostname - 如果设置为true，则Consul会验证所有传出连接，即服务器提供的TLS证书与“server。。”主机名匹配。这意味着verify_outgoing。默认情况下，这是错误的，并且Consul不验证证书的主机名，只验证它是由受信任的CA签署的。此设置对于防止受损客户端作为服务器重新启动很重要，从而能够执行MITM攻击或添加为Raft对等设备。这在0.5.1中是新的。
• watches - Watches是手表规范的列表，允许在更新特定数据视图时自动调用外部进程。有关更多详情，请参阅 手表文档。手表可以在配置重新加载时修改。
»使用的端口
Consul最多需要6个不同的端口才能正常工作，有些使用TCP，UDP或两种协议。下面我们记录每个端口的要求。
• 服务器RPC（默认8300）。这由服务器用来处理来自其他代理的传入请求。仅限TCP。
• Serf LAN（默认8301）。这是用来处理局域网中的八卦。所有代理都需要。TCP和UDP。
• Serf WAN（默认8302）。这被服务器用来在WAN上闲聊到其他服务器。TCP和UDP。从Consul 0.8开始，建议通过端口8302在LAN接口上为TCP和UDP启用服务器之间的连接，以及WAN加入泛滥功能。另见： Consul 0.8.0 CHANGELOG和GH-3058
• HTTP API（默认8500）。这被客户用来与HTTP API交谈。仅限TCP。
• DNS接口（默认8600）。用于解析DNS查询。TCP和UDP。