4.6 KiB
title |
---|
consul_kv |
Summary
For users who used nginx-upsync-module and consul key value for service discovery way, as we Weibo Mobile Team, maybe need it.
Thanks to @fatman-x guy, who developed this module, called consul_kv
, and its worker process data flow is below:
Configuration for discovery client
Configuration for Consul KV
Add following configuration in conf/config.yaml
:
discovery:
consul_kv:
servers:
- "http://127.0.0.1:8500"
- "http://127.0.0.1:8600"
prefix: "upstreams"
skip_keys: # if you need to skip special keys
- "upstreams/unused_api/"
timeout:
connect: 1000 # default 2000 ms
read: 1000 # default 2000 ms
wait: 60 # default 60 sec
weight: 1 # default 1
fetch_interval: 5 # default 3 sec, only take effect for keepalive: false way
keepalive: true # default true, use the long pull way to query consul servers
default_server: # you can define default server when missing hit
host: "127.0.0.1"
port: 20999
metadata:
fail_timeout: 1 # default 1 ms
weight: 1 # default 1
max_fails: 1 # default 1
And you can config it in short by default value:
discovery:
consul_kv:
servers:
- "http://127.0.0.1:8500"
The keepalive
has two optional values:
true
, default and recommend value, use the long pull way to query consul serversfalse
, not recommend, it would use the short pull way to query consul servers, then you can set thefetch_interval
for fetch interval
Register Http API Services
Service register Key&Value template:
Key: {Prefix}/{Service_Name}/{IP}:{Port}
Value: {"weight": <Num>, "max_fails": <Num>, "fail_timeout": <Num>}
The register consul key use upstreams
as prefix by default. The http api service name called webpages
for example, and you can also use webpages/oneteam/hello
as service name. The api instance of node's ip and port make up new key: <IP>:<Port>
.
Now, register nodes into consul:
curl \
-X PUT \
-d ' {"weight": 1, "max_fails": 2, "fail_timeout": 1}' \
http://127.0.0.1:8500/v1/kv/upstreams/webpages/172.19.5.12:8000
curl \
-X PUT \
-d ' {"weight": 1, "max_fails": 2, "fail_timeout": 1}' \
http://127.0.0.1:8500/v1/kv/upstreams/webpages/172.19.5.13:8000
In some case, same keys exist in different consul servers. To avoid confusion, use the full consul key url path as service name in practice.
Upstream setting
Here is an example of routing a request with a URL of "/*" to a service which named "http://127.0.0.1:8500/v1/kv/upstreams/webpages/" and use consul_kv discovery client in the registry :
$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
"uri": "/*",
"upstream": {
"service_name": "http://127.0.0.1:8500/v1/kv/upstreams/webpages/",
"type": "roundrobin",
"discovery_type": "consul_kv"
}
}'
The format response as below:
{
"node": {
"value": {
"priority": 0,
"update_time": 1612755230,
"upstream": {
"discovery_type": "consul_kv",
"service_name": "http://127.0.0.1:8500/v1/kv/upstreams/webpages/",
"hash_on": "vars",
"type": "roundrobin",
"pass_host": "pass"
},
"id": "1",
"uri": "/*",
"create_time": 1612755230,
"status": 1
},
"key": "/apisix/routes/1"
},
"action": "set"
}
You could find more usage in the apisix/t/discovery/consul_kv.t
file.
Debugging API
TODO