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
We're provisioning Traefik as a Docker job with host networking, binding the proxy to a public VRRP IP and the management IP to a private VRRP, on separate interfaces.
This works all good, but the services registered in Consul get assigned to the Nomad IP, which makes service checks fail.
I see that this may be covered by the solution to #646 , but I think this is a common use-case that can have a simpler solution not requiring changes to the client config, by simply allowing specification of the IP address to use in the serviceor check stanza with an added address field.
The text was updated successfully, but these errors were encountered:
I've run into this issue too, but in a different way. My cluster is configured to bind to and advertise IPv6 addresses for both Nomad and Consul, but Nomad always picks the public IPv4 address when registering a service using the exec driver. The discrepancy can be seen pretty easily in the service details:
The address is correctly using the advertised IPv6 address, but the service address is still picking the IPv4 address, which in this case is causing Fabio to route requests to the wrong address.
I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
We're provisioning Traefik as a Docker job with host networking, binding the proxy to a public VRRP IP and the management IP to a private VRRP, on separate interfaces.
This works all good, but the services registered in Consul get assigned to the Nomad IP, which makes service checks fail.
I see that this may be covered by the solution to #646 , but I think this is a common use-case that can have a simpler solution not requiring changes to the
client
config, by simply allowing specification of the IP address to use in theservice
orcheck
stanza with an addedaddress
field.The text was updated successfully, but these errors were encountered: