OPERATING

Clusters and scaling

Join servers into a cluster, run several replicas of an application, and survive a node going down.

Everything else on DockBoard places an application on one Docker host. A cluster spreads a single application across several of your servers, on an overlay network, with Docker scheduling the tasks. It is opt-in per application — every existing application stays on the compose path, untouched.

Forming a cluster

Cluster → Create cluster, then pick the manager server.

The manager must be a remote server — not the DockBoard host, which runs the control plane.
Add node joins another ONLINE server as a worker. A server belongs to one cluster at a time.
Removing a node makes it leave the Swarm. Deleting a server still in a cluster is refused until it does.

Ports between nodes

Nodes need these open to each other. A join that hangs is almost always one of them:

Port	What it carries
`2377/tcp`	Cluster management
`7946/tcp` + `7946/udp`	Node discovery
`4789/udp`	Overlay traffic

The registry

Swarm does not build images — every node has to *pull* the same one. Provision registry deploys a private registry:2 on the manager for that, with TLS and a password. The CA is handed to each node as it joins, so workers can pull without anyone editing daemon.json.

Until the registry reads Ready, deploying a stack is refused. Without it, tasks scheduled on the other nodes would fail to pull and never start.

Running an application on the cluster

On the application page: Deployment target → Docker Swarm cluster → pick the cluster → Apply. The application must be:

Git-based: The image is built from the repository and pushed to the registry.
Compose-managed by DockBoard: A committed docker-compose.yml is authoritative and is never rewritten, so it cannot be converted into a stack.
Stateless: No volumes, no bundled database. A task can be rescheduled onto another node at any moment, and a local volume does not follow it.

Deploying then clones, builds, pushes <registry>/<app>:<sha>, converts the compose file into a stack — build, container_name and depends_on dropped, image pinned, ports republished on the ingress mesh, networks turned into overlays, memory and CPU limits remapped under deploy.resources — and waits for the services to converge.

What changes day to day

Action	Compose application	Cluster application
Stop	Container stopped	Scaled to 0 replicas
Start	Container started	Scaled back up
Restart	Container restarted	Rolling `service update --force`
Scale	N containers, one host	N tasks spread over the cluster, applied live
Rollback	Previous build restored	`service rollback` to the previous spec
URL	Server host + published port	Every node answers on the stack port

That last row is the point. Docker’s routing mesh means any node can serve the application, so the reverse proxy is given every ONLINE node as an upstream. Lose a node and the traffic keeps flowing.

Refused on purpose

Applications with volumes or a bundled database — see above.
Moving a cluster application to a single server. Its placement *is* the cluster; change cluster, or move it back to compose first. See moving a project.
Backing one up. A stack has no files or volumes on any single server, so the archive would be empty. The refusal is explicit rather than silent — see backups.