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