Skip to content

Latest commit

 

History

History
59 lines (41 loc) · 2.13 KB

File metadata and controls

59 lines (41 loc) · 2.13 KB

Rollbacks

Automatic Rollbacks

  • Having manifests is optimal, IaC

  • Rollbacks though are necessary when things go wrong

Viewing the Rollbacks

  • When using a Kubernetes Deployment, history of rollouts is in the Clusters tab of your Application

  • Spinnaker exposes “Undo Rollout” functionality in two places:

    • Clusters tab

    • Pipeline stage

revisions

Ad Hoc Rollbacks

  • In cases where you see something is immediately wrong and isolated to a resource in the “Clusters” tab

  • You can select “Undo Rollout” from the “Actions” dropdown

  • This provides an opportunity to select a healthier alternative

adhoc

Automated Rollbacks

  • You can also configure automated rollbacks inside of Spinnaker pipelines.

  • These stages are best configured to run when other stages or branches fail, indicating that something has gone wrong in your rollout.

  • Number of Revisions Back:

    • Counts how many revisions the current active revision should be rolled back by. If you have the following state:

nginx-deployment-2d8178b77 (Revision 5) # active
nginx-deployment-7bdd110f7 (Revision 4)
nginx-deployment-0b13cc8c1 (Revision 1)

And roll back by “1” revision, (Revision 4) will be active again. Roll back by “2” revisions and (Revision 1) will be active again.

Keep in mind that Kubernetes will implicitly roll-forward the old configuration, creating (Revision 6) in both cases.

Parameterized Rollbacks

  • Parameterize the target resource to roll back

  • Reference anything via pipeline expressions

  • Point to something specified using pipeline parameters, for example:

    • Upstream deploy stage

    • Another stage’s outputs

    • Using pipeline expressions.

Versioning Artifacts

  • Rolling Back will not work unless artifacts are versioned, this includes:

    • Docker images

    • ConfigMap

    • Kubernetes Secrets