wesher icon indicating copy to clipboard operation
wesher copied to clipboard

Default port 7946 collides with Docker Swarm port

Open kaotika opened this issue 5 years ago • 7 comments

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.

kaotika avatar Jan 24 '20 12:01 kaotika

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 avatar Jan 29 '20 19:01 costela

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

Dr-Shadow avatar Apr 10 '20 19:04 Dr-Shadow

Can't you already change the Port

https://github.com/costela/wesher/blob/master/README.md

Look under Configuration Options

On Fri, Apr 10, 2020, 3:41 PM Dr-Shadow [email protected] wrote:

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: image] https://user-images.githubusercontent.com/5308086/79018353-ea43f880-7b73-11ea-8110-002ce5417fd0.png

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/costela/wesher/issues/22#issuecomment-612187288, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM23J2ZMMIAYY3XH5YIXW3RL5ZAHANCNFSM4KLFURPA .

bmullan avatar Apr 10 '20 19:04 bmullan

hey @Dr-Shadow! yeah, sorry, I'm unfortunately kinda swamped and didn't get around to fixing this :unamused: 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 :crossed_fingers: :sweat_smile:

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

costela avatar Apr 10 '20 19:04 costela

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

costela avatar Apr 10 '20 19:04 costela

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" ?

Dr-Shadow avatar Apr 10 '20 20:04 Dr-Shadow

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".

costela avatar Apr 10 '20 20:04 costela