CODEWITHSUNDEEP
pythonflaskconsul
Bino Oetomo
Bino Oetomo

Reputation: 625

Flask consul and consul DNS

I'm trying to learn playing with flask and consul.

Here is my /etc/consul.d/consul.json

{ "data_dir": "/opt/consul/data", "server": true, "bind_addr": "0.0.0.0", "bootstrap_expect": 1, "ui": true, "domain": "bino.inc", "client_addr": "0.0.0.0", "node_name": "node01" }

run with /usr/bin/consul agent -config-dir=/etc/consul.d/

Test with dig @127.0.0.1 -p 8600 node01.node.bino.inc and got ;; ANSWER SECTION: node01.node.bino.inc. 0 IN A 192.168.1.5

I just make a copy of example from https://github.com/vsudilov/flask-consulate make a small change to it :

# Register Consul service:
consul.register_service(
    address='127.0.0.1',
    name='webapp',
    interval='10s',
    tags=['master', ],
    port=5000,
    httpcheck='http://localhost:5000/healthcheck'
)

consul.app.run(port=5000, threaded = False, debug=True)

Looks like consul and flask script communicating each other. flask debug got :

127.0.0.1 - - [15/Nov/2018 08:38:27] "GET /healthcheck HTTP/1.1" 200 -

My question is the FQDN of my flask script that consul will generate ?

I tried

dig @127.0.0.1 -p 8600 webapp.bino.inc

, and consul debug said :

2018/11/15 08:41:29 [WARN] dns: QName invalid: webapp.

Tried with

dig @127.0.0.1 -p 8600 webserver.bino.inc

, consul debug said :

2018/11/15 08:43:37 [WARN] dns: QName invalid: webserver.

Sincerely -bino-

Upvotes: 3

Views: 1480

Answers (1)

bagljas
bagljas

Reputation: 850

Querying registered services in Consul via DNS interface requires specific structure of the service FQDN as described in this link for standard lookups (Conusl DNS stadard lookup)

FQDN of the service registered with Consul must be in the form:

<service>.service[.datacenter].<domain>

where <service> is the name of your service registered with Consul, in your case webapp or webserver. The <domain> is consul domain as defined in your consul.json. [datacenter] is optional, and Consul server will return services for the datacenter to which it belongs. Since you haven't defined it in consul.json it's dc1.

So your dig query should look like this:

dig @127.0.0.1 -p 8600  webapp.service.bino.inc

or

dig @127.0.0.1 -p 8600  webserver.service.bino.inc

Optionally you can try adding datacenter to FQDN. Your dig query should look like this, and should return same response as those above as you are running single DC single node Consul cluster:

dig @127.0.0.1 -p 8600  webserver.service.dc1.bino.inc

I hope this helps solve your problem.

Upvotes: 2

Related Questions