I have a small docker swarm running in my office: one 40-core (128GB RAM) and two 8-core (16GB RAM each). When I deploy a service across the swarm, the jobs are running, but they are spread evenly without regard to per-machine capacity.

I started the swarm on the manager with:

docker swarm init
docker swarm update --task-history-limit 2

and on each node:

docker swarm join --token <token-string> <ipaddr:port>

Then I start a service with:

docker service create --detach \
     --mount type=bind,src=/s/mypath,dst=/home/mypath \
     --entrypoint "/home/mypath/myscript.sh arg1 arg2" \
     --name "mystuff" -w /home/mypath myregistry.me.com:5433/myimage

The process works individually. I have not found an indication of assignment weighting or affinity based on node strength.

Ideally, I'd like to be able to say something like one of these:

  1. join the swarm, take no more than n tasks (a bit naïve)
  2. join the swarm, weight my (cpu-)capacity as 0.2 (or 5 on the larger ones)
  3. start this service, assign no more than one task per available core

I'm self-regulating the overall scale of the service with docker service scale, but that doesn't provide any granularity. Is it possible to regulate docker swarm services per node by available resources?

(This may be even more incentive to switch to k8s, which I'm assuming provides functionality along these lines. There are growing pains with learning and the transition that I've been stiff-arming.)

1 Answer 1


All that is indeed possible when you create or update a Swarm service.

This falls under "container placement" options in those commands. If it's just resource reservation you're worried about, then look at --reserve-cpu and --reserve-memory. Those will ensure the node has the free cpu or memory avail on a node before tasking each container.

Example: If you need a swarm service to deploy two php replicas, and each needs to make sure it's on a node with 1GB of memory and 1 CPU, then service create --reserve-cpu 1 --reserve-memory 1GB php will only schedule the containers on nodes that the Swarm scheduler knows have that amount of hardware available. If a node only has 2 logical CPU's, then it would never deploy more then 2 replicas of that service on that node.

  • There's lots of other ways to control task placement, including limiting cpu/memory, the "mode" (global/replaced), service constrains (label matching), placement preferences, and node availability, but the ones I mention are likely your answer. Commented Jan 24, 2018 at 3:47
  • That was easier than I expected, not sure how I missed it. Thanks, Bret!
    – r2evans
    Commented Jan 24, 2018 at 5:40
  • Will be another question if you prefer: is there an easy way to limit the total number of instances started? That is, "run this task 100 times" (and spread appropriately across the heterogenous workers) "and then stop"?
    – r2evans
    Commented Jan 24, 2018 at 5:49
  • not built in. Swarm assumes a Service is long running. Two options: try and hack together something with service create options search for restart but it's not usually a good experience. The best option is to check out JaaS (Jobs as a Service) By Alex Ellis github.com/alexellis/jaas which runs on top of swarm and can run 1-off things. Commented Jan 24, 2018 at 17:39
  • 1
    Yea, Swarm has things built-in that K8s doesn't, and K8s has the same. That's why there are multiple successful orchestrators (nomad, mesos, swarm, k8s, etc.) Commented Jan 25, 2018 at 3:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .