Skip to content
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

Consul 0.6: dynamic bind address when running in a docker container? #1478

Closed
drankinn opened this issue Dec 8, 2015 · 5 comments · Fixed by #2563
Closed

Consul 0.6: dynamic bind address when running in a docker container? #1478

drankinn opened this issue Dec 8, 2015 · 5 comments · Fixed by #2563
Labels
type/enhancement Proposed improvement or new feature

Comments

@drankinn
Copy link

drankinn commented Dec 8, 2015

previously consul would find the docker container's eth0 interface and bind to that by default.
With the change to forcing a bind address with multiple private ips that doesn't work.
I'm a t a loss how to proceed. There isn't a bind address to pass in during the docker run command,
and consul doesn't recognize anything but an ip address as a parameter.
Am I relinquished to writing a wrapper script just to discover the container's IP address before running consul?

@slackpad slackpad added the type/enhancement Proposed improvement or new feature label Dec 8, 2015
@slackpad
Copy link
Contributor

slackpad commented Dec 8, 2015

Hi @drankinn - previously Consul would basically just pick one, so it wasn't a very good mechanism to rely on. This is an interesting problem, though. If you can't bind to 0.0.0.0 then I think you would have to pull the address as things stand now, though this could be made better if Consul would let you bind to an interface name, looking up the address for you.

@MansM
Copy link
Contributor

MansM commented Dec 11, 2015

In a setup I am building, I also having problems with this. The ip that consul should be delivering on request is different from the ip that is connecting with consul. I have manually fixed it in the containers consul agent by setting the address item in the service defenition file.

@slackpad
Copy link
Contributor

Will look to share code with Nomad on this one - see hashicorp/nomad#186.

@sean-
Copy link
Contributor

sean- commented Dec 2, 2016

All, please give the latest code in master a twirl and let us know if that helps with this old issue. The syntax for selecting the right IP addresses, getting the first "usable" IP address on an interface, or any other manner of network craziness is likely possible now as a template evaluated address parameter can be passed to Consul addresses (e.g. -bind or bind_addr, or any other *_addr-like parameter):

-bind='{{ GetInterfaceIP "eth0" }}'
-bind='{{ GetAllInterfaces | include "network" "10.99.0.0/24" }}'
-bind='{{ GetDefaultInterfaces | include "network" "10.99.0.0/24" | sort "size,address" | attr "address" }}'
-bind='{{ GetAllInterfaces | exclude "rfc" "6890" | sort "type,size,address" | include "flags" "up|forwardable" | attr "address" }}'

Very few people should need to do anything as obscene as shown in the last example, but the functionality is there should you need it.

With the sockaddr command you can experiment with getting the right template syntax with the eval sub-command, for instance:

$ sockaddr eval 'GetAllInterfaces | include "network" "10.99.0.0/24" | sort "size,address" | attr "address"'
10.99.0.5
$ sockaddr eval 'GetInterfaceIP "eth0"'
10.99.0.5

There is now a configurable template language for examples and docs) behind this that you can use to create a customizable heuristic that should allow you to get whatever it is that you need from your environment when using an immutable image (see hashicorp/go-sockaddr/template and cmd/sockaddr.

@salzig
Copy link

salzig commented Mar 27, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/enhancement Proposed improvement or new feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants