Documentation for Configuration of Open Manager while running HAProxy in Docker

[zanetdev]

Really interesting project!

I was looking at the documentation and noted in the docker compose file there are 2 "remote haproxy" test instances running in docker. I am a bit lost as to how open manager be connected to these ephemeral instances?

From my reading of the documentation it looks like it will only be able to run against an installed haproxy instance, the agent needing access to the binary, the socket and the config.

Ultimately I would like to ran haproxy in docker on remote machines and have open manager manage them

[yudin-s]

The important distinction is that the Docker compose "remote haproxy" containers are test fixtures, not the normal production connection model.

OpenManager's real model is agent-pull:

• run the OpenManager backend/frontend/database stack centrally;
• create a pool/cluster in the UI;
• install the generated haproxy-agent script on each target HAProxy machine;
• the agent on that machine reads/writes the local HAProxy config, talks to the local stats socket/binary/service, and polls OpenManager for work.

So if HAProxy is running in Docker on remote machines, the question becomes where the agent runs:

1. Agent on the Docker host, managing the HAProxy container's mounted config and reload mechanism.

   This is usually the cleaner option if the HAProxy container bind-mounts its config from the host. The agent can update that host-side config path, then reload/restart the HAProxy container through whatever service/compose workflow you standardize.

2. Agent inside or beside the HAProxy container.

   This only works if the agent has access to the same config path, the HAProxy binary or validation command, the stats socket/API, and a way to reload HAProxy. A minimal HAProxy image often will not have the needed shell/system tooling, so a sidecar or host-level agent is usually easier than baking management into the HAProxy container.

The bundled haproxy-remote1 / haproxy-remote2 containers in docker-compose.yml look like local demo targets using haproxy/haproxy-simple.cfg; they do not by themselves demonstrate remote Docker-host management. For real remote Docker nodes, I would document/configure each node as an agent-managed target and make the HAProxy config path/reload command explicit.

If your goal is "central OpenManager, HAProxy containers on several remote hosts", the supported shape should be: one agent per remote host or per HAProxy node, assigned to the same pool/cluster, with that agent given controlled access to the container's config and reload path.

If that answers the topology question, please mark this as answered.

[zanetdev]

Clarification much appreciated, thank you!