TCP transporter IP bug

[0x39]

I'm testing TCP transporter.
All nodes is docker containers managed by rancher.

Transporter configuration, kind:

nodeID: 'node-id-1',
transporter: {
        type: 'TCP',
        options: {
            udpDiscovery: false,
            useHostname: true, //have tried true/false
            urls: [
               container_hostname:6000/node-id-1,
               ...
            ],
        }
    }

Problem is when i upgrade my rancher service, container IP changes, but all moleculer nodes still try to use old IP.

Some logs: https://gist.github.com/0x39/25bcf691268858155f8efeb210651ce8

[icebob]

Does somebody have an idea how we can force NodeJS to resolve again DNS names?

[zllovesuki]

I think the native DNS bingings will respect the TTL. It will resolve again if the TTL expires. There's no way to "force" hostname to resolve again without using third-party modules.

---

Consider using service discovery like etcd or consul. Relying on container dns name resolution is inherently broken. If you are using networked transporter (such as gnatsd or Redis) then initial service discovery is built-in to the transporter. Using TCP introduces nuisance where you don't know where your other peers are (in fact, projects like cote will recommend you to use Redis as a "service discovery" repo for that matter), thus external initial discovery is needed. Then gossip takes care of the rest.

[zllovesuki]

As a last resort, you could have an empty moleculer service (with unchanging hostname) which acts an introducer/arbitrator/middle man, then all your other instances should have random hostnames, and use the empty service as the entry point.

#notabug

[Wallacy]

I did not try but using dns.resolve4(hostname[, options], callback) passing a low ttl under options solve the problem? https://nodejs.org/api/dns.html

[icebob]

The docs say the ttl in option is a boolean. If true, the callback returns the TTL setting. So you can't use it to define TTL for DNS resolving.