Repository navigation
TCP transporter IP bug #380
Description
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
Activity
icebob commentedon Nov 1, 2018
Does somebody have an idea how we can force NodeJS to resolve again DNS names?
zllovesuki commentedon Nov 6, 2018
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 commentedon Nov 7, 2018
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 commentedon Nov 9, 2018
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 commentedon Nov 10, 2018
The docs say the
ttlin option is a boolean. If true, the callback returns the TTL setting. So you can't use it to define TTL for DNS resolving.