keptn Keptn Lifecycle Toolkit, 21 Mar 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keptn Lifecycle Toolkit: Installation and KeptnTask Creation in Minutes

Description

This video demonstrates how to install the Keptn Lifecycle Toolkit (KLT) and create your first KeptnTask in under 10 minutes

Learn more: https://lifecycle.keptn.sh
Join us in Slack: https://slack.keptn.sh
Star us on Github: https://github.com/keptn/lifecycle-toolkit
Follow us on Twitter: https://twitter.com/keptnProject
Sign up to our newsletter: https://bit.ly/KeptnNews

A

Video I'm going to show you how to install the captain, lifecycle toolkit and also have the captain lifecycle toolkit trigger a captain task. Captain lifecycle tasks run on the Deno engine. Basically, if you can write JavaScript, you can write Deno go to webhook Dot site and basically this website whenever you send a post or get request to the website, it's gonna show up here, I'm just using this as a dummy to show that something actually happens visually.

A

So let's have a look at our Deno task and you can see here all I'm doing here is doing a fetch to the website. So if I do, Deno run allow net, which is allow network access and then the file name, deno.fetch dot, JS see it runs and we've got our get request. That is what we want. The captain lifecycle toolkit to do rather than me running it manually so now that we've got that we can go ahead and create our cluster I'm going to use kind to create a cluster.

A

Next thing to do is double check that the cluster is the right version. So if you run Cube CTL version short Captain lifecycle toolkit must run on something higher than version 1.24, so you can see I'm at 1.25 and 26 I'm all good to go. The next thing I'm going to do is pull down the captain. Lifecycle toolkit manifest file for, in my case, version 0.7.0. Your version, of course, when you're watching this might be slightly higher.

A

The reason I'm doing that is the Manifest file needs to be altered slightly to run on my local machine. So if you do a search for CPU colon and just go down you'll see, one of these has I. Think it's yes line or 227 for demo purposes. I need to shrink that, because my machine isn't big enough, so I'm going to shrink that to 10 and save the file and then apply it to my cluster. So first thing we need to do is create a namespace for the captain. Lifecycle toolkit from the default is Captain.

A

Lifecycle. Toolkit system then apply the Manifest file.

A

Wait until all of the pods in the captain life cycles, toolkit system are running and now it's time to deploy our workload. So an absolutely bog, standard deployment and service would look like this. Of course, we're just going to deploy nginx with one replica and a service so that we can get to it and there we are our nginx is running. So let's expose the nginx on port 8080, pointing to Port 80, just to make sure everything works.

A

And there's our nginx, nothing special so far, okay, so let's integrate the captain. Lifecycle toolkit to wrap that process, wrap the cube. Ctl apply the deployment and Trigger our task out to webhook.site. So the first thing we're going to need is a captain task. A captain task is a custom resource definition that looks like this. It has a name and it has a function with some in in my case inline code, and you can see it looks a lot like the Deno runtime.

A

In fact, it is because this block here is just a block of JavaScript, so apply the custom resource definition into the same namespace as the engine X. So in my case, the default namespace and if you use Cube CTL to get the captain task definitions, you should see one that's called Center webhook site. So how do we tell Captain lifecycle toolkit to integrate with our deployment process? It's actually simple: we just need to annotate or label up our deployments.

A

Now you can do that with standard kubernetes, annotations and labels, or you can use Captain specific ones depending on what you've already got in your environment. So the standard kubernetes recommended labels are part of name and version, or you can use the captain ones. Captain.Sh app, slash workload and slash version. You can see I've added, a part of which is our concept of an application.

A

Now kubernetes does not have the concept of an application out of the box, so I'll get back to that in a moment, but the name is the name of our deployment, pretty straightforward. The version is whatever we decide so version. 0.1.0 I'll, explain this in a moment, so go ahead and add these three labels to your deployment. Next, we need to build up the concept of an application. As I say, kubernetes doesn't have the concept of an application out of the box, so Captain has provided one again. It's a crd of a Kind Captain app.

A

We give it a name and we deploy it into a particular namespace. We give the application itself a version and a revision. Those fields there are different to the workloads so think about a more complex example where you might have multiple microservices.

A

Those multiple micro services are the workloads, but we wrap all of those multiple workloads into a concept of an application and, of course, your workloads will have different versions to each other, but also different version ends to the actual higher level rapper The Logical application, so our workload is called nginx deployment that must match the name of the deployment or, more specifically, it must match. Whatever is in this name field here, the captain app has a version 0.1.0 and again that must match what is written down here. So that's the link between them.

A

The final link is this part of field or, if you're, using the captain app it's the um it's it's this annotation here the app that must match the name of your captain, app fantastic. So once you have all of that, we're going to go ahead and apply this Captain up.

A

You can say: please get me the captain apps and there we are. We have our website application. The final piece of the puzzle that I said I'd come back to later. Is this annotation here captain.sh post deployment tasks now as you've probably already guessed, this task will fire after the deployment occurs so think about it. On a timeline we are going to do the deployment of our app of our nginx just like we would and then we're going to trigger that Captain task.

A

Remember we created it at the beginning of the tutorial called send to webhook site and just as a refresher. That is the definition. So we can safely apply this now and you can see our nginx is successfully deployed. So if we go across to webhook.site you'll notice, we don't have anything. Why is that? Well, actually, that's safety. Well, we have one final step to actually enable the captain lifecycle toolkit on this namespace and again, it's all to do with annotations, so to enable the captain lifecycle toolkit for a specific namespace.

A

We have to add this annotation onto the namespace and now, let's do another deployment, so I'm going to bump my version to 0.1.1 just to make it visual I'm going to bump the replicas to two and then, of course, I need to also bump the version. In my captain app file here.

A

So I will deploy everything and I. Think I forgot to save the replica, so I've only I've still only got one replica in reality, but you can see when I get my pods I've got my new engine. X pod here and I've also got a pod that says KLC post sent to webhook site. So what happens when the task runs? It spins up a pod. It does whatever we've defined in the um Captain task definition as a kubernetes job.

A

So now, if I flick across to webhook.site, we can see that the captain task has actually triggered. So when you're writing Captain tasks. As long as you can write JavaScript, you can write Captain tasks and, of course, as you can see, there really is no limit to what you can do with the captain task. So I hope this was helpful. Reach out to me. If you ever have any questions thanks a lot bye.