keptn Community videos, 26 Apr 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keptn: Putting Observability into the driving seat of Continuous Delivery - CDF Webinar

Description

Putting Observability into the driving seat of Continuous Delivery? It's simple: You define your SLOs (Service Level Objectives)! Keptn takes care of orchestrating your favorite delivery tools (Jenkins, Argo, GitLab, ...) based on the data from your observability platform (Prometheus, Dynatrace, DataDog ...)

Join this webinar and learn the latest from the Keptn team. We answer common questions such as: how does Keptn fit into Argo, Flux or Jenkins? How do I let Keptn integrate other testing and notification tools not supported out-of-the-box? How can I get started? How can I contribute?

About the speaker: Andreas is a DevOps activist at Dynatrace. He has over 20 years of experience as a software developer, tester and architect, and is an advocate for high-performing cloud operations. As a champion of DevOps initiatives, Andreas is dedicated to helping developers, testers and operations teams become more efficient in their jobs with Dynatrace’s software intelligence platform.

References:

* Project website: https://keptn.sh/
* Meetup page: https://www.meetup.com/CD-Foundation-Online/events/285267023/

A

So and we are live so thanks, everyone uh for waiting, uh we are still studying new systems and how they integrate with each other and yeah. This time with me messed up. So thanks a lot for your patience and we are happy to start the webinar. So today we have india grammar who will uh talk about putting observability into your convenience and delivery and maybe continuous integration pipelines and yeah. This is uh first cdf webinar after a long break. So you know you see a proper t-shirt today and yeah.

A

Our goal is to talk about everything: continuous delivery. Captain interoperability you're welcome to join captain channels, you're welcome to join the cdf channels. I will be posting all of them um in the corner here and in the youtube chat, and if you have any questions also, please use the youtube chat, because uh this, uh where we can collect all the questions- and I will be asking andy uh during the presentation- so that's it from me and yeah. Please welcome andres grubner, also a cdf community ambassador.

B

Yeah, thank you so much and thanks for uh being the magician behind the scenes, I know sometimes we run into technical challenges, but you are great and also fixing them and getting everything up to speed. uh Welcome everyone. Let me actually start sharing my screen and I'm moving things around here on my screen and, let's make sure I'm sharing the right thing, which should be my slides all right. So I do have a combination.

B

I have a couple of slides, but not many, because I really want to show you uh captain live and then hope to get a lot of questions from you so see this as your opportunity to really get to know captain better and also, if you have specific questions, um then just let me know so to get a little bit more information. um My talk in three acts, so I want to first talk about what is captain for people that are not familiar with have a couple of new slides that I put together.

B

Second thing is why we built captain as a reminder on that we are not just solving a problem that has already been solved multiple times before. Well, people try it, but um I really want to show you why we think we're different and then how captain works. Architecture extends extensibility.

B

So, first of all, what is captain for those that are new. For me, captain is an open event and data driven automation, framework for devops engineers and essays. Now today we talk a lot about continuous delivery, obviously, but to to remind you what captain really allows you to do? It allows you to orchestrate multi-stage delivery, so you will later see me specifying a deployment task, a test task, a validation task and then, if everything is good, it gets released into the next stage, and uh but captain is more than that.

B

So just for completeness captain is not just focus on delivery. Captain is really using the orchestration power that it has to also orchestrate will be called day one and day two operational tasks, meaning helping you to roll out your canaries into production or execute remediation actions. So think about this. If there's a problem that is coming in in production after you've deployed something captain can assess the situation can then make a decision on what to do next. It could be a rollback, it could be a scale up.

B

It always validates that either the situation is good, then perfect, if not reassess the situation, try to figure out what next, hopefully, eventually, this loop will end in a happy scenario where everything is going back to normal. If not, you can also escalate. Now you may wonder andy. This is no different right. This is just if this do this, then that right.

B

Well, I disagree here because what we do as a very key component to all of this is captain makes data driven decisions based on slos service level, objectives, which is a key component of site, reliability, engineering or a key keycap, a key methodology. So what this really means captain at the core connects to your observability platform or to any observability platform to pull in metrics sli's. That's what we call them. Initially, we started with prometheus support.

B

Then we added dynasty support uh the community just recently built datadog, but nothing keeps you from implementing and connecting to any other observability platform that you have now. Most importantly is that captain is not replacing your existing tools that you have for delivery, test notification, ticketing or configuration management. It connects to those tools so really what it does.

B

It's an orchestrator of sequences that then connect to your tool of choice at the right moment through standardized events, and this is a big thing again for us- we're working with the cdf and the cd events team to really standardize the way we communicate with all of these different tools, because one big problem we want to solve. We don't want to be yet another tool that connects to other tools and connects them through a proprietary api.

B

We want to standardize the way we connect all of your different tools that you use right now in your tool belt. We want to connect them through a standard event mechanism and at the core we want to make data-driven decisions based on your observability data, all right. So a core component is the slo-based evaluation, the data-driven decisions, and you will see later in my demo and also, if you know captain already, then the evaluation task is a core task of captain that you can place in any part of your automation sequence.

B

Now, when the evaluation is processed, what that means is internally- and this is a service that comes with the captain control plane. When you install captain so-called lighthouse service, the lighthouse service is the one that is reacting to the evaluation request. The first thing it does, it says: hey, show me the service level objectives that the user has specified service level objectives will be specified in a so-called slo yaml. You can see here, error rate, jvm memory, count db calls and you can specify pass and warning criteria and also a total score.

B

Now. The lighthouse service itself is not retrieving data for this. It sends an event that is then picked up by exactly your observability tool, whatever you have so to give you two examples: if you have prometheus or dynatrace, you would therefore over whoever is responsible for observability platform and knows how to get certain data.

B

Those teams can specify in the sli gamble how to, for instance, query error rate count db, calls jvm memory, http, request, total. You can see it for itself right. You basically specify the queries that are then executed by your observability platform and we have so-called sli services that can take care of this. Those integrations with the observability platform will then return the values and then the lighthouse service is really doing the job of taking the values that have been returned by observability platform for a certain time frame.

B

Let's say: if you want to evaluate a test execution, you can give it the time frame for when you're in the load test. If you just did a production deployment, you can say how is my production doing after 5 after 10 after 15 minutes, so the timeframe is something that will flow into this, but the lighthouse service is then retrieving the data, comparing every single data point against the objectives in your slo and then grades every single metric and then comes up with a total score to be again normalized between 0 and 100..

B

So this is at the core of captain and also, I believe, the reason why it is different, because we see a lot of other tools. You have these capabilities, but they're typically bolted on. For us it is kind of core of captain. Now, let's see the whole thing in action, let me just switch over to my browser here. We go all right.

B

So, first of all, if this is the first time you see captain please and you are interested in more- you can go to the captain website. Captain.Sh more information can also be found on our github repositories. This is github.com captain our core repository, where you also find links, first of all, on how to contribute how to join the slack, uh how you also find additional organizations, contrib and sandbox, and also sockshop for some demos, again, all the information you need now. In my case, I have kept running here and, let me and with running here.

B

Let me also quickly bring up uh my terminal window here. So what I have captain itself runs on kubernetes. That means you need some type of kubernetes cluster. It can be, you know any of the big ones uh if you go also to the cloud: vendors, the hyperscalers and eks and aks the g key. In my case, I just run a k3s lightweight kubernetes.

B

We also have tutorials to run on on kind, so any type of flavor will do when you install captain like in my case, you get the core components, and I just want to highlight a few, for instance, the bridge. This is the ui that you see in the back. We call this the bridge. What else do we have the api gateway right?

B

That's an important one that actually gives you access to the api, because not only do we have a ui, but we also have an api that can be used to configure and to interact with kept and trigger automation. What else is interesting? The lighthouse service I mentioned this earlier right. Lighthouse service is the one that is doing the evaluation.

B

I also have, in my case, the dyna choice service installed. That is uh giving me the integration, the connection to my dynameter's observability platform. I have low cost here as a testing tool. I have argo here, argo, rollouts, helm and and so forth, right and maybe at the very core, the shipyard controller, which will take care of a lot of the of the actual orchestration.

B

So if you install it lightweight, uh you get the idea now, captain itself is organized in projects, so I have different projects here and I just want to start with the release validation, because this is what I see most people start with. I have my release validation project. By the way I'm running here, which version do I run around 14.1, which is, I think, the latest version out there. It really includes a couple of new cool things in the ui in the bridge to trigger sequences and so on now the way a project is structured.

B

You always have stages, at least one, but it can be multiple. I have a production stage and then you can also have multiple services services see them. Initially, we thought a service kind of reflects your micro service, but really service is just a configuration entity. It can then point to whatever you want to point it to really right. It's just a configuration entity. Now, in my case, I have my aapl service.

B

So in case, you wonder when I to tutor my tutorials and my workshops typically include a scenario where I give my attendees my workshop attendees ownership of an app there and they're responsible for it and in order to separate them out, I I used stock symbols, apple, acer and then there's others like this is just a very small one just for two, but you get the idea now what's important here is, since I want to show you kind of the core uh of of captain and kind of the first use case uh here.

B

This visualization actually really shows me what what what I think why I think captain is so great because at the core we allow you to ask captain. Please do an evaluation, remember the evaluation task and what I've done here, every kind of column here, every column um kind of represents, when I asked captain to run an evaluation, an evaluation that was then pulling in different metrics, remember slis from my observability platform and is then comparing it to the objectives.

B

Now, if you move, if I move the mouse over, you can actually see the individual values that were pulled back and then also how it compared with the pass or warning criteria, and this is also why you see some of them are red, because here I missed the mark, the green ones are the good ones and then also we are calculating a total score. Now, if I scroll down a little bit, there's a couple of things you see.

B

First of all, you can see that we are also showing everything in the table view where every metric that was pulled back is shown here with the metric value and then also with what it was compared to you can have comparisons against a static threshold or also against a previous comparison or a previous evaluation. So you can actually do regression detection for every metric here you can also see different weights, so you can weight every metric differently because something might be more important than others. um What else is there?

B

The past criteria, the warning criteria, the individual result and then the score that this particular metric kind of contributed, and then we just normalize everything to 100 and that's it. Okay.

B

You can also see here I have some additional metadata executed by andy another build. You know what let me actually execute one more because I want to show you something here, but I want to go to the sequence view. The sequence view shows me all of my previous uh evaluations that I ran, so I can click on and see every time captain triggered or executed an automation sequence, and this one, as I said, is the most basic one just develop.

B

I can trigger a new sequence, and now this is actually really nice, a new ui component, where I'm, in the context of my release, validation project I can now trigger in so-called evaluation. I pick the service and then I pick the stage I click on next now for the evaluation. I have two options. I can specify either a time frame or I can use a start and an end uh time frame is nice because I can say please evaluate the last.

B

Let's say 30 minutes um right: this is a use case where you just ran a test, and now you want to evaluate the metrics that just came in in the last 30 minutes. You can also give it uh your labels so build id is a key label that I want to highlight here it will. You will see it later in different in different areas, but I can, for instance, say build what do we have cdf webinar april 26?

B

I can do executed by equals andy, and maybe it was triggered through right and obviously I'm not triggering it through. My uh my ui here, but a very common use case would be to trigger this, let's say from a github action or from a jenkins pipeline. So if you have like oh my dot, jenkins.myorg.com slash job slash my job right.

B

If this would be the job that triggers it, because you can also from jenkins trigger this to an api, then we can pass in the link back as so-called label and it will show up later in our ui again as metadata. It's also clickable. So if I click on trigger sequence, what happens now?

B

um I'm asking captain: please execute an evaluation sequence. um I can see here the metadata build cdf webinar 20 april 26 executed by andy trigger through. So if an external tool would call it great, I would get the link back now. This is now running and here's what I wanted to highlight. I talked about events earlier. The way captain is actually interacting with external tools, but also with the internal tools, like the lighthouse service. All are the same. They all communicate through the same eventing standard.

B

So, first of all, when you trigger a sequence, you are just sending in a so-called cloud event with a particular data package here or data payload. So here the cloud event type is shcaptan event production, because this is my stage evaluation triggered. It basically means please trigger the evaluation sequence in production. Now, here's the project, context the service and again the stage is twice here and then there's some additional data, like the labels, the metadata, also the time frame that I pasted in now. What captain is really doing?

B

It's now, looking into my definition of my sequence, now my sequence is very boring. There's only one task in there the evaluation, uh still same concept. Kepnes then saying all right. I now need to trigger the evaluation task and in my case it's the lighthouse service that is picking it up.

B

The lighthouse service is then picking it up and says: hey. I am ready to go so the lighthouse service then say hey. I am the lighthouse service and I am just started the devaluation. So let me do my job and so on and so forth. I'll show you in a second a little bit more of what else is possible, but I hope you get the idea. Also. A very key component is here under settings where you have the option. First of all, to integrate other tools so under settings there's a section called uniform.

B

This is where you see all of the integrations. All of the we call them captain services that are currently subscribing to those events. Now, there's a couple that come out of the box with your captain installation like the remediation service, the lighthouse, the approval, the webhook service.

B

I additionally installed the helm service and argo service, the dyna trust service, the monaco, the low cost and so on and so forth, and you can see here that these services, what they have in common they run on a target platform by this means, while captain itself is the control plane that runs somewhere like mike, is on an ec2 machine. I can have other services that are listening to events and then reacting on it. I can have them installed anywhere.

B

If you have multiple kubernetes clusters, or even they don't have to be kubernetes clusters, it can be a windows system, it can be anywhere where they can call to the control, plane and say hey. I am the monaco service, the dinatris service, the low cost service and I'm interested in a certain event. So please I will call you and every time you have something to do for me. Please give me that event.

B

A very cool and out-of-the-box service is the so-called web hook service, and I like this in particular, and here's the reason why, because the web hook service makes it super easy to just integrate any additional tool adhoc on the fly, because if you click on it, you can see here on the on the bottom.

B

We have these subscriptions, so I have subscribed to events just to show you one of them, and I've done this earlier this morning, because I did another event and I just said hey: whenever the evaluation is finished, then I want to post it to a particular endpoint. So this is a webhook.site, I'm not sure if you're familiar with this uh this website, but it's a really convenient one where you just get a unique url, and you can just it's basically for testing web hooks, and you can see here just uh two minutes ago.

B

In a minute and a half ago my web hook was triggered, and it seems that my latest evaluation just finished with a warning score. 86 points, and here's also the message now how why do I get this over here? Because if I go back to my definition, I basically said whenever captain is done with the evaluation task, then I want to send a web hook to this endpoint and then you can also specify here the payload and the nice thing is.

B

You can pick any type of payload that comes with the cloud event for that particular event, type right. So, for instance, the git commit the results, the score this is all available now.

B

This is something obviously that you wouldn't do like I mean this is just a dummy environment, but if, if this would be a token, we also give you secrets custom headers to show you another example. If I go back to integrations, go back to my web hook service. The second thing that I've done here I have or again said for evaluation finished. I want to make a post to uh my slack api, so slack provides web hooks as well.

B

Here I put my slack token into a secret and then I'm just sending in um you know this is kind of the payload that slack expects. So if I now go over here, then I can see at 6 23 now it's three minutes ago. I received also this message in slack. The cool thing is, I can just subscribe to an event and then I'll get the event. Now I want to do a little bit more.

B

um I want to show you one a little bit of kind of one advanced use case because we talked about delivery, but for me this was important that you know that this is a common use case to really integrate this automated validation capability.

B

Now I have a delivery demo project, but also a demo roll-up project and that's the one I want to show you the demo rollout project.

B

This is where I have specified a little advanced or a little more advanced use case, and with more advanced I mean this is what we see a lot people, starting when they're interested in continuous delivery with captain. So here I have, as you can see, staging and production in staging.

B

I have a delivery sequence and I actually executed this one as you can see here. uh While I was at devops days last week um what this sequence does again from the outside, you trigger it the same way you basically say hey, I wanna trigger the delivery sequence in staging. This is my automation project. This is the service context. Here's some metadata now for the delivery use case, you may wanna add in configuration changes that you want to happen as part of that delivery sequence.

B

So, in my case I will later on have our helm integration, where helm can take a values block here under the configuration change block and can apply this to my values, values.mls and then use helm to to actually apply my helm chart. um So this is what I'm pasting kind of putting in now. In my case, delivery has then a couple of sequences specified the first one is actually called. Monaco monitoring is code where I have integrated my dynatrace, but dynatrace is being automatically configured as part of that step. Then I have my deployment.

B

This is where helm comes in helm. Does the initial deployment that's great, then? I have a validate step now in my validate step. I have a so-called generic executor service, where I'm executing a shell script on a target environment that is basically just validating. If the url that was deployed by my deployment step can be reached. Now you may wonder: how does the url get passed in? Well, my deployment was triggered, then the helm service says I'm taking the job and when the helm service finished, it actually responded and said hey by the way.

B

I'm I've been working on this, I'm the helm service, the deployment test. I just finished it with pass, so everything went, went smooth, um but I have some additional information for you. Here is the url that I deployed to and there's even the git commit right.

B

So every tool can then define additional and enrich uh the event with more details, and then what captain really does it will take this data that comes back from helm, also from monaco. It kind of collects the data and then pushes it on to the next task. In this case, validate and in my case validate, has been handled by a tool that we have out there, the generic executor service. We also have the job executor, there's different things, how you can trigger things.

B

I really like the job executor now, but in this example I have the generic.

B

This one will then call a certain script and it assumes that it just gets certain data like the deployment url, and this is how I can then validate it now. What's next after validate release, I'm using argo rollouts here, so I've integrated argo. So we have an argo integration that is listening to that event. To that release, task request and is then doing a blue green deployment right then we have a test event where I'm running some low cost test, which is also pretty cool low cost, is one of the testing tools.

B

We see a lot, then the evaluation kicks in and if everything is fine, then it goes over to production where in production the way I phrased it is, I said, initially, I'm doing a delivery, so I'm deploying the new helm chart validate test again. If everything works. Fine and then I am using different canary phases where I'm always using release the release task to then let argo rollouts go from 20 to 50 and so on and so forth, and in the in between, we always evaluate a certain metrics.

B

Now you may wonder this looks like a lot of magic. There must be a lot of configuration behind the scenes. Well, there is configuration, but not a whole lot.

B

So if I go back to my captain overview, every project, as you can see here behind the scenes, has a git repository and you can set an upstream git like in my case, I'm just using kitty. You could be bitbucket, it can be gitlab, it can be github, but for every project we basically keep a configuration repository where, in the main branch we have the shipyard file. This is the first thing you need when you create a new project.

B

Now remember earlier, when I showed you the delivery sequence, here's a delivery sequence in the staging stage- and here I have monaco deployment, validate release test evaluation approval. This is all the process. Definition right that captain. If I go back again, go over here go into my delivery sequence and if you remember, if I go back to staging delivery sequence, monaco deployment validate release test. Let me switch back delivery sequence. Monaco deployment validate release test evaluation approval, so you're specifying the process here and captain is then orchestrating the process.

B

By sending events now remember these events need to be picked up by a tool that is listening to it, but we have a clear separation between process and tooling here, which is pretty cool, because everything is event based. You can subscribe to an event. I can have a different tool to configure my monitoring subscribed for one project for one service over one environment and for the other, so also rollback sequence here that will be triggered on in case my staging delivery finished with a result fail, and then I called a rollback task.

B

Rollback is then handled again with our argo rollback integration, so really cool stuff that you can do it because you just specify the process. Now you may want okay, where's, all the other data. Where does whether the slice and the ose slos live? How do you know how does how does help know what to deploy well, in this case, for every stage for every automation stage, we always also have a branch in here we have subfolders for your automation.

B

Services now remember quickly, go back to captain in this demo rollout project I have staging and prod, and I have a service that is called simple node, which means in my demo rollout git repository under my staging branch. I have a simple node folder, where I now have all the files that are relevant when a tool is participating in a particular automation step. Every tool that is participating is triggered by the event can actually call back to captain and say give me the files for that stage for that project.

B

For that service that belong to me, so, for instance, here is where I have my helm. Charts right here is where I have all of my helm, charts that will then be picked up by helm, uh or what else do I have? I have my locust test scripts there, and here or I have my slo ammo.

B

This is where the slos are specified and if I want to change that, I can change it here. Next time I run it. Captain will automatically take this particular criteria right. So this is. This is really powerful and again always what I like so much about it. We are not just providing you with another tool that can do call tool a to b to c and then make a decision. First of all, the decisions.

B

What's really powerful is the decision based on slice and slos. So you can pull in multiple metrics from your observability tool. It will automatically evaluate it, but then the real power, I believe, comes because we're not just calling a tool and we're enforcing or we're forcing tools to have the wrong proprietor api. We are standardizing currently through the cdf through the cd events, what the payload is for certain tasks to be executed, because I know there's many delivery tools out there.

B

There's many testing tools out there many notification tools, they all have their own proprietary api, it's a pain for many tool, vendors to build and to maintain these integrations, because every time a new version comes up of a particular tool. You already integrated with chances. Are it breaks the api and then it breaks your scripts.

B

We want to counter this by providing a standard on how we want to communicate with the different devops tools, deployment tools, testing tool, evaluation notification.

B

So this is ongoing work, obviously, but this is kind of how this works right. So I I think for me really powerful. Now I want to quickly uh check in with olek if any questions came in so far, because I have not yet no.

A

No, no, there is no unanswered questions, so there were some follow-ups in slug, but uh we are handling everything synchronously, okay and yeah. Quite a lot of nice content.

B

Yeah cool, then let me, let me show you a couple of more things. um Let me quickly go back to my slides.

B

um What I, uh what do you? Probably people, know well who is adopting it? This is just a pet project or what is anybody adopting it? Well, we have, I just bring it two that are relevant to ci cd uh reifies and software. They are the software company that builds most of the online banking software in austria.

B

They are using this they're using this uh just evaluation capability right now, which means they have the jenkins pipeline.

B

They are deploying with jenkins, they are testing with jenkins, but then they are calling captain to evaluate their key metrics, there's also a nice blog article about it, and we also already had them on a on a captain user group. Another one- and this is another captain user group we had. um This- is kind of more what I have just shown. You is our friends from volusion uh and entity data, so artemis from entity data.

B

uh They have basically built uh a multi-stage delivery pipeline using captain with argo and and chain meter and then dynatrace and helm kind of similar to what I've shown you in my example, and really roll it out and then making decisions based on observability data.

B

We also got some nice comments and I think I've used this uh in the in in the past, because I really like it so much that at the core we have this concept of slis and slos, where we really make data-driven decisions, just as a human being would do right, you deploy it and you look at your dashboard, your logs, and we just automate that for you and we make it agnostic to your observability platform right because we are using standardized events to then communicate with your tools, and this gives you all the or the options on where the data comes from.

B

So act number: two. Why we build captain. uh Why did we build captain? I know like you- have been obviously part of the jenkins community for many many years. So you know how powerful jenkins is in other tools um and which means there is no shortage of options to build these pipelines or these orchestration workflows yourself, you can execute tests, add results, you can do all this stuff right. Nobody keeps you from it. That would be if sorry.

A

Go ahead, that's the question of how many resources you are ready to put to maintain that, because even on this slide, I see probably too much uh groovy script and I'm big fan of uh scripted pipeline and jenkins for the record yeah, but yeah. Sometimes it's difficult to maintain it, especially if you don't have experienced team uh that is ready to decay time on continuous basis.

B

Exactly and- and I also say it- I also love the power that jenkins and other tools give us, um but I've also seen things like you know. Coming to one of our colleagues. Now I mean he used to be working at ert as a senior devops engineer, now he's a diamond trace, but when he was still at ert, he used a different tool. Yet he ended up with very complex and very long scripts pipeline scripts that were hard to maintain. It was not just one script. That was a thousand lines long.

B

uh It was many right and and and this is just very hard to maintain and what happened to us internally at dynatrace- and I brought this example many times. We are also a big jenkins shop and have a lot of jenkins pipeline, and when we moved to more micro service architectures, we obviously went with jenkins years ago. uh We had kind of our standard template um jenkins pipeline, but then every team came in and said: hey. We need a little a different testing tool here.

B

We want to have a different way to deploy, so then we modified it, and then we ended up with what we call the snowflake effect and what we did. We then did some pipeline code duplication analysis, and we saw that we had a high level of code duplication in these pipelines right the same code.

B

It was copy pasted, but then also it was not maybe perfectly componentized so that you could reuse the same components, a lot of duplicated code, and this just makes it very hard to scale, and this is why the conclusion for us was the left side is great, but it doesn't scale it's hard. You need a lot of resources, and this is why we needed a new approach with captain.

B

So how does captain work? You saw it in action already, but let me explain again: uh captain really manages the life cycle of your orchestration and what our initial thought was. Looking at these examples I just brought.

B

We know that a lot of you have these very lengthy pipelines, a thousand plus lines long, where you have hard-coded integrations for individual steps to a particular monitoring tool to a particular deployment tool.

B

Oleg mentioned itself, I just saw a lot of too much config already to also config files in in the pipeline, and- and this is something that we it doesn't scale, and so we said okay, what we need to do is we need to get rid of these dependencies. We need to separate the process on the left from the tooling on the right.

B

We need to make sure that any configuration lives in git and that we then use eventing to connect the process. The tasks on the process with the actual tooling, and to give you an example, even though you've seen it earlier, automating performance is a very common use case that people start with. So you would have a on the left side, a sequence, that's called performance in the stage staging, and then you have tasks, deploy test evaluate and on the right side.

B

You have like these four tools: monitoring deployment, testing and notification tool, so you can trigger captain. You saw me earlier tweaking it through the ui. You can also trigger such a sequence through the cli with an api. But basically, what happens? Captain will look at your definition. It says hey.

B

The first thing is a deployment I'm taking all the information I have I'm sending over an event and then, whichever tool is subscribing and here's the cool thing already, you can see the deployment tool is subscribing to the deployment and says yes, I can deploy in staging and I know how to do blue green. Let me deploy it and it sends back when it's finished, but also notification tool like like slack.

B

What I had earlier can subscribe to those events and there's always three events, there's always a trigger for a task as started and the finished. So you can subscribe to any of those tasks and either decide to become active.

B

Saying I want to do something and let me know how, when I start them when I'm finished, but you can also be more passive uh kind of just listening and just doing something with it like sending a notification to slack right. But then, if once the first task is done, captain goes on. If everything is good to test same thing, testx gets executed and then the evaluation kicks. In now we call the left side the shipyard. The definition of your sequences, is in defined in the shipyard file.

B

The tools we call the uniform the config goes into a config repo and then the events are all cloud events with a specific payload and metadata, and this is again what we're currently standardizing through the cdf through cd events, special interest group just for completeness, even though you saw it earlier second use case automating, the canary rollout, just what I showed earlier on the left, a different set of sequences on the right.

B

Maybe you are adding different tools and the thing is still the same: captain trigger canary rollout in a certain stage, some additional metadata on top like what image just came out of your ci and then captain is following through, and it's just the same thing just what we saw earlier right.

B

So from my perspective, um captain brings opinionated cloud native automation to all of your projects, so you can either do the left side or you can try the right side. The nice thing is, it connects with all of your tools. We are not replacing any of your tools, that's very important.

B

We are just connecting them and we're bringing in um the automated evaluation with the slos that's built in, and we're also standardizing now so that you don't have to go through the pain anymore and connecting all these tools we're working very closely with our community. um You know things we are getting asked a lot. How does this integrate with jenkins? We just had a great captain user group last week with renee who showed us how he was basically componentizing a large jenkins pipeline and then kept orchestrating the individual pieces.

B

We're getting a lot of questions about argo and flux. How does this work together so here again, argo cd is great for delivery and therefore captain can trigger delivery by triggering an argo, um an article workflow to do to get the delivery done uh and then does the testing. Another thing we've seen if you're already great, with or if you're, already good, with uh argo cd uh re, you know, detecting, uh that is a sync is necessary with the git repository, because something has changed.

B

Let argo do its job of deployment and then use the notification mechanism in argo to then trigger the captain workflow, where captain can then do testing evaluation, and if everything is good, it can then promote that change into the next git repository. That again, then kicks off your argo workflow for the next.

B

So the nice thing is, you can really fit captain in as you see fit in the ideal case you have captain across and it's doing the end to it, but you don't have to right if you are comfortable with what you have, but you just need individual pieces like the automated testing. The automated evaluation then start from there um yeah. I guess you can see for yourself, I always bring in. I always call it left. Side is the main, and this is.

A

B

Slide because it's nice to see why you want to have a look in captain, because we've seen just a lot of improvement and a lot of less code, which means less technical depth, potentially um yeah. So that's that's, I think the benefit. So to sum it up here- and hopefully there are some more questions- um captain gives you a cello driven automation, so, whoever you are pick your use case. Quality gates, delivery, ester re-automation order, remediation, there's also other use cases.

B

Remember in the very beginning, I talked about all the remediation, bring your configuration so bring your shipyard file, your slis, then your configuration of your specific tools, your helm, charts, your load, testing tool, your load, testing scripts and then connect your tools to captain by letting those tools subscribe to the events, and then captain manages the rest through an event driven approach, all right, so this is it. uh This is definitely the content that I wanted to get through.

B

I also know um I showed you some of the demos and now I just want to see if there's any more more questions. Oh, like.

A

Yeah, if you have any questions, please put them in the chat or in slack wherever I posted the link. I monitor everything. Well, at least I hope so.

A

There is actually one question about how you deploy captain within the company, because we have continuous delivery for a single product, maybe or for a single component, or maybe there are independent, devops teams contributing for each uh component within a larger system. So what would be your recommendation about deploying captain in the organization.

B

Yeah, so I've seen different things, so I have seen organizations where they have one captain like I have here and then they are. The captain instance is shared with different development teams, every development team. Then you know, if I go back here, they may have different projects, so you can you can organize it by projects. That's one option um the drawback of this approach. Right now, and I'm saying right now, because this has been worked on is uh we are soon getting our back uh robust access control.

B

Once we have role based access control, then this approach is great. You have a central captain and then you can give different users access to their different projects right now it is once you have access to. You see everything right, but this is something that we're working on and I think uh it's actually, the first iteration of arabic is coming very soon. The second thing I was just visiting some customers in texas last week or users and what they have done. They have their provides and automated.

B

um I think an eighth in azure there they're operating in azure and they were providing terraform scripts, where every development team can get their own captain instance on demand. They just can run their terraform script and then they're deploying uh captain on aks. You can deploy multiple captains even on the same kubernetes cluster, because uh the captain control plane itself, like you, can see here by default.

B

uh It goes into the captain namespace, but what what what you can do is you can install multiple ones in different namespaces and then you can separate it out like that. um That's also what I've seen I really like the um this customer or this user in in in texas, who just made a self-service. So every team can just uh get their own captain instance and then they can do whatever they want. So I think these are the two options that I would go for.

B

The third option obviously is- um and this is just a little commercial here, but just really short as dyna trace. We also provide a hosted version of captain and the hosted version. Let's call it, let's just name it better. uh We are providing the capabilities of captain as part of our observability platform, so it means, if you're a damage race customer. Then you can get this from us and you don't need to care about hosting it.

A

Nice thanks for the review, so yeah. Another question was about uh what's next for captain. So what's your vision for that.

B

uh Well, there's a lot of things. um I think what we are currently focusing on, or the several areas I think I mentioned are back. uh I mentioned some enterprise capabilities that that a couple of enterprise organizations have asked us um our role-based access control is actually one of them. High availability there's. Definitely some topics that are swirling around for me. I'm very much looking forward to some of the improvements when it comes to all the remediation.

B

So one thing that I don't have here, but projects from where you can call captain in case there's a problem and then captain can execute a sequence of tasks to bring a system back to a healthy state, either by rolling back by scaling up by making configuration changes uh and then all this stuff uh coming there.

B

um I'm I'm also very much looking forward to there's a lot of improvements in the bridge. This is the ui and I know there's many more coming, because what we've learned initially, we tried to make sure that our users can, you know, automate a captain. So we have a very strong api where you can really.

B

You know automate everything and you can, for instance, you know you can manage your projects and your services and your stages and all that uh and you can also trigger um you, know tasks. So, for instance, you can trigger an evaluation. You can trigger any type of event.

B

What we're now doing, and what we're seeing more and more is getting these capabilities into the ui. So, for instance, one of those was what I showed you earlier trigger a new sequence. You can now, as I mentioned right, I mean you, can create new projects within a project. You can now also create services, so these are some of the things we're now bringing more and more into the into the ui.

B

Another thing that I'm looking forward to- and this is what one of our colleagues is driving- is through gitops, meaning being able to declare your state of captain your projects, your services, your sequences, your tasks sc or these in kubernetes, and then we have an operator that then make sure that captain, um uh you know, has all this configuration and then it's a true, true kit, ops, because right now what we, what you've seen here this is, you know git based, meaning all the configuration.

B

Isn't it that's true, but in order to stand up this configuration, you still need to configure captain by setting up the project through the api. So this is a this is one of the things we're doing here and I also hope to see more integrations, more integrations being built by the community um strengthening some of the integrations like we see a lot of demand on the jenkins side to build and to improve our integration.

B

We have a great jenkins library right, and I know when all of this is a topic that we've discussed uh the last couple of weeks. There's some there's some great stuff happening here, but but we see a lot of users that are using jenkins and I think we have a lot to give and we just need to make it easier for them to integrate their jenkins pipelines with captain.

A

Right and just a quick disclaimer, so in the chat I checked a link to captain roadmap, so the integrations section is not finished as well as ui ux, and they mentioned before so.

B

A

Come back maybe in one week and there will be a lot more content there. I'll be sure there is a lot of contributions and thanks a lot to all captain community members who work on integrations because we receive uh so last month, we received more than 10 integrations, some from job executor service, some through webhook service, but also native integrations, and actually it helps the captain ecosystem to cross to grow quickly.

B

A

To everyone who adopts captain and extends it for their needs.

A

Okay, there is another question in the chat, so we have standard templates for uh services and for integrations with observability tools.

B

uh Yeah, so the I think the best is, if you go to captain sandbox. um This is where you find a couple things. First of all, uh there's a captain service template for go. uh So if you wanna write your own integration, it's a so-called sli provider and I think the best way to get started is the captain service template go. You can also look at, for instance, something like the the data dog service, how they've implemented it by the way. You can also do it in python.

B

As you can see here, we have different templates, one of the things that I can also tell you is and now- and I just need to remember a new this pack- captain sli provider, because I did the presentation um on a custom, sli provider, and I provided the whole example.

B

I think that's it exactly so I basically built a sample sli provider that was pulling data from a json file and the whole code is here in in my pick, sli provider. I think that's.

B

That is something let me see if I can easily get this over to you. Olek.

B

This is this one, and then this is a presentation where I really showed like how the whole concept works of of sli providers and then the reference, implementation and yeah and then also writing your own sli provider. In five minutes.

A

B

A

Yep also, it was mentioning that now we have two generic integrations, so one is job executor, service, nd presenter, another one webhook service. So if your observability tool has rest api or it if it has cli, you can easily integrate by just uh doing uh while creating a proper container or just by passing a web hook. Rest api call from captain.

A

So there is a lot of opportunities and examples demonstrated so, for example, slack integration, etc. Slack is not observability tool, but you can see the principles how it work and the implement for your own tools.

B

A

um Yeah and and last question about the integrations is: are there any us? Is there any integration with asia.

B

uh With asia devops yeah, I think there's two things we have, uh I mean there's an asia devops extension out there that was built by by a diameter's partner a while ago, and then it's currently being kind of reworked a little bit.

B

But what we have seen is that most azure devops users, most organizations, are not kind of allowed somehow to just download third-party extensions from the azure devops marketplace, and therefore most of them are just using bash scripts to just make calls to the captain, cli and there's a couple of, uh I think rob has a great selection robian, one of our colleagues, a great selection of of those powershell scripts that can then be integrated uh in in azure devops, just to kick it off yeah.

B

So I would say the most common integration use case is just through a powershell script that is making a rest. A simple rest call to captain to trigger a sequence.

B

And if you want to know more jump on the captain's leg channel and ask in the integrations slack channel- and we can give you the answers. Yes,.

A

So just uh john captain slug, I shared the link before in the chat and if you want to try something I don't know what to do. There is a help channel where you you get added to it by default, and we will assist you to find proper information and discussion channels.

A

Okay, so we are on time and.

B

A

I don't have any questions in my backlog as far as I can tell so thanks a lot andy for the presentation, yeah, it's very comprehensive and uh nice to see you both use cases for captain yeah.

B

A

For everyone who is going to keep con, we will have a captain booth there, uh all the days we will also have uh um uh project office house. On thursday. It's already announced uh on the community chapter, uh which I.

B

A

I also shared, and there will be more events like bugbush and also we participate in cd events day, so this specification uh referenced. So if you go to kubecon and definitely you can meet uh us then- and we are happy to chat about captain and maybe do some presentations and live demos. If you want.

B

Cool all right, I need to jump. Thank you so much bye-bye.

A

Yeah thanks india and yeah. If you're interested to subscribe to our cncf chapter, uh we do at least two presentations uh every month. uh User group is a great case. Studies from our users and also there are developer meetings tomorrow. We do github's working group meeting so if you want to manage githubs with captain or if you want to use captain together with other services, also join us there's a lot of discussions and yeah, see you on slag or just comment on youtube. We will also follow up them. So thanks a lot.