Pular para o conteúdo principal

Docker Swarms & Load Balancing

Docker Swarms group nodes into a cluster for running compute instances and services. EasyHAProxy provides automatic load balancing and ingress routing.

Create a swarm​

nimbus swarm create --name production --lb

The --lb flag automatically deploys EasyHAProxy as a load balancer.

Cloudflare integration​

nimbus swarm create --name production --lb \
  --cloudflare /path/to/cloudflare.env

The env file should contain CLOUDFLARE_TOKEN and CLOUDFLARE_DOMAIN.

Add and remove nodes​

nimbus swarm add-node --swarm SWARM_ID --node NODE_ID

The first node becomes the manager; additional nodes join as workers.

The join runs on the node in the background. Once it succeeds, the node's local DNS is pointed at the manager for the swarm's domain. If it fails, the node is taken out of the swarm and the swarm keeps its status. The reason is recorded as a swarm_join_failed event:

nimbus node events NODE_ID

The most common reason is a Docker daemon that won't start on the node. The event then includes the state of docker.service and dockerd's last log line; journalctl -u docker on the node shows the rest.

List swarms​

nimbus swarm list

Load balancer management​

If you didn't use --lb at creation time, you can manage the load balancer separately:

# Deploy EasyHAProxy
nimbus gateway lb set --swarm SWARM_ID

# List load balancers
nimbus gateway lb list

# Delete the load balancer
nimbus gateway lb delete --swarm SWARM_ID

# Move it to the newest EasyHAProxy release, or to --version
nimbus gateway lb upgrade --swarm SWARM_ID

An upgrade replaces the image and keeps EasyHAProxy on managers, which it needs to read the swarm; see Upgrading the load balancer.

HTTPS with your own certificates​

A certificate registered with nimbus certificate create is also served by the load balancer of every swarm, on 443, for any service routed to its domain: a compute instance created with --domain, or a Compose stack with EasyHAProxy labels.

nimbus certificate create --domain chat.example.lan \
  --cert chat.example.lan.crt --key chat.example.lan.key

Each manager of a swarm with a load balancer gets the certificates, since EasyHAProxy may run on any of them, as files in the volume nimbus-lb-certs, mounted at EasyHAProxy's certificates folder. Deleting a certificate removes its file. HAProxy picks the certificate whose name matches the one the browser asks for, so a certificate covering several names (SAN) serves all of them.

EasyHAProxy 6.5.2 and later serve a new or changed certificate within a few seconds, without a restart. An older one serves it at its next reload; nimbus gateway lb upgrade moves it to the newest release. Load balancers deployed before this feature get the volume with that upgrade, in the same restart.

A Compose stack only needs the routing labels, with ssl on the 443 definition; the certificate comes from Nimbus:

services:
  web:
    image: nginx
    deploy:
      labels:
        easyhaproxy.http.host: chat.example.lan
        easyhaproxy.http.port: "80"
        easyhaproxy.http.localport: "80"
        easyhaproxy.http.redirect_ssl: "true"
        easyhaproxy.https.host: chat.example.lan
        easyhaproxy.https.port: "443"
        easyhaproxy.https.localport: "80"
        easyhaproxy.https.ssl: "true"

Do not also give the stack an easyhaproxy.*.sslcert label for the same name: HAProxy would then have two certificates for it.

The same certificates also serve Ingresses on a Kubernetes cluster, as TLS Secrets: see HTTPS with your own certificates in the Kubernetes guide.

Gateway status​

View the routing table showing how domains are mapped to services:

nimbus gateway status

Local DNS​

Configure your workstation to resolve swarm domains (e.g., web-1.production.nimbus) via dnsmasq running on the swarm manager:

sudo nimbus dns create

This configures systemd-resolved to forward queries for swarm domains to the manager node's dnsmasq. To remove:

sudo nimbus dns delete

Unmanaged resources​

DockNimbus manages only the resources it created, so anything you deploy straight to Docker stays outside its control. The swarm's detail page in the web UI has an Unmanaged Resources panel that shows those services, so a swarm is not a place where things can hide.

Press Scan to run it. The scan is manual rather than automatic because each run queues a task on the swarm manager, and its result is never stored — it is a live look at the swarm, accurate as of the moment you pressed the button.

DockNimbus's own services are excluded: instances, the load balancer, local DNS, and every service belonging to a stack deployed through DockNimbus, including stacks whose services carry no DockNimbus label of their own.

The panel is read-only. It shows you what is there; stopping it is still done through Docker.

Delete a swarm​

nimbus swarm delete SWARM_ID          # load balancer and nodes removed first
nimbus swarm delete SWARM_ID --force  # removes the load balancer, every node leaves

A swarm that still has instances or services Nimbus manages (that are not terminated) cannot be deleted: delete them first. The same holds for removing its last node, or deleting that node.

Every member leaves the Docker swarm, and the swarm shows as deleting until they all have. A node whose agent is offline leaves when it comes back, so the swarm is never removed while a node is still in it. If a leave fails, the swarm stays in error with that node still listed; run the delete again once the node is fixed, and its leave is retried. Removing the last node with nimbus swarm remove-node deletes the swarm the same way.

While a swarm is deleting, its name cannot be reused.