consul_kv

    Thanks to @fatman-x guy, who developed this module, called , and its worker process data flow is below:

    Add following configuration in conf/config.yaml :

    And you can config it in short by default value:

      The keepalive has two optional values:

      • true, default and recommend value, use the long pull way to query consul servers
      • false, not recommend, it would use the short pull way to query consul servers, then you can set the fetch_interval for fetch interval

      Dump Data

      When we need reload apisix online, as the consul_kv module maybe loads data from CONSUL slower than load routes from ETCD, and would get the log at the moment before load successfully from consul:

      1.  http_access_phase(): failed to set upstream: no valid upstream node

      The has three optional values now:

      • path, the dump file save path
        • support relative path, eg: logs/consul_kv.dump
        • support absolute path, eg: /tmp/consul_kv.bin
        • make sure the dump file’s parent path exist
        • make sure the apisix has the dump file’s read-write access permission,eg: chown www:root conf/upstream.d/
      • load_on_init, default value is true
        • if false, ignore loading data from the dump file
        • Whether true or false, we don’t need to prepare a dump file for apisix at anytime
      • , unit sec, avoiding load expired dump data when load
        • default 0, it is unexpired forever
        • recommend 2592000, which is 30 days(equals 3600 * 24 * 30)

      Service register Key&Value template:

      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:

      1. 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
      2. 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.

      1. $ 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:

      You could find more usage in the apisix/t/discovery/consul_kv.t file.

      It also offers control api for debugging.

      1. GET /v1/discovery/consul_kv/dump

      For example:

        It offers another control api for dump file view now. Maybe would add more api for debugging in future.