Consul 入门指南

Consul 由HashiCorp用 GO 开发的服务发现、配置管理中心服务

• 让服务发现和配置管理更容易。
• 分布式、高可用、跨数据中心。

服务发现

Consul 让服务注册和服务发现（通过 DNS 和 HTTP 接口）更加简单，甚至对于外部服务（例如 SaaS）注册也一样。

故障检测

通过健康检查，服务发现可以防止请求被路由到不健康的主机，并且可以使服务容易断开（不再提供服务）。

多数据中心

Consul 不需要复杂的配置即可简便的扩展到多个数据中心，查找其它数据中心的服务或者只请求当前数据中心的服务。

键值存储

灵活的键值存储，提供动态配置、特征标记、协作、leader 选举等功能，通过长轮询实现配置改变的即时通知。

基本概念

Agent
组成 consul 集群的每个成员上都要运行一个 Agent，可以通过 consul agent 命令来启动。Agent 可以运行在 Server 模式或者 Client 模式。每一个数据中心至少要有一个 Server，不过一个集群推荐要有 3-5 个 Server。单一 Server 的部署将非常令人沮丧，因为在故障场景下数据丢失将无法避免。

Client 节点
一个 Client 是一个非常轻量级的进程，用来注册服务，运行健康检查，以及转发查询到 Server。
Client 本身无状态，且轻量级，因此，可以部署大量的 Client 节点。

Server 节点
负责组成 cluster 的复杂工作（选举、状态维护、转发请求到 lead），以及 consul 提供的服务（响应 RCP 请求）。考虑到容错和收敛，一般部署 3 ~ 5 个比较合适。

Datacenter
多机房使用的数据共享

安装

官方下载页面https://www.consul.io/downloads.html

wget https://releases.hashicorp.com/consul/1.0.7/consul_1.0.7_linux_amd64.zip
unzip consul_1.0.7_linux_amd64.zip
cp consul /usr/bin/

Agent

运行 Agent

启动单节点

consul -dev

启动 Server 节点

consul -server -bootstrap-expect 1 -data-dir /tmp/consul

启动 Client 节点

consul agent -join 192.168.90.99 -bind 192.168.90.90 -data-dir .\consul_data -ui

常用参数

参数	描述
-bootstrap	用来控制一个 server 是否在 bootstrap 模式，在一个 datacenter 中只能有一个 server 处于 bootstrap 模式，当一个 server 处于 bootstrap 模式时，可以自己选举为 raft leader。
-bootstrap-expect	在一个 datacenter 中期望提供的 server 节点数目，当该值提供的时候，consul 一直等到达到指定 sever 数目的时候才会引导整个集群，该标记不能和 bootstrap 共用
-bind	该地址用来在集群内部的通讯，集群内的所有节点到地址都必须是可达的，多网卡可能需要手动指定，默认是 0.0.0.0
-client	绑定客户端接口的地址，包括 HTTP 和 DNS 服务，默认情况下是 127.0.0.1，在 1.0 和之后，可以将其设置为以空格分隔的地址列表
-config-file	加载配置文件，如果它被指定了多次，稍后加载的配置文件将与前面加载的配置文件合并。
-config-dir	配置文件目录，里面所有以.json 结尾的文件都会被加载
-data-dir	提供一个目录用来存放 agent 的状态，所有的 agent 都需要该目录，该目录必须是稳定的，系统重启后都继续存在
-datacenter	运行的数据中心的名称，默认是 dc1，同一数据中心中的节点应该在一个局域网中。
-encrypt	指定 secret key，使 consul 在通讯时进行加密，key 可以通过consul keygen生成，同一个集群中的节点必须使用相同的 key
-join	加入一个已经启动的 agent 的 ip 地址，可以多次指定多个 agent 的地址。如果 consul 不能加入任何指定的地址中，则 agent 会启动失败，默认 agent 启动时不会加入任何节点。请注意，在自动化 consul 集群部署时，使用 retryjoin 可能更适合于帮助缓解节点启动竞争条件。
-retry-join	和 join 类似，但是允许你在第一次失败后进行尝试。如果给出了多个值，那么它们将按照所列出的顺序进行重试和重试，直到有一个成功为止。在 0.9.1 中，retry-join 使用go-discover库接受一个统一的接口，用于使用云元数据进行自动集群连接。
-retry-interval	两次 join 之间的时间间隔，默认是 30s
-retry-max	尝试重复 join 的次数，默认是 0，也就是无限次尝试
-log-level	consul agent 启动后显示的日志信息级别。默认是 info，可选：trace、debug、info、warn、err。
-node	指定节点在集群中的名称，在一个集群中必须是唯一的，默认是该节点的主机名
-protocol	consul 使用的协议版本，默认是使用最新版本，通过consul -v可以查看支持的协议版本
-rejoin	使 consul 忽略先前的离开，在再次启动后仍旧尝试加入集群中。
-server	定义 agent 运行在 server 模式，每个集群至少有一个 server，建议每个集群的 server 不要超过 5 个
-ui	启用内置的 web UI 服务器和所需的 HTTP 路由。

官方配置说明 https://www.consul.io/docs/agent/options.html

查看集群成员

consul members

查看当前状态

consul info

查看日志

consul monitor [-log-level=<string>]

服务注册与发现

服务发现的主要目标之一是提供可用服务的目录。为了达到这个目的，Agent 提供了一个简单的服务定义格式来声明服务的可用性，并可能将其与健康检查联系起来。如果与服务相关联，健康检查被认为是应用程序级别。

服务是在配置文件中定义的，或者在运行时通过 HTTP 接口添加。

配置文件注册

启动 Agent 通过配置-config-dir参数加载服务配置

mkdir /etc/consul.d
echo '{"service": {"name": "web", "tags": ["rails"], "port": 80}}' > /etc/consul.d/web.json
consul agent -dev -config-dir /etc/consul.d

配置单个服务

{
  "service": {
    "name": "redis",
    "tags": ["primary"],
    "address": "",
    "port": 8000,
    "enable_tag_override": false,
    "checks": [
      {
        "script": "/usr/local/bin/check_redis.py",
        "interval": "10s"
      }
    ]
  }
}

服务定义必须包括一个 name，并且可以选择性地提供一个 id, tags, address, port, check, 和 enable_tag_override。如果没有提供，name 即为 id。所有服务都必须有每个节点的唯一 ID，因此如果名称可能冲突，那么应该提供唯一的 ID。

配置多个服务

{
  "services": [
    {
      "id": "red0",
      "name": "redis",
      "tags": [
        "primary"
      ],
      "address": "",
      "port": 6000,
      "checks": [
        {
          "script": "/bin/check_redis -p 6000",
          "interval": "5s",
          "ttl": "20s"
        }
      ]
    },
    {
      "id": "red1",
      "name": "redis",
      "tags": [
        "delayed",
        "secondary"
      ],
      "address": "",
      "port": 7000,
      "checks": [
        {
          "script": "/bin/check_redis -p 7000",
          "interval": "30s",
          "ttl": "60s"
        }
      ]
    },
    ...
  ]
}

API 注册

方法	接口	描述
PUT	/v1/agent/service/register	注册 service

参数示例：

{
  "ID": "redis1",
  "Name": "redis",
  "Tags": ["primary", "v1"],
  "Address": "127.0.0.1",
  "Port": 8000,
  "Meta": {
    "redis_version": "4.0"
  },
  "EnableTagOverride": false,
  "Check": {
    "DeregisterCriticalServiceAfter": "90m",
    "Args": ["/usr/local/bin/check_redis.py"],
    "HTTP": "http://localhost:5000/health",
    "Interval": "10s",
    "TTL": "15s"
  }
}

发现服务

方法	接口	描述
GET	/v1/catalog/service/:service_name	获取服务的所有节点
GET	/v1/catalog/node/:node_name	获取节点的所有服务
GET	/v1/agent/services	获取所有服务

注销服务

方法	接口	描述
PUT	/v1/agent/service/deregister/:service_id	注销服务

更多请查看官方接口文档https://www.consul.io/api/index.html

Consul Template

Consul-Template 是基于 Consul 的自动替换配置文件的应用。在 Consul-Template 没出现之前，大家构建服务发现系统大多采用的是 Zookeeper、Etcd+Confd 这样类似的系统。

Consul 官方推出了自己的模板系统 Consul-Template 后，动态的配置系统可以分化为 Etcd+Confd 和 Consul+Consul-Template 两大阵营。Consul-Template 的定位和 Confd 差不多，Confd 的后端可以是 Etcd 或者 Consul。

Consul-Template 提供了一个便捷的方式从 Consul 中获取存储的值，Consul-Template 守护进程会查询 Consul 实例来更新系统上指定的任何模板。当更新完成后，模板还可以选择运行一些任意的命令。

参考

• 服务发现比较:Consul vs Zookeeper vs Etcd vs Eureka
• Consul 中文翻译
• 深入学习 consul
• 通过 Consul-Template 实现动态配置服务