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.

Recently Published Posts

A Faster Way to Evaluate Self-Hosted Continuous Deployment from Armory

Sep 30, 2022

Introducing Quick Spin One of the most common challenges that organizations face when implementing a continuous deployment strategy is the time and focus that it takes to set up the tools and processes. But a secure, flexible, resilient and scalable solution is available right now. Want to see if it’s the right tool for your […]

Read more

3 Common Spinnaker Challenges (and Easy Ways to Solve Them)

Sep 27, 2022

Spinnaker is the most powerful continuous delivery tool on the market.  DevOps engineers and developers recognize this power and are looking to use Spinnaker as a foundational tool in their Continuous Integration and Continuous Delivery (CI/CD) process for hybrid and multi-cloud deployments. Such a powerful, expansive open source tool needs expertise within your organization to […]

Read more

Streamline Advanced Kubernetes Deployments from GitHub Actions with New Armory Service

Sep 23, 2022

Today, Armory is excited to announce the availability of the GitHub Action for Armory Continuous Deployment-as-a-Service. GitHub is where developers shape the future of software. After a developer writes and tests their code in GitHub, it must be deployed. Armory’s GitHub Action for Continuous Deployment-as-a-Service extends the best-in-class deployment capabilities to Kubernetes. CD-as-a-Service enables declarative […]

Read more