13.2.3.4 Orchestrator Rollback

Orchestrator rollback uses a platform like Swarm or Kubernetes' own built-in rollback capability, gradually and automatically reverting a deployment to a previous revision while maintaining service availability throughout the process, a meaningfully more sophisticated capability than a direct Compose-based replacement.

Performing a Rollback in Kubernetes

Kubernetes tracks deployment revision history automatically, allowing a straightforward command to revert.

kubectl rollout undo deployment/myapp

kubectl rollout status deployment/myapp

This automatically reverts to the immediately preceding revision, gradually replacing currently running pods while monitoring the rollout's progress.

Rolling Back to a Specific, Non-Immediate Prior Revision

Rather than just the immediately preceding revision, a specific earlier revision can be targeted directly.

kubectl rollout history deployment/myapp
kubectl rollout undo deployment/myapp --to-revision=3

Performing a Rollback in Swarm

Swarm provides similar rollback capability for a deployed service.

docker service update --rollback mystack_app

This reverts the service to its previous configuration, applying the same gradual update mechanism Swarm uses for forward updates.

Why Orchestrator-Managed Rollback Maintains Availability

Both platforms apply the rollback using the same gradual, rolling mechanism used for forward deployments, replacing instances incrementally rather than all at once, maintaining overall service availability throughout the reversion.

kubectl get pods -w

Watching pod status during a rollback confirms this gradual replacement behavior in action.

Why Orchestrator Rollback Matters

Built-in orchestrator rollback capability provides a considerably more sophisticated, availability-preserving reversion mechanism than direct replacement approaches, making it a significant advantage of choosing Swarm or Kubernetes as a delivery target for applications where maintaining availability during a rollback genuinely matters.