Skip to main content

Docker Swarm: Overview

The Docker Swarm installer brings the full Elchi control plane up on Docker Swarm with a single command — online or fully air-gapped, single-node or multi-node HA. It is the third Elchi deployment path, alongside the bare-metal systemd installer and the kind + Helm single-host installer, and the production Helm chart.

It reuses the pre-built jhonbrownn/* images already on Docker Hub — the same images the Helm chart consumes. Nothing is built locally. Third-party services (MongoDB, ClickHouse, VictoriaMetrics, Grafana, OpenTelemetry, Envoy) run their official upstream images. Source lives at elchi-archive/deploy/docker/.

note
This is Docker Swarm, not Compose

The installer runs docker stack deploy against a Swarm cluster (it initializes Swarm for you if needed). It is not a docker compose setup.

What it deploys

All services share the elchi-net overlay network and address each other by Swarm service DNS (tasks.<service>), replacing the bare-metal installer's /etc/hosts aliases.

ServiceImageModeNotes
elchi-envoyenvoyproxy/envoyglobalEdge L7 router + TLS, publishes :<port>
elchi-registryjhonbrownn/elchi-backendglobalxDS routing / ext_proc target
elchi-controller-node<i>jhonbrownn/elchi-backend1 per nodeREST + gRPC API singleton (version-agnostic)
elchi-cp-<envoy>-node<i>jhonbrownn/elchi-backend1 per node per variantcontrol-plane (xDS)
elchi-uijhonbrownn/elchiglobalSPA (nginx); config.js injected
elchi-mongomongo:8.01 (M1)standalone; scoped elchi app user
elchi-clickhouseclickhouse/clickhouse-server1 (M1)event store (collector)
elchi-victoriametricsvictoriametrics/victoria-metrics1 (M1)metrics TSDB
elchi-grafanagrafana/grafana1 (M1)served at /grafana/
elchi-otelotel/opentelemetry-collector-contribglobalper-node metrics sink
elchi-collectorjhonbrownn/elchi-collectorglobalEnvoy ALS → ClickHouse
elchi-corednsjhonbrownn/elchi-corednsglobalGSLB DNS (optional)

The single elchi-backend image serves all three backend roles (registry / controller / control-plane) via subcommand. One control-plane service and one Envoy cluster is generated per backend variant; the embedded Envoy version must be unique across variants.

What it does NOT install

This is a control-plane-only stack, exactly like the bare-metal installer. It does not run the data-plane components that live on your edge hosts:

  • the elchi-client agent, and
  • the elchi-shield WAF sidecar.

Those install separately on each edge node — see Edge Client. If shield's audit sink is pointed at this stack's ClickHouse (--shield-audit-dsn=… on the edge), make port 9000 reachable from the edge hosts and grant the DSN user CREATE/INSERT; shield auto-creates its elchi_shield_audit table.

Container images

The Elchi-specific images live on Docker Hub under jhonbrownn/*. Third-party services use pinned upstream tags so save-images.sh produces a reproducible offline bundle. Defaults are the single source of truth in versions.env and can be overridden per component with the version flags (see Installer Flags).

ComponentImageDefault tagOverride flag
Backend (registry / controller / control-plane)jhonbrownn/elchi-backendv1.6.6-v0.14.0-envoy1.38.3--backend-version=<csv>
UI (nginx SPA)jhonbrownn/elchiv1.5.5--ui-version
CoreDNS (GSLB plugin)jhonbrownn/elchi-corednsv0.1.4--coredns-version
Collector (Envoy ALS ingest)jhonbrownn/elchi-collectorv0.1.11--collector-version
Envoy (edge)envoyproxy/envoyv1.37.0
MongoDBmongo8.0
ClickHouseclickhouse/clickhouse-server24.8
Grafanagrafana/grafana11.6.0
VictoriaMetricsvictoriametrics/victoria-metricsv1.93.5
OpenTelemetry Collectorotel/opentelemetry-collector-contrib0.89.0

Point the Elchi images at a private mirror (for example a local registry:2 used for air-gapped multi-node distribution) with --image-repo=<registry>/<namespace>.

Which path should I choose?

PathUse whenNotes
Docker Swarm (this)You want the control plane in containers on one or more Linux hosts without KubernetesPrebuilt images, online or air-gapped, single-node or auto-HA
Bare-metal / systemdYou want no container runtime — plain systemd services on the VMsPer-service MemoryMax/CPUQuota caps; host-managed lifecycle
HelmYou already run KubernetesProduction Kubernetes deployment
kind + HelmEvaluation on a single VM with no existing clusterWraps the Helm chart in a local kind cluster

Where things live

  • Editable config, secrets, TLS and dashboards are host bind-mounts under /etc/elchi (override with --etc-dir=), on every node. Operators edit a file in place and apply it with a service update — see Upgrade & Uninstall.
  • Only the generated stack.yml lives under ~/.elchi-docker/gen (override with --state-dir=).

Next steps