Spinnaker Training Series #6: The Highlander Strategy
Jan 7, 2018 by Armory
Ethan Rogers, resident Spinnaker expert, demonstrates how to use the Highlander strategy.
A Transcript of the video is available below:
What’s up guys Ethan here, your Spinnaker expert, thanks for joining us for another installation of our Spinnaker training series. Today we are going to be talking about one of the components in Spinnaker that makes your software deployment safer and that’s deployment strategies. Out of the box Spinnaker has a handful of deployment strategies that you can use to ensure that your software is deployed and available.
The one we are going to be talking about today is the highlander strategy and yes in case you are wondering that does come from the movie Highlander. So let’s jump in and see what we are going to do and then do a quick demo of how it works. So if you look here on our screen you can see that we have already got V001 of our nginx sever group deployed to our Kubernetes cluster. Now the highlander strategy what it does is once you have deployed a new server group, it will destroy all of the previously enabled server groups. So we can do that by jumping over into our pipeline and configuring it as part of our deploy stage. So in here we can see in our server group definition that we are deploying an nginx container and using the highlander strategy to do so.
The container is very simple it’s just exposing port 80. So what we can do here is jump back into our pipeline tab and start a manual execution. What we are going to do instead of deploying nginx1.11, we will deploy nginx1.12 and show that as we update things Spinnaker will handle orchestrating the destruction of previous server groups since we don’t want them around.
So we will search for 1.12-alpine in our tag list and click run. Now that we are actually deploying it, we can see what tasks spinnaker is going to take to deploy our new server group. Down here in this section we can see that we are deploying the highlander stack for version 2 and if we click task status we will see all of the different things that Spinnaker is going to do as it is deploying.
So the next thing we are going to do is jump back into our clusters tab while that’s running and view the new server group being deployed, and you will see here that version 2 is deployed and we can see the different tasks that are happening on that server group, and we can pop back over into our pipeline area to watch this play out. We will refresh a couple of times just to make sure, and we will see now that a new task has been started. Disable cluster task. So what that’s going to do, is it’s going to disable the one that will be destroyed. Disabling is just a way of pulling a server group out of a load balancer and by disabling it before we destroy it we can ensure that we are not dropping any customer requests to our application. This is critical in maintaining your SLA, making sure that your application stays as available as possible. And kind of one of the great things that Spinnaker provides is these deployment strategies, so that you don’t have to worry about the semantics around disabling or terminating server groups yourself, spinnaker will handle that for you.
So now that this is running, we can jump back into our clusters tab and see that the version 1 server group is now disabled, we can see that over here in this section. Spinnaker will tell us that it is disabled, and anytime you see a grayed out out server group, that just means that it’s not actually serving traffic, it’s been pulled out of the load balancer. In some cases you may need to disable a server group that may be misbehaving and it is really useful to be able to do that over here on this right hand side, and as this keeps progressing will notice that the different tasks that are being handled are displayed right here as well as in our pipelines tab we can see all the different things that are happening, we can check the status on them, so right now the disable cluster task is waiting for the cluster to actually be disable and pulled out of the server, out of the load balancer and now it’s refreshing it’s cache.
Now that that’s actually succeeded, the shrink clusters task will take effect. Now since we are deploying pretty a much one for one server group this isn’t really going to take anything into account. If we had more instances running than the one that we deployed it will shrink them. So now that our pipeline has successfully completed, and we can jump back into our clusters section and notice that version 2 has been deployed and version 1 no longer exists. That has been a demonstration of the highlander strategy, be sure to check back in for more videos as we talk about more deployment strategies and the different ways you can use them.
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 →