Open alkalinecoffee opened 6 years ago
Making the service address and port available when defining checks would be great. I'd propose this be extended generally and not just to TCP checks:
For members with dynamic IP, Consul properly reregisters itself to the cluster, however, services created manually, that have this tcp health check in place and use ip:port to register them originally, will be no longer passing health check.
Any way around this, after whole six years? Does http check require address or can it be set to just path?
Looking at the documentation for service configs, this part has me a bit confused:
For a service definition:
And for a TCP health check definition:
It seems to me that the service's bind address should be honored as the default for all child healthcheck definitions for that service, instead of switching over to
localhost
. Otherwise, in the current scenario, there is no way to set up a TCP healthcheck for a service that listens only on the bind address without knowing the node's external IP in the first place.This suggestion may be a backwards incompatible change, but it seems to be more in line with the service-to-health-check relationship.
If this is not an option, then a workaround like
GetInteraceIP
should perhaps be made available in the healthcheck definition as it is through command-line arguments so users can dynamically specify the target IP to a non-loopback address. Making envvars available to be injected similarly might also work, and be more flexible.