Update & Rollback Strategy
Reduce downtime during deployments and configure automatic rollback options.
| Field | Description |
|---|---|
| Order | Defines whether the new container starts first, or the old container stops first. (default: stop-first) |
| Parallelism | Defines the maximum number of containers updated simultaneously. Setting this value to 0 will update all containers at once. (default: 1) |
| Delay (seconds) | Defines the time delay between rolling out service updates processed in batch by what is configured in the parallelism option. (default: 0s) |
| Max failure ratio | Defines the maximum tolerable failure rate as a ratio of passed/failed Dockerfile healthchecks to determine when to trigger the failure action behaviour. (default: 0.0) |
| Monitor (seconds) | Defines the duration a task is monitored for Dockerfile healthcheck failures after the update has been published. (default: 5s) |
| Failure action | Defines the action taken when an update results in failed Dockerfile healthchecks. Options are: - pause: halts the update- continue: continues updating the service to the desired replicas- rollback: triggers an update rollback to the previous service configuration state(default: pause) |
Publishing Updates
The update strategy defines the behaviour new and existing containers when updating services. You can learn more about Docker update options here. Configuring the update strategy can improve the availability of Docker services and decrease the disruption to application clients when updating services.
Delay does not consider healthcheck intervals
When using load balancer healthchecks and defining an update strategy, it's important to note that the update strategy delay does not wait for the healthcheck to pass before continuing to rollout the service update.
It is recommended that the delay is long enough to allow for the containers to pass their load balancer healthchecks. Configuring this correctly can reduce downtime for clients when running many service replicas.
Automatic Rollbacks
The update strategy rollback configuration defines the behaviour when the update failure action is set to rollback and there are Dockerfile healthcheck failures that exceed the failure tolerance threshold.
When a rollback is triggered, the service configuration is reverted to its most previous state.
Be careful of breaking changes
Rollback needs to be used carefully because if there are multiple services that depend on each other where only one of them fails and rolls back, the rollback version of the failed service update could have incompatibilities with the successfully updated services.
For example, the case where an update with a database migration is successful in one service, but an API service that interfaces the database fails to update, introducing a breaking change with the rollback of the API service.
Updated 26 days ago