You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking at the documentation for service configs, this part has me a bit confused:
For a service definition:
The address field can be used to specify a service-specific IP address. By default, the IP address of the agent is used, and this does not need to be provided. The port field can be used as well to make a service-oriented architecture simpler to configure; this way, the address and port of a service can be discovered.
And for a TCP health check definition:
TCP + Interval - These checks make an TCP connection attempt every Interval (e.g. every 30 seconds) to the specified IP/hostname and port. If no hostname is specified, it defaults to "localhost".
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.
The text was updated successfully, but these errors were encountered:
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.The text was updated successfully, but these errors were encountered: