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.
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 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 →
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 →
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 →