当前位置: 首页>数据库>正文

consul 查看 consul_template consul 使用

官网Document https://www.consul.io/docs/index.html 一、介绍
Consul有很多组件,但总的来说,它主要用来发现和配置服务。
(1)服务发现:Consul的客户端可以“provide”一个service,例如api或mysql,其他客户端可以使用Consul来“discover”给定服务的providers。通过DNS或HTTP
(2)健康检查:Consul客户端可以 检查webserver是否返回200 OK,或本地节点的内存使用率是否低于90%,等等。这些信息可以被用来监视集群的健康,也用于服务发现组件在路由时远离不健康的hosts。
(3)Key/Value存储:可以用于动态配置、leader election等等。使用简单的HTTP API使用。
(4)Multi Datacenter(多数据中心):这意味着Consul的使用者们不需要再创建额外的抽象层来扩展Consul了。

Consul是一个分布式的、高可用HA的系统。
每一个向Consul提供服务的节点都运行一个Consul agent。运行这个agent对于发现其他服务或get/set key/value数据不是必须的。这个agent负责健康检查service和node自身。
这个agent和一个或多个Consul server通话。Consul Servers存储着数据并replicated数据。Servers自己会选举一个leader。虽然一个server也可以工作,但是3到5是推荐的,以防止失败时导致数据丢失。
如果你的infrastructure(基础设施)的组件要发现其他服务或节点,可以向任何一个Consul server或任何一个Consul agent查询,agent会自动转发请求到servers。
每个Datacenter都运行着一个ConsulServer的集群。当一个跨集群的service discovery或configuration request来到时,本地的Consul servers会转发请求到远端的Datacenter并返回结果。

二、GettingStarted
1、下载zip包 https://www.consul.io/downloads.html 2、安装:解压、拷贝consul文件到任何的PATH路径中以方便它可以直接被执行,例如 /usr//local/bin。

三、运行agent:
(1)启动consul:
consul agent -dev #以dev模式运行,这种模式启动一个单节点的Consul环境,它不适用于生产环境。因为不持久化任何state。
consul agent -server #以server模式启动,
consul agent #默认是以client模式运行,client非常轻量级,它注册服务、运行healthchecks、转发query到servers。agent必须运行于集群上的每一个节点。
consul agent -dev -config-dir /etc/consul.d #或-config-file。指定配置文件夹,Consul会加载其中的所有文件。配置文件是json格式,除了提供启动agent时的命令行选项外,还用来提供check和service定义。

kill -HUP ${consulPid} #重新载入配置文件。
consul reload #重新载入配置文件。

(2)关闭consul:
consul leave #关闭consul并离开集群。也可以使用Ctrl+C或kill -INT来gracefully停止agent,这种体面的离开方式让consule可以有机会通知集群其他成员自己的离开。如果你强制地结束了agent,其他member会检测到这个节点的failed。当成员离开时,它的services和checks都会从catalog中移除。当成员failed时,它的health只是简单的被标记为critical,并不会从catalog中移除。Consul会自动尝试重新连接failed节点,允许它从恶劣的网络环境中恢复,显然离开的nodes不会被重新连接。另外,如果这个节点是server,体面的离开对避免潜在的中断的可能很重要。
为了防止dead nodes的积累,consul会自动把dead nodes移除出catalog。这个过程被称为reaping(收割)。默认是72小时的间隔(不建议更改)

(3)consul集群:

consul集群:当一个consul agent启动后,它不知道任何其他节点,要学习到集群中的其他节点,agent必须加入一个已经存在的集群(cluster)。要加入这样的集群,它只需要知道这个集群中的一个节点即可。它加入后,将会和这个member gossip(交谈)并迅速发现集群中的其他节点。一个consul agent可以加入任何类型的其他agent,而不只是那些运行于server mode的agent。

server节点的启动:

consul agent -server -bootstrap-expect 1 -node=agent-one -bind=10.0.209.123 -data-dir /tmp/consul -config-dir /etc/consul.d

-server 以server模式运行

-bootstrap-expect n:表示期望有多少个server nodes加入。这个选项的目的是delay the bootstrapping of the replicated log 直到所有的server都成功加入

-node=node-name 集群中的每个node必须有一个唯一的名称。默认情况下,Consul使用机器的hostname

-bind=ip 表示Consul监听的地址,而且它必须能够被集群中的其他节点访问。Consul默认会监听第一个private IP,但最好还是提供一个。生产设备上的服务器通常有好几个网卡,所以指定一个不会出错

-data-dir 指定数据目录

-config-dir指定配置文件夹,Consul会加载其中的所有文件

-datacenter 指定数据中心名称,默认是dc1

client节点的启动

consul agent -node=agent-two -bind=10.0.209.122 -data-dir /tmp/consul -config-dir /etc/consul.d

consul members # 现在你有了两个运行中的agent,一个server,一个client。分别在两个节点上运行这个命令,可以看到现在他们还不知道彼此。
consul join 10.0.209.122 #加入集群:现在我们告诉第一个agent加入第二个agent
consul members # 现在看看集群中有2个节点了

那如何在启动时自动加入一个cluster呢?

consul agent ... -join 1.1.1.1 1.1.1.2 #或-retry-join

或者在配置文件中使用 start_join

(4)查询节点:
consul members #查询集群成员
dig @127.0.0.1 -p 8600 agent-two.node.consul #查询节点
dig @127.0.0.1 -p 8600 agent-two.node.[DATACENTER].consul curl http://127.0.0.1:8500/v1/catalog/nodes #通过API的方式查询节点 curl http://127.0.0.1:8500/v1/catalog/node/agent-two

(5)服务声明和查询:

注:虽然这里使用的是通过文件声明服务,但一般都是使用 HTTP API 动态地增加、移除和修改services。

consul agent -dev -config-dir /etc/consul.d # -config-dir指定配置文件夹,Consul会加载其中的所有文件 # echo '{"service": {"name": "web", "port": 80, "tags": ["rails"]}}' >/etc/consul.d/web.json #定义一个服务“web” consul reload #重新载入配置文件

dig @127.0.0.1 -p 8600 web.service.consul #查询web服务 (如果没有dig命令,请yum install bind-utils) dig @127.0.0.1 -p 8600 rails.web.service.consul #通过tags来过滤services curl http://127.0.0.1:8500/v1/catalog/services curl http://127.0.0.1:8500/v1/catalog/service/web #通过HTTP API方式查询web服务 curl 'http://127.0.0.1:8500/v1/health/service/web?passing #使用健康状态过滤服务

(6)健康检查:

定义 Checks

一个检查可以通过提供一个check定义文件或调用HTTP API来注册

这里介绍使用check定义文件的方式

echo '{"check": {"name": "ping","script": "ping -c1 google.com >/dev/null","interval": "30s"}}' >/etc/consul.d/ping.json

echo '{"service": {"name": "web", "tags": ["rails"], "port": 80,"check": {"script":"curl 127.0.0.1 >/dev/null 2>&1", "interval": "10s"}}}' >/etc/consul.d/web.json

第一个definition增加了一个host-level check,名字为ping。这个check每30秒运行一次,调用ping -c1 google.com . 基于脚本的健康检查,在运行脚本时使用的用户就是启动consul agent的用户。如果脚本以非0值退出,那么这个node被标记为unhealthy。

第二个definition修改了web service,增加了一个check,每10秒运行一次,使用curl来验证web server是否可访问。如果脚本以非0值退出,那么这个service被标记为unhealthy。

consul reload #重新载入配置文件

然后我们可以看到service.web is now critical,因为实际上我们还没有在第二个节点上运行web server,check失败了。

curl http://127.0.0.1:8500/v1/health/state/critical #使用HTTP API来查询,这里是查询所有的failing checks。
dig @127.0.0.1 -p 8600 web.service.consul #结果查询不到unhealthy的service。

(7)KEY/VALUE存储:
curl -v http://127.0.0.1:8500/v1/kv/?recurse #因为现在还没有值,所以不会返回任何内容,使用-v参数是为了让你看看返回的详细信息
curl -X PUT -d 'test' http://127.0.0.1:8500/v1/kv/web/key1 #增加键web/key1,值为test
curl -X PUT -d 'test' http://127.0.0.1:8500/v1/kv/web/key2?flags=42 #增加键web/key2=test,同时指定flags=42,flags默认值是0,flags值可以是一个64位的整数值,flags对于Consul没有任何意义,但你可以将他作为有意义的metadata
curl http://127.0.0.1:8500/v1/kv/?recurse #现在再查询可以看到返回结果中value为base64编码后的值,这是为了允许一些non-UTF8的字符。

?recurse表示取得遍历所有的key的值,在删除时也一样

curl http://127.0.0.1:8500/v1/kv/web/key1 #单个key的查询

curl -X DELETE http://127.0.0.1:8500/v1/kv/web/sub?recurse #删除

curl -X PUT -d 'newval' http://127.0.0.1:8500/v1/kv/web/key1?cas=97 curl -X PUT -d 'newval' http://127.0.0.1:8500/v1/kv/web/key1?cas=97

更新值时consul提供了一个Check-and-Set操作,通过使用?cas=[ModifyIndex],这个值在get的结果里通过 ModifyIndex提供。如果该值不是get结果里的 ModifyIndex ,那么更新操作将失败。

例如上面的例子中,假设当前的web/key1的ModifyIndex是97,那么第一次更新成功,第二次更新就会失败。

curl "http://127.0.0.1:8500/v1/kv/web/key2?index=101&wait=5s" #表示等待web/key2的ModifyIndex大于等于101,并且最多等5秒,然后返回当前的值

另外,查询是还可以指定?dc=xx,默认是查询agent所在的Datacenter,注意到每个Datacenter都有自己的kv系统,并且没有内置的replication。

四、consul cli:
consul -v #查看consul版本
consul info #提供了各种debugging信息,这些信息对operator会有用的。

consul reload:触发重新加载配置文件。等于kill -1或kill -HUP

consul configtest -config-file 或 -config-dir #只验证配置文件,不真正启动agent。

consul join 10.0.209.123 10.0.209.124 #可以指定多个node
consul leave #优雅的离开并shutdown
consul force-leave #强制集群中某个member进入“left”状态。注意,如果member实际上还是alive,它会rejoin the cluster。这个方法的真正意图是强制移除那些“failed”的节点。

consul members:
consul monitor #用来连接一个运行中的consul agent,并follow它的logs。这个命令的强大之处在于你可以使用一个非常高的log level(例如warn)来追踪日志,
consul monitor -log-level trace/debug/info/warn/err

consul kv delete/export/get/import/put #kv操作

consul event #fire一个自定义的user event到整个Datacenter。它们可以用于自动化部署、重启services、或执行其他协同动作。events可以通过使用watch的方式被处理。 event通过gossip协议传播,不保证一定传播到。不像其他的大部分consul data(它们都通过consensus协议被replicated),event数据是通过gossip 一点一点传播的。这意味着它没有被持久化并且没有顺序(例如fire两个event,不代表后面fire的就一定后收到)。 同时event的payload也有限制,但是没有一个准确的值,一般应该小于100bytes。

consul exec #在集群中所有的节点上远程执行并返回命令回显。例如,可以运行uptime命令在所有提供web service的机制上。 远程执行通过在KV中存储一个job,然后通过event系统通知节点有新的job并执行。 注意命令的输出结果不要太多,输出结果也是存储在KV中,如果有一个大的集群,这可能会让集群不可达。

consul keygen
consul keyring

consul lock #提供了一种简单的分布式锁机制。锁或semaphore通过给定的前缀在KV里创建,并且只有持有时,子进程才调用。如果lock丢失了或通信破坏了,子进程就被终止了。

consul maint #提供了对service和node的maintenance mode的control。使用这个命令,可以 标记某个节点提供的一个service或者某个节点整体为“under maintenance” 。在这种模式下,service和node将不会出现在DNS查询结果里或API结果里。实际上这让service或node离开了available “healthy” nodes 池。 实际上,maintenance mode是在health check为critical status时激活,取消注册health check后去激活。

consul operator #提供集群级别的工具,例如与Raft subsystem交互。使用这个命令要特别特别小心。因为不适当的使用可能导致Consul中断甚至丢失数据。

consul rtt #估算两个节点之间网络往返时间。round trip time

consul watch #监控一个节点的data view(list of nodes,services members,key value等等)的变化,并且调用一个进程(使用data view的最新的数据)。如果没有指定process,当前值会被dumped到stdout。

五、HTTP API: https://www.consul.io/docs/agent/http.html 1、所有的API路径的前缀都是 /v1/ 。这个文档也只是介绍 v1 API。例如:
http://10.245.6.90:8500/v1/agent/members 2、有些 endpoints 使用或需要 ACL token 来操作。虽然agent可以被配置为使用默认的token,但是token可以在每次请求时都指定,通过在请求的Header里加入 X-Consul-Token 的值 或 在请求url中加入 token 参数(优先级最高)。但是推荐使用请求头里加入Header的方式。
3、当启用了authentication(认证)时,就应该在请求中传递token。下面是一个例子:
curl --header "X-Consul-Token: abcd1234" https://10.245.6.90:8500/v1/agent/members 4、很多(但不是所有的)endpoints都支持阻塞查询特色。支持该特色的endpoints会在response的HTTP header里包含一个 X-Consul-Index 的key。这个key标识了请求资源的当前状态。 然后在接下来的查询里可以在请求头里加入这个 X-Consul-Index key,表示你想等待任何在这个key表示的index之后的更改后的资源值。
5、一致性模型(consistency modes):很多查询的endpoints都支持多个级别的一致性。模型有:

  • default : 如果没有指定,default一般都是强一致的。除了短暂的leader重选时的空窗期。
  • consistent : 一般不要使用这种模式,除非你实在不能忍受 a stale read。
  • stale : 这个模式允许任意的server来服务读请求,而不管它是不是leader。这意味着read可以任意的stale(不新鲜)。然而一般来说result都会在50ms内被同步完成。
    要想切换这些模式,应该在请求url中提供 stale 或 consistent 参数,如果同时提供会报错。
    为了支持数据的staleness不新鲜程度,response的HTTP Header中会包含 X-Consul-LastContact(表示最近和leader node的通信时间毫秒数)、X-Consul-KnownLeader(表明是否有已知的leader) 字段。这些数据可以被client用来判断数据的不新鲜程度并作出相应的动作决策。
    6、默认情况下,所有的response输出都是最小化的JSON格式的。如果请求url中传递了pretty参数,会返回格式化的JSON数据。
    7、HTTP 方法:Consul的API目标是RESTful,虽然有一些例外。API响应标准的HTTP GET、PUT、DELETE方法。例子:
    curl --request PUT --data 'hello world!' https://consul.rocks/v1/kv/foo 8、有些库文件可以用来更方便的调用API。一些是官方的,一些是第三方提供的。
    https://www.consul.io/api/libraries-and-sdks.html 9、具体的API请自行查看。
    10、一些常用的:
    agent相关的API

列出所有的members

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

列出所有注册到本地agent的checks,本地知道的checks可能和catalog报告的不一致。

curl http://10.245.6.90:8500/v1/agent/checks

注册check到本地agent。checks可以是script、HTTP、TCP或TTL 类型。agent负责管理check的状态并同步到catalog。

curl --request PUT --data @payload.json http://10.245.6.90:8500/v1/agent/check/register

取消注册check到本地agent。agent会小心的从catalog中取消注册check。如果提供的check ID不存在,则不采取任何动作

curl --request PUT http://10.245.6.90:8500/v1/agent/check/deregister/:check_id

TTL check pass

curl http://10.245.6.90:8500/v1/agent/check/pass/:check_id

TTL check warn

curl http://10.245.6.90:8500/v1/agent/check/warn/:check_id

TTL check fail

curl http://10.245.6.90:8500/v1/agent/check/fail/:check_id

TTL check update

curl http://10.245.6.90:8500/v1/agent/check/update/:check_id

列出所有注册到本地agent的服务

curl http://10.245.6.90:8500/v1/agent/services

注册服务到本地agent、可以同时提供健康检查。agent负责管理服务的状态,并同步到global catalog

curl --request PUT --data @payload.json http://10.245.6.90:8500/v1/agent/service/register

取消注册服务到本地agent,如果服务不存在,则不采取任何动作。agent负责从catalog中删除该服务。如果该服务关联了一个check,那么check也会被删除。

curl --request PUT http://10.245.6.90:8500/v1/agent/service/deregister/:service_id

将服务设置为maintenance mode,这个模式下的服务被标记为不可达而且对外不可见。而且服务的这个状态会被持久化,当agent重启时服务也会自动恢复到这个状态。

curl --request PUT http://10.245.6.90:8500/v1/agent/service/maintenance/:service_id

catalog相关的API

注册Entity,是较低级别的注册或更新entries到catalog。一般都是使用agent endpoints来注册。

curl --request PUT --data @payload.json http://10.245.6.90:8500/v1/catalog/register

取消注册Entity,

curl --request PUT --data @payload.json http://10.245.6.90:8500/v1/catalog/register

列出所有的datacenters

curl http://10.245.6.90:8500/v1/catalog/datacenters

列出所有的nodes

curl http://10.245.6.90:8500/v1/catalog/nodes

列出所有的服务

curl http://10.245.6.90:8500/v1/catalog/services

列出提供某服务的所有节点

curl http://10.245.6.90:8500/v1/catalog/service/:service

列出提供某节点提供的所有服务 :node是"Node"字段的值 不是"ID"的值

curl http://10.245.6.90:8500/v1/catalog/node/:node

KV相关的API

读取 Key 的值

curl http://10.245.6.90:8500/v1/kv/:key

创建/更新 key ,返回的内容只有true或false

curl --request PUT --data 'xxx' http://10.245.6.90:8500/v1/kv/:key

删除key ,返回的内容只有true或false

curl --request DELETE http://10.245.6.90:8500/v1/kv/:key

Health相关的API

列出某个节点的所有Checks

curl http://10.245.6.90:8500/v1/health/node/:node

列出某服务的所有Checks

curl http://10.245.6.90:8500/v1/health/checks/:service

列出某服务的所有节点

curl http://10.245.6.90:8500/v1/health/service/:service

列出某状态的所有Checks

curl http://10.245.6.90:8500/v1/health/state/:state

六、consul agent 启动选项和配置文件: https://www.consul.io/docs/agent/options.html 七、使用的端口:
8300:TCP # Server RPC :agent server 使用的,用于处理其他agent发来的请求
8301:TCP and UDP # Serf LAN: 所有的agent都要使用这个端口,用于处理LAN中的gossip,
8302:TCP and UDP # Serf WAN:agent Server使用的,处理WAN中的与其他server的gossip
8400:TCP # 所有agent都要使用的端口,用于处理从CLI来的RPC。
8500:TCP # 所有agent都要使用的端口,用于处理HTTP API。
8600:TCP and UDP # 用于处理 DNS 查询。



https://www.xamrdz.com/database/6kx1944551.html

相关文章: