Changing a service's specification triggers a rolling update: Swarm 514 replaces tasks in batches of update_config.parallelism, waits delay between batches, and with order: start-first starts each new task before stopping the old one, so capacity never drops. Roll the heap setting of Memory and CPU Limits out to the API, then take swarm-3 out of service as you would before patching its operating system:
m1 service update -q --env-add NODE_OPTIONS=--max-old-space-size=192 booknest_api >/dev/null
S='{{.UpdateStatus.State}}'
until m1 service inspect -f "$S" booknest_api | grep -q completed; do sleep 2; done
m1 service ps booknest_api --format '{{.Name}} {{.Node}} {{.DesiredState}}' | head -2
m1 node update --availability drain swarm-3 >/dev/null; sleep 15
m1 stack ps booknest -f desired-state=running --format '{{.Name}} {{.Node}}' | sort
m1 node update --availability active swarm-3 >/dev/nullbooknest_api.1 swarm-2 Running booknest_api.1 swarm-3 Shutdown booknest_api.1 swarm-2 booknest_api.2 swarm-2 booknest_api.3 swarm-1 booknest_db.1 swarm-1 booknest_web.1 swarm-2 booknest_web.2 swarm-1
Each replica has a new running task and an old one shut down. Had the new tasks failed their healthcheck, failure_action: rollback would have restored the previous specification (docker service rollback does it by hand). Draining moved every task off swarm-3 to the remaining nodes; pause instead keeps existing tasks but accepts no new ones. Making swarm-3 active again does not move tasks back: Swarm never rebalances running work on its own, so run docker service update --force booknest_web if you want an even spread.