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

Nodes with duplicate hostnames fail to join kong cluster when using default cluster_listen #1255

Closed
nguilford opened this issue May 26, 2016 · 3 comments
Assignees

Comments

@nguilford
Copy link

nguilford commented May 26, 2016

Summary:
Nodes with identical hostnames using the default cluster_listen ipv4:port fail to join a cluster because serf expects node names to be unique, and the code for get_node_name does not generate unique names in these conditions:

https://github.com/Mashape/kong/blob/997561b42c27d5917f261065d9b1f5e99079e337/kong/tools/cluster.lua#L6

Why this is a problem:
I use docker to spin up multiple instances of kong containers that live behind a load balancer. Those instances are brought up as members of the same pool and, as such, are given the same hostname; /etc/hosts on each instance is configured to resolve that hostname to localhost. ipv4 addresses are not assigned to these instances until runtime, so I wish to use kong's default cluster_listen ip:port (0.0.0.0:7946). Unfortunately, in this case get_node_name will return the same name for each node in my cluster, resulting in all but one node failing to join the cluster.

At the moment, my container grabs the node's local ipv4 address at runtime and appends it to kong.yml file for cluster_listen before starting up kong. But it would be nice to have this working out of the box.

Version/Platform:
I am running Kong version 0.8.1 in Docker.

Suggested fix:
Just as the first local non-loopback address is used to advertise a node's presence to other nodes when the cluster_listen ipv4 address is 0.0.0.0, first local non-loopback address could be used to calculate the node's name. There is no reason two nodes in the same cluster should have the same non-loopback ipv4 address, so this would be unique.

@subnetmarco subnetmarco self-assigned this May 26, 2016
subnetmarco added a commit that referenced this issue Jun 1, 2016
@subnetmarco
Copy link
Member

@nguilford could you try to manually apply the patch at #1281 and see if that fixes your problem?

@nguilford
Copy link
Author

nguilford commented Jun 1, 2016

Yes, #1281 fixes this issue. Thank you!

@Tieske
Copy link
Member

Tieske commented Jun 2, 2016

released in 0.8.3. closing this.

@Tieske Tieske closed this as completed Jun 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants