Controlling Service Updates, Rollback, and Failure Handling

When an update to an individual task returns a state of `RUNNING`, the scheduler continues the update by continuing to another task until all tasks are updated. If at any time during an update a task returns `FAILED`, the scheduler pauses the update. You can control the behavior using the `--update-failure-action` flag for `docker service create` or `docker service update`. In the example service below, the scheduler applies updates to a maximum of 2 replicas at a time. When an updated task returns either `RUNNING` or `FAILED`, the scheduler waits 10 seconds before stopping the next task to update: ```console $ docker service create \ --replicas 10 \ --name my_web \ --update-delay 10s \ --update-parallelism 2 \ --update-failure-action continue \ alpine ``` The `--update-max-failure-ratio` flag controls what fraction of tasks can fail during an update before the update as a whole is considered to have failed. For example, with `--update-max-failure-ratio 0.1 --update-failure-action pause`, after 10% of the tasks being updated fail, the update is paused. An individual task update is considered to have failed if the task doesn't start up, or if it stops running within the monitoring period specified with the `--update-monitor` flag. The default value for `--update-monitor` is 30 seconds, which means that a task failing in the first 30 seconds after it's started counts towards the service update failure threshold, and a failure after that is not counted. ### Roll back to the previous version of a service In case the updated version of a service doesn't function as expected, it's possible to manually roll back to the previous version of the service using `docker service update`'s `--rollback` flag. This reverts the service to the configuration that was in place before the most recent `docker service update` command. Other options can be combined with `--rollback`; for example, `--update-delay 0s`, to execute the rollback without a delay between tasks: ```console $ docker service update \ --rollback \ --update-delay 0s my_web ``` You can configure a service to roll back automatically if a service update fails to deploy. See [Automatically roll back if an update fails](#automatically-roll-back-if-an-update-fails). Manual rollback is handled at the server side, which allows manually-initiated rollbacks to respect the new rollback parameters. Note that `--rollback` cannot be used in conjunction with other flags to `docker service update`. ### Automatically roll back if an update fails You can configure a service in such a way that if an update to the service causes redeployment to fail, the service can automatically roll back to the previous configuration. This helps protect service availability. You can set one or more of the following flags at service creation or update. If you do not set a value, the default is used. | Flag | Default | Description | |:-------------------------------|:--------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `--rollback-delay` | `0s` | Amount of time to wait after rolling back a task before rolling back the next one. A value of `0` means to roll back the second task immediately after the first rolled-back task deploys. | | `--rollback-failure-action` | `pause` | When a task fails to roll back, whether to `pause` or `continue` trying to roll back other tasks. |

This section discusses further service update configurations, including `--update-max-failure-ratio`, `--update-monitor`, and how to manually roll back a service to its previous version using `docker service update --rollback`. It also explains how to automatically roll back a service if an update fails by setting flags such as `--rollback-delay` and `--rollback-failure-action`. These features help maintain service stability and availability.