Skip to content

Add support to pull data from multiple docker endpoints (e.g. swarm) #548

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

tarasov65536
Copy link
Contributor

This PR adds support to request container data from multiple docker endpoints. For example in swarm you now can get containers information from all nodes at once.

Main idea is that endpoint parameter refers to local docker node for which docker-gen generates configs. And the swarm-node parameters define additional docker nodes from which docker-gen pulls containers information.

Back compatability preserved. If no swarm-node stated then docker-gen collects information only from local docker endpoint defined by endpoint parameter.

In case when stated at least one swarm-node parameter docker-gen will collect containers information from swarm-node list. And use endpoint only for "controlling" purpose (e.g. to notify containers).

Root use-case for this PR is to make possible for projects like nginx-proxy to have full information across all swarm cluster.

fix getContainers
# Conflicts:
#	internal/generator/generator.go
@tarasov65536
Copy link
Contributor Author

Hi @buchdag,

I’d love to help move this PR forward if there’s interest (like here nginx-proxy/nginx-proxy#97) in adding support for pulling container data from multiple Docker endpoints — especially for Swarm setups.

I understand the code might be outdated and possibly conflicts with the current main branch. If that’s the case, I’m happy to resolve any conflicts and submit a clean, updated version of the PR.

Just for context: I’ve been running this implementation successfully in a Docker Swarm environment for the past couple of years. It’s been working reliably in production and enables tools like nginx-proxy to have visibility into containers across all Swarm nodes, which was the main motivation for this contribution.

Please let me know what would be the best way to proceed. Would it make sense to create a new PR based on the current main branch, or is there a particular direction you’d prefer?

Thanks in advance!

@buchdag
Copy link
Member

buchdag commented May 26, 2025

Hi @tarasov65536

There is definitely still interest in this and I would happily review a new PR 👍

One thing I did not get from this PR is how sendSignalToContainer and SetServerInfo / SetDockerEnv would continue to work in a swarm ?

… into multiple-enpoints

# Conflicts:
#	README.md
#	cmd/docker-gen/main.go
#	internal/generator/generator.go
@tarasov65536
Copy link
Contributor Author

Hi @buchdag ,

Thanks for your reply!

I’ve just merged the latest main branch into the PR and resolved all conflicts. The branch is now up to date and ready for review.

Regarding your question: the core idea of Swarm support in this PR is that we can define multiple swarm-node endpoints from which to collect container metadata (via the Docker API). However, actions like sendSignalToContainer, SetServerInfo, and SetDockerEnv are only ever performed against the single endpoint, which represents the local Docker engine — the one where docker-gen is running.

So, even in Swarm mode:

  • All container data is aggregated from multiple remote Docker nodes (via swarm-node).
  • But any control actions (e.g., sending signals, updating env) are only done against the local endpoint.

This matches the typical use case I have in production:
I run a Docker Swarm with multiple nodes, and some of them act as gateways. On each of these gateway nodes, I run a pair of containers: docker-gen and nginx.
Each docker-gen instance collects container info from all Swarm nodes using the swarm-node parameters and then generates the local nginx config accordingly — and only restarts its local nginx instance.

This setup works very reliably for me, and I’m hoping that this PR can help push that logic further into the nginx-proxy project as well — eventually allowing a single container (with docker-gen logic embedded) to handle everything instead of needing two containers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants