mirror of
https://github.com/therealpaulgg/ssh-sync-server.git
synced 2026-04-25 07:35:49 +03:00
[GH-ISSUE #19] Make ssh-sync-server horizontally scalable #2
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ssh-sync-server#2
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @therealpaulgg on GitHub (Mar 22, 2024).
Original GitHub issue: https://github.com/therealpaulgg/ssh-sync-server/issues/19
For the challenges, currently we store state in ChallengeResponseDict. This is thread-safe but single node.
This state is responsible for responding to challenges, but the problem with this approach is that it is not horizontally scalable...
If a user instantiates a challenge, that pops a thread on node A (which is probably fine). But then if we had a challenge response submitted to node B, node B would not be able to resolve the challenge as it isn't sharing the state that node A has.
If we used Redis to have a distributed state this might help. So node B checks redis, finds the state. It would also need to locate the machine that has the thread active, and notify it somehow. Could probably do this with a pub/sub system.
The app would still utilize channels, but would be receiving signals from Redis directly.
This may not be very necessary but would improve the scalability of ssh-sync.
@therealpaulgg commented on GitHub (Mar 22, 2024):
https://redis.uptrace.dev/guide/go-redis-pubsub.html
@therealpaulgg commented on GitHub (Mar 22, 2024):
In order to test this we would need some sort of load balancer to route traffic correctly...infra hell.
K8s, docker swarm
this may be the easiest way?