Jan 7, 2018 by Armory
Ethan Rogers, resident Spinnaker expert, demonstrates how to use the Highlander strategy.
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.
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 →
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 →
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 →