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

Default port 7946 collides with Docker Swarm port #22

Open
kaotika opened this issue Jan 24, 2020 · 7 comments
Open

Default port 7946 collides with Docker Swarm port #22

kaotika opened this issue Jan 24, 2020 · 7 comments
Assignees
Labels
enhancement New feature or request

Comments

@kaotika
Copy link

kaotika commented Jan 24, 2020

Hi,

I tried to setup docker swarm over wesher and run into a port conflict. According to the docker swarm docs swarm uses TCP and UDP port 7946.
Cause docker swarm is a common project I vote to change the default wesher port to something else instead, e.g. 7680.

As a workaround you can of cause use --cluster-port 7980 to setup the mesh on another port. Doing so, works like a charm with swarm.

@costela costela added the enhancement New feature or request label Jan 29, 2020
@costela
Copy link
Owner

costela commented Jan 29, 2020

Good catch. I believe swarm also uses memberlist, so that would explain it.

I'm thinking about implementing some bigger changes that would sidestep this problem, but if I don't get around it in the next few weeks, I'll probably change the default port.
It would mean breaking the upgrade path though. Unless one does a synchronized upgrade across the cluster.

@costela costela self-assigned this Feb 6, 2020
@Dr-Shadow
Copy link

Any news about this ?
I'm using wesher with docker swarm and I lost some time looking through these logs to understand what was happening.
Even a simple default port change should be enough for future users.
Btw I love to bootstrap my servers like this :
image

@bmullan
Copy link

bmullan commented Apr 10, 2020 via email

@costela
Copy link
Owner

costela commented Apr 10, 2020

hey @Dr-Shadow!
yeah, sorry, I'm unfortunately kinda swamped and didn't get around to fixing this 😒
My main problem is that I'd like to make the change seamless, without losing cluster connectivity.
Currently, if all cluster members are upgraded within memberlist's time limits, this should work, but it's still not ideal and might lead to unexpected cluster splits.

I'm thinking I'll spread this over two releases: first adding the cluster port to /var/lib/wesher and the second changing the default only for newly created clusters.

Here's to hoping I can find the time 🤞 😅

BTW: in your cloud-init, wouldn't it be slightly safer to have /etc/default/wesher as mode 0400?

@costela
Copy link
Owner

costela commented Apr 10, 2020

@bmullan I think he knows that: his config is already setting WESHER_CLUSTER_PORT 😉
(I'm assuming you probably didn't see the screenshot because you're reading the message over email)

@Dr-Shadow
Copy link

Dr-Shadow commented Apr 10, 2020

BTW: in your cloud-init, wouldn't it be slightly safer to have /etc/default/wesher as mode 0400?

Nice catch ty. That's still a WIP cluster and I got most of the things working including docker swarm init / join as manager/worker in cloud-init all together with wesher.
I'm still stuck with a static host for cluster initialization and I hope I will be able to get rid of it too.
I have a question about this :
Is the first host with WESHER_INIT=true required or optional at all times ? -> I have to create a specific instance ("hole") for the cluster initialization. Next instances get WESHER_JOIN=IP_of_hole.
Once they join the wesher cluster, is it safe to shutdown/delete the instance "hole" ?

@costela
Copy link
Owner

costela commented Apr 10, 2020

The first node has no special role. Any other node in the cluster can be used to join an existing cluster and will forward the other nodes' information along.
That being said, it may still be easier for the whole provisioning logic to have some node declared "the join node".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants