consul学习与常用命令和使用教程

consul学习与常用命令和使用教程

目录

一级目录

二级目录

三级目录consul是什么常用命令API实例1：新建服务API注册服务查询服务

一级目录 二级目录 三级目录 consul是什么

Consul是分布式的、高可用的、 可横向扩展的用于实现分布式系统的服务发现与配置。consul就是提供服务发现的工具。
做服务发现的框架常用的有

zookeepereurekaetcdconsul。

服务A-N把当前自己的网络位置注册到服务发现模块（这里注册的意思就是告诉），服务发现就以K-V的方式记录下，K一般是服务名，V就是IP:PORT。服务发现模块定时的轮询查看这些服务能不能访问的了（这就是健康检查）。客户端在调用服务A-N的时候，就跑去服务发现模块问下它们的网络位置，然后再调用它们的服务。这样的方式是不是就可以解决上面的问题了呢？客户端完全不需要记录这些服务网络位置，客户端和服务端完全解耦！
CLIENT
CLIENT表示consul的client模式，就是客户端模式。是consul节点的一种模式，这种模式下，所有注册到当前节点的服务会被转发到SERVER，本身是不持久化这些信息。
SERVER
SERVER表示consul的server模式，表明这个consul是个server，这种模式下，功能和CLIENT都一样，唯一不同的是，它会把所有的信息持久化的本地，这样遇到故障，信息是可以被保留的。
SERVER-LEADER
中间那个SERVER下面有LEADER的字眼，表明这个SERVER是它们的老大，它和其它SERVER不一样的一点是，它需要负责同步注册的信息给其它的SERVER，同时也要负责各个节点的健康监测。

常用命令

命令行打开

consul agent -dev #该命令启动只能允许本机访问
consul agent -dev -client 0.0.0.0  # 加上-client 0.0.0.0就可以其他机器进行访问了

进入consulserver容器

 kubectl exec -it consul-server-0 -- /bin/sh

查看成员

consul members

查看版本号

consul  version

列出所有服务

consul catalog services -http-addr=localhost:8500

API

官方文档

获取member

	curl http://127.0.0.1:8500/v1/agent/members

/v1/agent/checks : 返回本地agent注册的所有检查(包括配置文件和HTTP接口)
/v1/agent/services : 返回本地agent注册的所有 服务
/v1/agent/members : 返回agent在集群的gossip pool中看到的成员
/v1/agent/self : 返回本地agent的配置和成员信息
/v1/agent/join/

: 触发本地agent加入node
/v1/agent/force-leave/>: 强制删除node
/v1/agent/check/register : 在本地agent增加一个检查项，使用PUT方法传输一个json格式的数据
/v1/agent/check/deregister/ : 注销一个本地agent的检查项
/v1/agent/check/pass/ : 设置一个本地检查项的状态为passing
/v1/agent/check/warn/ : 设置一个本地检查项的状态为warning
/v1/agent/check/fail/ : 设置一个本地检查项的状态为critical
/v1/agent/service/register : 在本地agent增加一个新的服务项，使用PUT方法传输一个json格式的数据

实例1：新建服务API

curl http://127.0.0.1:8500/v1/agent/service/register -X PUT -i -H "Content-Type:application/json" -d '{
  "ID": "userServiceId",  
  "Name": "userService",
  "Tags": [
    "primary",
    "v1"
  ],
  "Address": "127.0.0.1",
  "Port": 8000,
  "EnableTagOverride": false,
  "Check": {
    "DeregisterCriticalServiceAfter": "90m",
    "HTTP": "http://www.baidu.com",
    "Interval": "10s"
  }
}'

查询服务

curl http://127.0.0.1:8500/v1/catalog/service/userService

注册服务

新建个文件夹存放服务的配置

sudo mkdir /etc/consul.d

在consul.d里面我们新建一个配置

echo '{"service": {"name": "web", "tags": ["rails"], "port": 80}}' | sudo tee /etc/consul.d/web.json

重新启动代理程序，提供配置目录

consul agent -dev -config-dir=/etc/consul.d -client 0.0.0.0 

您会注意到它在输出中“同步”了Web服务。 这意味着代理程序从配置文件加载了服务定义，并已成功将其注册到服务目录中。 　　如果您想注册多个服务，您可以在Consul配置目录中创建多个服务定义文件。

查询服务

一旦代理启动并且服务同步，我们可以使用DNS或HTTP API来查询服务。
DNS API
我们首先使用DNS API来查询我们的服务。 对于DNS API，服务的DNS名称是NAME.service.consul。 默认情况下，所有DNS名称始终在consul命名空间中，尽管这是可配置的。 服务子域告诉Consul我们正在查询服务，NAME是服务的名称。 　　对于我们注册的Web服务，这些约定和设置会生成web.service.consul的完全限定的域名：

dig @127.0.0.1 -p 8600 web.service.consul

正如你所看到的，一个A记录返回了服务可用的节点的IP地址。 A记录只能保存IP地址。 　　您也可以使用DNS API来检索整个地址/端口对作为SRV记录：

dig @127.0.0.1 -p 8600 web.service.consul SRV

SRV记录表示Web服务正在端口80上运行，并且存在于节点zp.local.node.dc1.consul.上。DNS使用该记录的A记录返回附加部分。最后，我们也可以使用DNS API来按标签过滤服务。 基于标记的服务查询的格式是TAG.NAME.service.consul。 在下面的例子中，我们向Consul询问所有带有“rails”标签的web服务。 自从我们使用该标签注册我们的服务后，我们得到了成功的回应。

dig @127.0.0.1 -p 8600 rails.web.service.consul

HTTP API

除了DNS API之外，HTTP API还可以用来查询服务：

curl http://localhost:8500/v1/catalog/service/web

目录API提供了托管给定服务的所有节点。 正如我们稍后将看到的健康检查一样，您通常只需要查询检查通过的健康实例。 这是DNS正在做的事情。 这是一个查询只查找健康的实例：

curl http://localhost:8500/v1/health/service/web?passing

参考链接：
https://blog.csdn.net/qq_34495753/article/details/88633562
https://zhuanlan.zhihu.com/p/361869606