-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Registering a different address for a service behind NAT #2770
Comments
I think that I have the same problem. When I deploy a service say Here is an example : The
|
Just an update, currently, I work around this by creating a loopback interface with the desired IP address and make Nomad bind to it. Then I use 'iptables -j NETMAP' to redirect traffic from the actual interface to it. |
On the other side, the "nomad-client" service has the correct IP address :
|
I have a similar request (tell me if it needs a separate issue): I want to register a service a second time, but with a different (already allocated) port. The reason for this is that I run the https://github.com/fabiolb/fabio load balancer on each machine, which picks up serving the service on the :80 port through service tags that are set in the nomad config. So basically what I would like to do is:
This way I can access a service through |
I have another use case for this. Although I agree it a bit stretched one. I got everything to work apart from consul health-checks for the running tasks. This is because the service will register in consul as being in This is very similar if not identical to the nomad behind NAT scenario; being able to override the service advertise address (so that I can specify the docker bip) would be great. |
As it was not straightforward for me, it is how I did (you need to replace
And just run:
I had to use this hack as Scaleway provides only public IPs via a NAT. |
As @mafonso mafonso said, this is very similar if not identical to the nomad behind NAT scenario. I'd like to be able to do "services behind NAT". In my case, I am using Fabio, but it's trying to route to the IP defined by the service stanze, which right now seems to be only the local IP of the host running the service, rather than the public IP of the host (because NAT is being used). |
Another possible approach might be to have a config in the service/checks stanza to use the Nomad agent's advertise address, just like how the nomad agent service checks can be configured via checks_use_advertise in the consul stanza for the nomad agent configs. I realize the challenge is to make job specs not require any knowledge of the underlying nomad host's config. However, I think it might make sense to support the ability to configure the Nomad agent to use one of the following for service registration:
This approach would work on both Linux and Windows hosts, and it would support NAT without jobspecs needing to have any knowledge of the underlying Nomad host's networking. It would mean operators would have to make it clear to job spec writers that services register with one of:
|
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 I'm not wrong, currently, the
service
stanza automatically registers the client's address configured innetwork_interface
to Consul. However, if the client is behind NAT, this address might not be reachable for other hosts in the multi-DC cluster.Is it a good idea to include an address in the
advertise
block of the client configuration file, underservice
for example that will override the address found by network fingerprinting? Or alternatively, shouldn't nomad uses the local Consul's WAN address instead?The text was updated successfully, but these errors were encountered: