[RRRA]

I'm no consul expert, but their only problem i've seen right now is the fact that ID is bound to an IP and that this IP is taken from the first network interface.

I hope they can move to GUIDs or some other solution soon and facilitate consul's use in "dynamic" (at leat from consul's point of view) IP environment, say inside Docker, etc.

[Leon]

You can specify a custom ID. I use ID's such as AWS instance ID for clusters in Amazon.

[RRRA]

So a single node Consul cluster, when rejoining itself with a custom ID, would end up a leader of "itself" and not wait for the previous IP as a follower, forever? :)

Which option would that be for a server config?

https://www.consul.io/docs/agent/options.html

[Leon]

I think I'm a little confused by what you are asking - are you wanting to run a consul server and agent on the same instance? You can do that and specify an ID appropriate to the consul service type for multi-tenancy situations of master nodes and client nodes. But that would be up to you given your deployment environments.

Are you wanting to have a single consul service running for the whole environment (as client and server)? If you're running an HA environment you should really have dedicated master nodes and non-voting clients for service discovery on instances. The member states of consul clusters have an IP and ID, are you saying that the IP could be mixed with a different ID (it could in the cloud, but upon connecting to the leader it would update its registered information).

Are you talking about cleaning up old instances registered in the cluster? Or that there could be a single master node which has a broken network connection to the other master nodes, so sees different cluster status information? In that case, you should be monitoring all your services. Always. There are a lot of tools out there which will clean up and correct voting clusters in those situations. We use Sensu and Kubernetes checks / services for a lot of monitoring and automatic reaction to changes in cluster health.

[chucky_z]

This was actually an issue in previous versions, in (I believe 0.7) after a timeout (reconnect_timeout and reconnect_timeout_wan in options) a node will be completely removed.

[takeda]

0.7.0 is the latest version of consul

[RRRA]

And it still is an issue

[bogomipz]

Is your concern that you just want it to bind to another interface besides the first one(the default?) If so you can use the -advertise flag.

From the docs:

-advertise - The advertise address is used to change the address that we advertise to other nodes in the cluster. By default, the -bind address is advertised. However, in some cases, there may be a routable address that cannot be bound. This flag enables gossiping a different address to support this. If this address is not routable, the node will be in a constant flapping state as other nodes will treat the non-routability as a failure.

[RRRA]

My concern is that while running consul as a single docker container, it will completely get stuck in a follower state even though it's the only node in the cluster if the IP chnages on restart.

It is waiting for the previous IP, who was the leader, to join... My understanding is that it's not solved?

https://github.com/hashicorp/consul/issues/457

Or maybe I could set the reaping delay from 72h to 0 in that case.

[zbjornson]

In addition to custom IDs as noted in the other reply, you can specify which interface to bind.