Skip to content

explain clustering - #929

Merged
taylordowns2000 merged 2 commits into
mainfrom
update-for-new-option
Oct 20, 2026
Merged

taylordowns2000 merged 2 commits into
mainfrom
update-for-new-option

Conversation

@taylordowns2000

Copy link
Copy Markdown
Member

@bensonmiller , @rorymckinley , @Tedion , heard there was some confusion about how clustering works in Erlang and thought this might be useful! does this line up with your understanding?

AI Usage

Please disclose how you've used AI in this work (it's cool, we just want to
know!):

  • I have used Claude Code
  • I have used another model
  • I have not used AI

You can read more details in our
Responsible AI Policy

Comment thread docs/deploy/requirements.md Outdated
the cluster.
each sized for its workload. This is how OpenFn's own cloud runs. As on Docker
Engine, every web app pod is active, and on GKE the pods join one Erlang cluster
on their own. For the database, use a high-availability managed Postgres service

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@taylordowns2000 Does on their own. equate to using Gossip? if so, I am not sure that is correct - we provision a service in GKE and pass that service (via K8S_HEADLESS_SERVICE) to Cluster.Strategy.Kubernetes.DNS (provided by libcluster).

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call. Have removed. Thank you!

Comment on lines +196 to +200
Outside Kubernetes, Lightning finds other nodes with gossip by default. Gossip
uses UDP multicast, which most cloud networks block between VMs. On Docker
Engine across several hosts, set `ERLANG_NODE_DISCOVERY_VIA_POSTGRES_ENABLED` to
`true` so nodes find each other through the Postgres database they already
share.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docker Engine side only, that's what I've deployed Lightning clustered on.

One thing the tip could add. Postgres discovery only finds peers; the connection is still plain TCP, so you also need the same RELEASE_COOKIE, RELEASE_DISTRIBUTION=name, RELEASE_NODE as a reachable address rather than a container id, a pinned port (ERL_AFLAGS=-kernel inet_dist_listen_min 9100 inet_dist_listen_max 9100) and the firewall open for epmd 4369 plus that port.

Set only the flag and the nodes discover each other and still can't connect.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah ok, let's make sure this information lives in Zeus

@Tedion Tedion left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docker Engine side reads right to me. I'll get the connection-level details into Zeus: the shared RELEASE_COOKIE, RELEASE_NODE as a reachable address, the pinned distribution port, and the firewall rule for epmd 4369 plus that port.

@taylordowns2000
taylordowns2000 merged commit 69a1543 into main Oct 20, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants