Spinnaker Training Series #7: Red/Black Strategy

Jan 8, 2018 by Armory

Ethan Rogers, our resident Spinnaker expert, explains how to use the Red/Black strategy to deploy to server groups.

Note: This content refers to Spinnaker’s legacy Kubernetes provider (V1), which is scheduled for deletion in Spinnaker 1.21. We recommend using the manifest-based provider (V2) instead.

A transcript of the video is available below:

What’s up guys Ethan here, your Spinnaker expert, thanks for joining us for another segment of our Spinnaker training series. Today we are going to be talking about deployment strategies and how to use them to get the most out of your software deployments. The strategy we are going to be talking about today is the red/black strategy more commonly known as the blue/green strategy. What this strategy does is take any previously deployed server groups and disable them so that your new server group is the one that’s takes traffic but you have instances available for quick rollback. It does this by pulling the previous server group out of the load balancer. So what we are going to do today is am going to show you how to build pipeline that uses the red/black strategy and then what it looks like when you are using that strategy for your deployment. Let’s get started.

So will notice here initially that we have the V000 server group deployed. All this is, is two instances of nginx running in Kubernetes. So if we look at our pipeline configuration, we will see that we have a deploy task stage setup to deploy to the Spinnaker training cluster and it is the red/black stack. So if we look at how our server group is configured we will see that we are just, the only thing that we are doing is selecting the red/black strategy. Now there are a couple of options here that you may want to take into account as you decide what’s best for your deployment, the first one is this check box to scale down replaced server groups to zero instances. What that will do is instead of just disabling your previous server group it will actually destroy the resources. Now this maybe cheap if your application is quick to start up or it may be more cost effective for you to leave your instance running. Now we can choose to leave as many previous server groups as we want, say we are deploying really frequently and we want to be able to rollback more than just the most recently deployed version. We can adjust that here, we can also wait a certain number of seconds before its disabled, perhaps we want to start serving traffic on the new server group and leave that running for a period of time before we destroy or disable any previous ones. That’s what we are saying here.

So we will just leave these sets to the default for this case and I will show you quickly what our deployment looks like. We’re just deploying a simple nginx container that expose port 80. So if we go into our pipeline execution window and start a manual execution we will then deploy the 1.11 tag of nginx, and we will select 1.11.1 alpine and run it. So we will click in here to see our deployment actually taking place. So the red/black strategy is going to start deploying v001 of our new server group. We will see that if we pop into our clusters window. What it’s doing is telling Kubernetes to go ahead and start the new instance of our application. It’s important to point out that this is not just a Kubernetes specific deployment strategy, you can use this for all the different cloud providers that Spinnaker supports.

So we will refresh to start seeing our new server groups come into place. I just refreshed to kind of bring the processes forward a little bit quicker. We can see now that Spinnaker is starting to disable the v000 server group and as you recall from previous videos, disabling just means being pulled out of the load balancer just to stop serving customer traffic. The great out nature of this box just means that we are disabling the server group.

So as part of this we will see that the disabled cluster task is now running. What’s that doing is disabling our previous server group and leaving the newest there. As this keeps going if you are constantly trying to hit your application, trying to make a request to your application you are not going to drop any customer traffic, and that’s important in meeting SLAs, and we will pop back into our clusters tab and we will notice that v000 is still there it is not yet, it is not destroyed it is just disabled. At this point version 1 of our server group is taking traffic, version 2 may continue to version 0, excuse me may continue to drain traffic until it is successfully completed.

We will go back into our pipeline execution to monitor the status of this and we are still disabling the server group, right now is just verifying that the server group is disabled, and there we go, now it’s done. The reason that you may want to use the red/black strategy is you want to enable a quick roll back. The difference between red/black and highlander is that we can roll back, if you recall from the previous video highlander just destroys any of the non-new server groups. Red/black will leave these in place so that we can actually click on the disabled server group and then the use the roll back server group action. Now we are going to, not going to talk about rolling back a server group today, we will save that for another video but I hope it was really useful for you to see how to set up a red/black deployment very simply with Spinnaker.
Thanks for watching.

Share this post:

Recently Published Posts

Navigating AWS Deployment Targets with Armory

Jan 20, 2023

Many organizations look to Amazon Web Services (AWS) to host and deploy their applications in the cloud. However, they’re finding that their deployment tooling, often built as an extension of their legacy continuous integration (CI), is one of the main impediments to adopting cloud services.  Custom-scripted production pipelines built with in-house tooling need to be […]

Read more

Release Roundup – January 2023

Jan 11, 2023

Get the latest product news on Continuous Deployment-as-a-Service and the most recent release for Continuous Deployment Self Hosted, 2.28.2. Welcome to 2023!  Just like every organization, Armory is looking for ways to improve our practices and deliver more value (and faster!) to you, our customers. That’s why our engineering team is working to deliver features, […]

Read more

Learn Continuous Deployment with Armory and Wilco

Jan 6, 2023

Armory is excited to announce we have launched an interactive, narrative-driven developer experience that teaches continuous deployment concepts. And now you can try it out for yourself! Wilco, also known as the “flight simulator” for software developers, allows companies to create engaging interactive developer challenges (called quests) that enable developers to acquire and practice skills […]

Read more