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

Add support for docker swarm #25

Open
rgomezceis opened this issue Nov 22, 2022 · 2 comments
Open

Add support for docker swarm #25

rgomezceis opened this issue Nov 22, 2022 · 2 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@rgomezceis
Copy link

No description provided.

@capnspacehook capnspacehook added the enhancement New feature or request label Dec 27, 2022
@capnspacehook capnspacehook added the help wanted Extra attention is needed label Apr 1, 2023
@akselerando
Copy link

Has this been tested with Docker Swarm, or what is missing for making this work for Swarms?

This tool looks really promising, so it would be greatly appreciated if it would work in Swarm mode aswell:) @capnspacehook

@Matchlighter
Copy link

Matchlighter commented Oct 22, 2024

I too would be interested in Swarm support, but afraid I can't offer a ton of help with Go. It'd be nice if the Docker Socket could return events/info from across the Swarm instead of just the current node, but it doesn't seem to do that.

Some implementation thoughts I came up with:

Whalewall would need to run on each Swarm node (easy). Ideally each instance would be isolated and operate independently (seems fairly realistic, aside from the note below).

I think the biggest issue would be locating IPs and Whalewall annotations of containers running on other nodes. Other than that, it seems like a lot of the rest is the same. Maybe one would take the container param (from Whalewall's config) and equate it to the service name. Then query /tasks?service=X to get the IP - the task response looks like it also contains a ContainerSpec value that might contain the tags as well, abating the need to call /services to find tags.

Reverse look up is the other problem - one would probably need to list all services (though probably not all tasks) and find which ones reference the current container in their tags. If Docker emits events fo tasks (which the docs don't mention it does...), this fetching of all services would probably only need to be done once on startup. Without Task events... each node would probably need to have some awareness of other nodes to relay container events (first trying to map them to a task and or service). Alternatively to full-awareness, the manager node can run a small MQTT (or similar) broker that handles each node pubs/subs to as appropriate.

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

No branches or pull requests

4 participants