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
How to Take the Pain of Rollbacks out of Deployments
Software applications have become an integral part of the business climate in most modern organizations. With an ever-increasing demand for new features and enhancement of already-existing ones, software teams constantly face novel challenges, and the pace of software development is growing by the day. To keep up with this fast-paced business climate, software teams […]
Read more →
Monitoring Spinnaker: Part 1
Overview One of the questions that comes up a lot is how you monitor Spinnaker itself. Not the apps Spinnaker is deploying, but Spinnaker itself and how it’s performing. This is a question that has a lot of different answers. There are a few guidelines, but many of the answers are the same as how […]
Read more →
The Importance of Patents: Interview with Nick Petrella, Head of Legal
In honor of Armory’s recent acquisition of a patent for continuous software deployment, we sat down with Nick Petrella, Head of Legal, for a casual conversation covering a wide range of subjects, from patent law to Nick’s background as a software engineer and why he made the leap to the law. Check out […]
Read more →