Deploying to Kubernetes with Spinnaker

Spinnaker is an open source, multi-cloud continuous delivery platform for releasing software changes with high velocity and confidence.

In this walkthrough, we show a container approach, with Spinnaker deploying to Kubernetes, using Jenkins as the build server.

**Here’s the Transcript:**

Chris: Hey, this is Chris.

Isaac: And this is Isaac.

DROdio: And this is Daniel.

Ben: And this is Ben. And today we’re going to demo a piece of deployment software called Spinnaker.

Chris: Here we have our fantastic website. As you can see, we’ve got a production environment as well as a staging environment here. What we want to do quickly is make a change to this so that we can then roll that out to production. Let’s go and edit this and say something here. And we’ll just commit that. On top of that we’ve got our pretty standard Jenkins build here that’s pulling a GitHub repo to pull in the latest changes. Let’s just give that a little push since we don’t want to wait for it. This is pretty standard Spinnaker [flow – 01:05]. Do you want to tell us about that, Isaac?

Isaac: Yeah, sure. First, code gets pushed to GitHub. Just like you guys saw, we made a change directly in GitHub. Then the job is being pulled by Jenkins at that time. We forced the actual job to run. Now the job is being run. And what’s happening in the background is we’re creating a container and pushing that to a Google cloud repo that we have for ourselves. At that time, that’s when Spinnaker is going to start taking over and see that Jenkins started and completed a job and that there is a new artifact available for it inside of the Google cloud repository. And then we’re going to kick off a pipeline. That pipeline then looks and deploys that container that we deployed earlier through Jenkins. But now it’ll actually deploy it to a (staging) infrastructure. Once it’s there, we’ll run an integration test and make sure that everything that we deployed to the repo earlier works as expected. And once that’s there, we will manually accept the job to go to production or manually accept the artifact to go to production. Once that gets to production, we’ll actually be done. But when it goes to production, it does something that’s really interesting, which is it has a deployment strategy. So it doesn’t just deploy everything to production all at once. It goes through a Red/Black deployment in a strategy that allows you to deploy to production safely and doesn’t take your entire infrastructure down. And then it quickly allows you to roll back just in case there are any problems. So we’re going to walk through that today, and we’re going to show you that next.

Daniel: You may be more familiar with Blue/Green versus Red/Black but same difference.

Chris: Perfect. So here’s the build that we triggered a little bit earlier. If we dig into our pipeline here, here are the phases that Isaac mentioned, deploying to staging. If we go quickly back to our environments, we have production here. And you’ll notice that the extra question is here on the end that isn’t yet in production. So on staging now, that’s what we’re doing. And as Isaac mentioned, we deploy the new cluster, disable the old cluster, and then actually shrink that one since in this particular case, we’re using the highlander strategy, which is to destroy the old cluster after we use it. Once that deploys, we should have it surely.

Isaac: When you configure the pipeline, here are the different strategies that you can use to deploy. So we chose the highlander one for staging because we don’t necessarily need it to be very smart in the way it deploys. Staging environment can be destroyed and brought back up very quickly without really affecting anybody on production. So we chose the highlander strategy, which just destroys the previous server group. You can also choose a non-strategy, I suppose, which is create the next server group with no impact on the existing server groups. And that means that you’ll have two server groups in production without destroying the older one. And then you can do the Red/Black one, which is also called Blue/Green. But Netflix has popularized the Red/Black in the Spinnaker application. And this just disables the previous group instead of destroying the previous group. And this allows for easy rollback, again, if anything were to break or crash in production. Again, we specify the container that you guys saw us build earlier. And that’s what’s actually being deployed to stage and growing through the integration test that we’ll go back to. And hopefully, that’ll be closer to completion.

Chris: Perfect. We’ve deployed it to staging. And then Spinnaker has also run our integration tests. This is a simple script that you can set up to do anything you want during the process. Once it’s successfully run integration test in staging, the next thing before we go to production would actually be a manual judgment. So you can have your QA teams look over to make sure everything looks good. Once you’re happy with that, approving that will then move us across to the next step, which is actually to deploy into production. We should be able to see that we still don’t have the [version yet – 05:34] we have. We haven’t yet deployed to production.

Isaac: So now, instead of doing the highlander strategy, it’s going through the Red/Black strategy. If we click on the server deployment here, we’ll see that V003 is rolling out as we speak right now. The desired number of containers in production is 2. Currently, it’s 0. So right now it’s rolling those containers out to the production, making sure that their health checks are okay. So you see that the UI automatically updated without us having to do anything. So now the current state in production is 2. So if we were to go to clusters – and we need to remove this here – we’ll see here’s the old version that was there, and that’s currently being reduced by Spinnaker. So what Spinnaker is doing is rolled out V003. It made sure that the health checks are okay. And now if we go back and we go to the deployment, we’ll see that it’s disabling the old cluster. And that means that it’s bringing down the other containers and out of rotation of the load balancer. And it does this in a very safe way so that your consumers or your customers don’t see any real outage on the website and you’ve made those changes safely and you know that the application that’s in production now is working well.

Chris: Absolutely. And all of these pipelines are configured through the UI here. [unintelligible – 07:16] we could do in terms of if we wanted to change the way that these work. If we wanted to make it so that, for example, these different pipelines, these different stages were in parallel, we can do that through the UI here. And all of this is nice and easily configurable.

Isaac: Right. And it’s very configurable, enough so that you can do the things like canarying, again, the Red/Black. You can have just no strategy at all. It’s very configurable to any type of pipeline that you have existing today, and it adapts to a huge amount of different types of deployments. It works for Netflix, so it’ll most likely work for deployment of that new strategy you have now.

DROdio: While this is running, guys, one question that I would ask you to just mention on this demo is this is Spinnaker, which is a piece of software that somebody could implement themselves. But the thing that we’re doing here is we’re offering to host this. And is there anything that you would say about that, about us hosting it for them?

Isaac: Yeah. Right now there are a lot of subcomponents to Spinnaker, including databases, caches, seven to nine different micro services. And what we’ve done in the last few months is really get a deep understanding of Spinnaker, how it works, how the pieces connect to each other. And you could be managing that stuff for yourself. But if you’d rather be building applications that directly affect your customers and providing value for your customers and want to have us manage this, we’re here to manage it for you. And that way you can focus on providing value to your customer and let us deal with all the subcomponents.

DROdio: And Ben, for somebody who’s thinking about CICD, a higher level from maybe product management perspective, what are the benefits maybe for somebody who’s not as familiar as most people might be.

Ben: Sure. I think most people have probably heard of Agile development. And some people have heard of the lean startup. CICD goes hand-in-hand with both of those frameworks, with both of those strategies. It’s all about getting code product into your customer’s hands as fast as humanly possible. Agile is the way to build software. Lean is a methodology or a strategy for testing ideas and validating new ideas. And continuous integration can [use – 09:34] deployment helps actually push that code to customer so you can get feedback more rapidly. So it’s all hand-in-hand. And a combination of those three, I think, is a recipe for success.

Isaac: All right. So we just saw that the build pipeline to production completed. Thanks for that rundown there, Ben. So let’s go back to the production website. And what we should see if I refresh this is that it was deployed to production, and it went through the entire steps. And we feel confident that the deployment that went out is indeed what will be good for customers. It’ll be stable. It went through the Red/Black deployments. It went through a manual check if that’s something you’re looking to have. But that’s the end of the demo. Anything else?

DROdio: I would just say, if any of what we just said [unintelligible – 10:27] to you, even if just Chris has amazing Australian accent, we would love to talk to you. So please reach out to us, and then we’ll chat. Thanks.