Skip to main content

Out-of-the-Box Rollbacks With Spinnaker

Feb 21, 2017 by Isaac Mosquera

What Spinnaker Considers a Version

One of the great features from Spinnaker is the ability to have consistent & dependable rollbacks to previous version of your service. This is distinct from your application which Spinnaker consider as one component of the service. While it’s true that the main driver for change in your service will certainly be your application (e.g. my-mobile-api-v1.23.3), consumers of that service experience the integration of all it’s parts (e.g. my-mobile-api-v1.23.3, Nginx 4.23, Ubuntu 14.04, OpenSSH 12.4, etc). This also includes the mechanisms to deliver the service such as networking and load balancing. A customer is concerned with the service a whole and less about which one of those components caused a failure. What Spinnaker considers a version is the combination of all these dependencies, not just your application package (e.g. my-mobile-api-v1.23.3)

How Spinnaker Implements Versioning on AWS

Spinnaker leverages AutoScaling Groups (ASG) to manage versioning of as many of those components as possible. Spinnaker does depend on an AMI to be “baked” but that isn’t what is considered the immutable deployment object, it’s the ASG which includes the AMI along with other deployment details. In Spinnaker parlance this is called a Server Group. Every-time there is a new deployment, the service doesn’t update the existing ASG but instead releases a new version and appends that version to the ASG name. Below is an example of an ASG in the AWS console deployments by Spinnaker.

ASG

Below is an internal application called hellodeploy and how that same ASG appears in Spinnaker. The active version of the entire deployment is v012 and because it was deployed with a blue/green deployment strategy, Spinnaker leaves v011 in an inactive state. The ASG contains the AMI information but all of the ELB, VPC and subnet details as well as shown in the previous screenshot.

Versioned ASGs

When ASGs are versioned in this manner it makes rolling back trivial because we can enable old ASGs and disable the new ones when the old ASG becomes operational. This is also because much of the custom operational complexity from service to service is encapsulated in the ASG and baked AMI.

Easily Rollback

This provides the safest most reproducible way to rollback because the ASG is immutable and doesn’t change over time. The blue/green deployment strategy will leave as many versions behind as you configure. Additionally, the workflow engine provided by Spinnaker allows you to do sophisticated deployments that help you scale server groups up and down as needed.

Learn More

Recently Published Posts

July 26, 2021
|
by Phebe Vickers

A day in the life of a TAM

I’ve been asked what a Technical Account Manager (TAM) does so I wanted to take the opportunity to illustrate it by walking through a standard day in the life. Before we can look at what a day in a life of a TAM is, I should provide some background in what is a TAM and […]

Read more

June 29, 2021
|
by Nikema Prophet

Nikema’s Spinnaker Summit 2021 Recap

My Second Spinnaker Summit is in the Books! Last week I attended and spoke at my second Spinnaker Summit. Like last year’s summit, it was fully virtual. This time Spinnaker Summit was co-located with cdCon and took place on the Hopin platform. Last year, I spoke on a panel about Black professionals a few months […]

Read more

June 28, 2021
|
by Stephen Atwell

Announcing General Availability of Armory Policy Engine Plugin

Armory Policy Engine provides support for automating policy compliance with Spinnaker. Policy Engine Plugin is the latest version of Policy Engine and adds support for both advanced role-based access control (RBAC) use-cases and open source Spinnaker. The release of Policy Engine Plugin comes with new documentation, including a library of example policies from across Armory’s […]

Read more