For large-scale deployments, you can change the default update behavior, either to complete the roll-out more quickly or to run a more conservative roll-out strategy. The default behavior updates one task at a time, with no delay between task updates, and if a task update fails, the roll-out is paused. The configuration can be overridden with three parameters:

• update-parallelism: The number of tasks to update concurrently
• update-delay: The period to wait between task updates; can be specified as hours, minutes, and seconds
• update-failure-action: The action to take if a task update fails, either to continue or stop the roll out

You can specify the default parameters in the Dockerfile so they're baked into the image, or the Compose file so they're set at deployment time or with the service commands. For a production deployment of NerdDinner, I might have nine instances of the SQL message handler, with update_config in the Compose file set to update in batches of three, with a 10-second delay:

nerd-dinner-save-handler:
  deploy:
  replicas: 9
  update_config:
    parallelism: 3
    delay: 10s
...

The update configuration for a service can also be changed with the docker service update command, so you can alter the update parameters and initiate a rolling upgrade with a single command.

Health checks are especially important in service updates. If a health check fails for a new task in a service update, that could mean there's a problem with the image. Completing the roll-out could result in 100% unhealthy tasks and a broken application. The default update configuration prevents this, so if an updated task does not enter the running state, the roll-out is paused. The update will not go ahead, but that's a better outcome than having an updated app that is broken.