2:41 Introduction

2:41 Hello, and welcome back to the Rawkode Academy. I'm your host, David Flanagan, also known across the Internet as Rawkode. Today, we are taking a look at a piece of open source tools to help simplify and flexify words I've just made up here Kubernetes deployments. Today, I'm joined by the creator and maintainer, Alexander. Hey, man. How's it going? Hi. Thanks for having me. I'm good. How are you? Yeah. I'm doing very well. I'm always excited to see a new tool in the Kubernetes space, especially when I'm not entirely sure how to pronounce the name. But today,

3:01 Guest Introduction (Alexander Block, creator of Kluctl)

3:17 we're taking a look at Clue Control, Clue CTL, Clue Cuddle, Clue Cuddle. Anything else you wanna add there? I would say just late into the hands of the community. Don't know. All this, so Clue CDL is fine. Clue Catalog is fine. Everything is fine. Clue Control. Let's go with that one. Alright. Yeah. Great. Could you please take a before we start talking about Clue Control, just take a moment to tell us a little bit about you and what you've been up to, please. Yeah. My name is Alexander Block. You can also call me Alex or Coda Block when

3:50 I'm online. So same handle used on Twitter and GitHub. I'm a senior DevOps engineer, back end developer, software developer. I'm a consultant, freelancer, and I'm very excited about open source development. So I'm trying to do that whenever possible. I'm trying to contribute whenever possible. And Kluctl or Kluctl Kluctl control. Yeah. We we we started to call it Kluctl. It's kind of the first big project that I started from scratch and which is kind of my my own baby right now. So yeah. Awesome. Thank you for sharing. Maybe you'd like to give us the quick TLDR

4:33 What is Kluctl? (TLDR and History)

4:37 of what Kluctl Control is. Now I know we're gonna have some slides, so just give us, the thirty second kind of pitch. Like, what is Kluctluctl? What's the history? Why why did you start building this thing? Yeah. I'd I'd describe it as the missing glue. So that's where the name comes from, by the way, Kluctl with k instead of g and without the e. So Clue, Glue, whatever. It's the missing glue between tools that already exist, for example, Helm and Customize, and it's kind of a front end to these. It allows you to define multi environment, multi cluster

5:11 deployments, and it has a CLI to control these, actually to do the deployments, to diffs and dry runs and so on. So, yeah, that's Clue Studio. And in these slides, I will try to explain how it came to that tool and what's the reasons reasoning behind that is. Alright. Without further ado, let's hand over to your slides then. If you wanna get them ready, I'll pop the scene over. And as always, there are people watching, Please feel free to add any questions that you have throughout the session and to the chat and comment box, and we will do our best to

5:31 Transition to Presentation

5:45 tackle them. Great. Alexander, your slides are now live. Take it away. Great. So I assume you can see the Kluctl scale logo? We can indeed. Great. So let's start. So just a small agenda for the slides. I'll try to make it as short as possible, so not so much slides. The hands on is the most important stuff that comes later. So who am I? Just why another tool introducing ClueCDL and then the actual hands on. I already explained why I am, so I think I can skip it. Let's go to why another tool. So I've been working on many, many deployment

6:21 Why Another Deployment Tool? (Problem Statement)

6:25 projects in the past. It started with plain Docker, then Docker Compose came and Docker Swarm and later Kubernetes. And it turned out that every one of these projects had the same requirements and same problems to be solved. On the next slides, I'll try to give an overview of these and describe why existing tools did not solve them. It won't be the focus, but I'll try to do it kind of in between. So of course, one of the most important requirements is infrastructure as code. So everything 100% must be as code, meaning it should be part

6:56 Key Deployment Requirements (Infrastructure as Code, Automation, Reproducibility)

7:05 of version control and yeah, so that you don't have to type in kubectl all the time and recreate everything by hand. I prefer declarative code whenever possible, but there are still situations where imperative parts are still needed. As an example, having declared everything is good, but in the end, you still need to adhere to deployment order, for example. As an example, you have to deploy a namespace before you can deploy any other object onto the namespace. So that is kind of a mix of decorative and imperative. It must be fully automatable and reproducible, and for me, it was always important to

7:53 at least allow the coexistence of GitOps and DevOps in a seamless way. I'll explain that later a little bit. Another requirement is I always needed to have to support multiple environments, so it's not enough to just have a bunch of YAML files and just deploy them to one cluster, and that's it. That's not enough. We always have multiple environments. We have tests. We have dev. We have production and so on. These are not necessarily on the same cluster. They are actually quite often on different clusters. So you have a prop cluster, have a test cluster and so on.

8:02 Key Requirement: Multiple Environments & Clusters

8:31 It's, at least in my opinion, should always be the target to have as much parity as possible between environments, so they should look like the same or at least have the same source and shouldn't have that much differences. In practice, that's not always the case because, for example, if you deploy something on your local machine, you will probably not deploy all the monitoring stuff while you would deploy that to prod. Next requirement is it's always required to have proper secrets management. I prefer version controlled encrypted secrets with public key encryption, and it always turns out that there are

8:56 Key Requirement: Secrets Management

9:10 nice tools to do that. But the hard part, which is key management and actually encrypting the correct secrets with the correct public key for the correct cluster is actually the hard part of that. So next thing is deploying some environment, for example, dev to a prop cluster, by accident should be impossible by design. What I mean with that is if I, as a DevOps engineer, want to deploy something to dev, I should not first I shouldn't have to figure out what context to use. I shouldn't have to figure out what other credentials are required. I shouldn't have

9:29 Key Requirement: Deployment Safety (No accidental deployments)

9:50 to figure out what configuration I should choose to deploy to dev. My deployment should self define what dev is, so what the environment dev is, what it means, which cluster it is, what configuration, and so on. That means environments must be a first class concept. That's a requirement that I had for myself all the time. Next. By the way, if you have questions in between, just stop me and ask them whenever you want to or comments or whatever. Also, when comments arise or something like that. So the next topic, configuration management. To meet the previously described requirements,

10:33 some form of configuration management must be possible because environments differ in all kinds of variations. There are simple variations. For example, prod needs another database than dev, and it gets more complicated when, for example, your local deployment doesn't even use an external database but wants to deploy its own database because it doesn't have one externally available. Yeah, and then there are other examples. For example, if you have a test environment, it might be useful to deploy a mail interceptor, something like mailhack or mailhawk, I don't know what it's called, while you never would like to deploy that to

11:14 prod. So that gets a little bit more complicated in regards to configuration management. So in my opinion, templating is a must, and I believe that overlays are not enough to solve that. You can solve most of that with overlays, for example, with customized overlays, but it will get hard and feel unnatural if it gets too complicated. At least that's my personal experience and opinion. Next requirement I always had is I want to move fast. I'm a very impatient DevOps engineer. Stuff must happen immediately, and I must be able to change stuff as fast as possible

11:54 with the security or the confidence that what I do actually results in what I want to do. For that, I need a proper logical project structure that feels natural. What that means is so if I open my project in two weeks after I close it today, I must be able to immediately understand it because it's kind of natural to the way I think and how I structure my stuff. If, for example, something's based on customize and overlays, I often got to the point where it didn't feel natural anymore, and understanding my own stuff was very hard

12:35 after some time because that's not how I think. Yeah. Boilerplate that doesn't add value should not be present at all. At least that's what I believe. If I just want to add one YAML file and just one resource and that's all I want to do, it's I don't like to add too much boilerplate to just do that. For example, adding a Helm chart just to add a small module that adds one YAML is too much, at least in my opinion. Without the requirements met from above, refactoring and high risk changes are no fun, which usually leads to not doing refactoring and

13:17 not doing high risk changes or at least postponing them forever. Then I'd like to avoid push and pray workflows as much as possible. So when I remember my first days as a DevOps engineer, one thing that was the most, yeah, not fun part was to do a change, commit it, push it and wait for Jenkins, GitLab, whatever to finish a pipeline. And just after a few minutes knowing that my change was actually broken and then redoing the same workflow again and again and again. So that means I want to develop locally and I want to test locally,

13:58 And I mean everything. So I must be able to completely verify locally that my deployment will actually work no matter how simple it is, no matter how complex it is, no matter how small or large my change was. Based on that, day two operations should be supported in some way or at least made easier. That means I must always be able to determine the current state of my deployments, so not just look at Git, for example, and see, okay, that's the state how it's defined. I must also be able to verify that this is really the state of the

14:33 cluster. GitOps kind of allows that, but not in all cases. And if you want to mix DevOps with GitOps, then you need other ways as well. Next thing is I must always be able to predict what consequences my changes will have. That means if I change a helm value, for example, I must know what consequences that change has. Just looking at the changes in git will just tell me, for example, that one value has changed. But the templating behind helm might result in very big structural changes of whatever I deploy, And I must have a way to actually

15:12 see these changes, for example, by having a dry run being applied and then seeing the logical diff or the structural diff. Then I must always be able to determine what consequences my changes actually had. So even if I assume that this will happen, I must later be able to verify that it happened. That means I want this, this, this, and much more this and not just keep this. So basically, that means what I just explained. A change in a HIM value does not reflect what really will happen. I want to have a full diff of the state

15:50 before and after my change. Yeah. If these requirements are met, I think that DevOps or the daily business as a DevOps engineer becomes a breeze because you get into a point where a change doesn't make you paranoid or cause fear and kind of make you avoid doing changes to plot or something like that. Yeah. Opening the gates to hell. All the available tools on their own were not able to solve all these requirements in the last few years. It was always required to do some kind of deployment orchestration or glue code, as I call it.

16:37 It and from my experience, it always starts like, it's just a few lines of bash. Let's start with the deploy.sh, tell it which environment to deploy it to, and then we are happy. I'd say a %, you'll wake up in hell after some time. So at least use Python or maybe a dedicated tool that solves all this. Yeah. So next next one is actually introduce you closely. Do you have any questions or comments so far? I would say that based on what you've described, clear control is promising a lot, and I'm quite excited to what we're we're gonna see

17:16 in this definition. Like, you've touched on a lot of really valid concerns, like Yeah. You know, especially the helm one resonates well with me. I've been in that position before where you make what you think of it as a professional change to the values dot YAML, and then you end up destroying the entire deployment in a production environment or maybe even not production, but still an important environment because prod isn't the only one that important. Yeah. In the end, every environment is important because if it causes you extra work to fix what you just broke,

17:48 I mean, you've you've lost time that you could have spent in different ways. But I don't QA. It could be staging. It could be performance. It could be p prod. Like, all of these environments need care and attention. And, yeah, I don't like being the one to break it. So and I've done it before with a helm values thing. It's something, again, trivial. I'll just change this one parameter, but actually, the repercussions of that lie deep and cascade down all the other deployments. So Yeah. I'm excited to see what Kluctl control is gonna bring to kinda bring that under

18:16 management. Yeah. So no questions right now, but a lot of excitement. That sounds good. That's a good start. Maybe to to get more to that point with with Helm. So when you have when you are using Helm and, like, you're using a lot of Helm charts, you, of course, have to maintain the used Helm charts in the form of doing updates and pulling in changes or new versions and stuff like that. And so without proper tooling, you are kind of blind. You see, oh, there's a new Redis release. Let's pull it and deploy it, and we

18:54 are happy. The problem is, Redis is good example, at some point, they changed, I think, slave to replicas in the deployment mode, which meant that your existing configuration was invalid because you are still you were still using the old naming for the deployment mode, which would completely break your deployment without you having changed any of your configuration. So what you actually need is you need a way to dry run or do a diff for the changes that you just did or if you do helm updates and stuff like that. So I can say that the projects where Kluctl is in use, we

19:38 have no problem with helm updates at all. We do it once a week. We go through all the projects and update dozens of helm charts every single week. And we are completely confident that it will not break stuff because if it will break stuff, we will know it before it breaks stuff because we just see it. Yeah. There's a cool it's a slight segue, but just because we're talking about helm and changes, it's like one of the challenges is that when you pick up a new version of a helm chart, you really don't know what's changed, and you don't know what's changed

20:09 to the templating. You don't know what's changed in the schema for the values fail. Although they are Yep. Trying to make improvements there. And something I think is really cool that we should take away from the JavaScript ecosystem. And maybe something that Kluctl does, and I'm just I don't know. Maybe I'm heading on it. But is the ability to do snapshot style testing where you actually take the render to YAML and then validate that on every subsequent deploy? Because quite often when we do upgrades, we don't really expect the template to YAML to change much. And if we do,

20:38 we need to know. So yeah. Maybe it may hopefully, that's something that Kluctl's going to do. Yeah. It does it does on multiple levels. So one level is the Helm integration assumes that you pre pull Helm charts and actually put them into your version control. This has different reasons, which I will explain later in the hands on. But one side effect of that is if you do that, you see in the GitDiffs or in the merge request that you later do to actually merge in the upgrade what has changed. If you want to, you can then

21:09 go deep into the Helm changes and verify that nothing strange is happening. Or then the next level applies. If you do the deployment, Closedale will always do a dry run before it actually does the deployment. So it will tell you line by line what has changed. So if, for example, you have a Helm chart that changes hundreds of lines of templates, but it's just refactoring because it changed some naming or something like that, looking into Git would be not so fun because you would see a lot of changes that actually have no effect. But when you later do the occlusal d

21:45 l diff or deploy, you will see that nothing has changed and you can be confident that deploying that to whatever environment you want wouldn't do any harm. So Right. I said multiple levels. Yeah. So where I'm right now okay. Introducing. So after multiple incarnations of such scripts, so it always started like a deploy. Sh and first parameter was the environment name, and then internally, it knew what to do, which hand charts to deploy and which environment needs to do stuff differently, when to wait on stuff, order, and so on. After some time, I figured out

22:25 that the requirements are always the same, the requirements that I just described, and that at that point, maybe it's time to have a unified solution, something that does all this in the way I would expect it. I hope that it resonates with other people's requirements and feelings, but, yeah, that's what we will discover after some time. First version was written in Python. Yeah. Actually, the first version was Bash, but then I turned to Python. It was very specific to the projects that I started to work on, that I worked in the beginning, mostly for my

23:03 customer and sponsor this project. A big thanks to Helman, by the way, if these people are listening. And after some time, it got more generic and was able to handle all kinds of deployments. It was not specific anymore to what they did internally. In the end, I decided to rewrite in one so one last time in Go to actually have something that integrates very well into the Kubernetes ecosystem, which is not so true with Python. I mean, it's okay. You still have a lot of libraries to work with the Kubernetes ecosystem, but it's still better in Go.

23:42 Current status says version 2.15. Next release is going to happen the next days. I personally and my customers so far consider it stable enough to be used in production. So that's about Are you going to do one more last time rewrite and Rust? Funny that that you say that. People have actually tried to motivate me to do that. I never looked into Rust. Not at all. I'm pretty sure that it's nice because that's what people tell me, but let's put it this way. Rewriting it from Python to Go was already a challenge, and I'm happy with it right now. Awesome.

24:27 Sorry. I I won't distract you anymore. Carry on, please. No. No. Do that. That's perfectly fine. So ClueScale tries to fulfill all the mentioned requirements. It does that by have a natural and dynamic project structure. What it means will be I'll show it later when doing the hands on. It's mostly decorative but kind of imperative when needed. That means we can still define the order. We can deploy a namespace before actually deploying objects into it. We can deploy CRDs before actually deploying the CRs. So many issues that I see with customized or Helm or GitOps

25:08 can be solved in that way by not being 100% declarative. It has native environments, so a first class concept of environments. I call them targets because after some time, I realized that you don't only deploy environments. Sometimes you deploy stuff to a cluster, which is, for example, base infrastructure stuff, and I wouldn't call that an environment. It's the dev cluster, but not the dev environment, so I decided to call that concept targets. Templating is possible everywhere, absolutely everywhere. There are one or two exceptions, but it's really minimal. This also includes helm values dot YAML, so

25:51 you don't have to write five different helm values files for five different environments. You can write one and use templating to actually do the one small change that is required to make it work on prod and test at the same time. It offers a unified CLI. That means whatever deployment you have at hand, you always use it the same way. You do a deploy for the target, so you call Kluctl, a Kluctl control, deploy -t and the target name. You do the same with diff, with delete, with prune and so on. So that means if you know how to

26:30 use Kluctl, you know how to deploy anything with that. I reuse Helm and customize as much as possible, and they are actually customized as the low level building block. The most low level part is customized and the resources that customize customize is customizing. So let's stop with the presentation and actually do the hands on. Let's do it. Great. Any comments, questions before I start? Nope. We just wanna see an action. Sorry. Lost my voice there. Yeah. We just wanna see an action then. Great. I have that. Do you see that as well? I'm Presentation mode just so that we can

27:15 Oh oh, yeah. They need to move that thing away here. So presentation mode. Awesome. Thank you. And I need to console. Great. So first thing we, of course, need, as always, with everything related to Kubernetes is Kubernetes cluster. I decided to just use kind. Let's start with a single kind cluster. Theoretically, I could create multiple kind clusters and then show everything based on these two clusters. I'll just use one for simplicity and instead, let's say, deploy multiple environments just by changing namespaces. I could also do it with multiple clusters. Maybe we have time later and we can actually show that.

28:20 So which targets can be deployed to. As an example, let's have one that we call dev. I'll explain that in a second, and one that is called prod. If you have any wishes, just tell me. Any additional targets or something like that? So I think name is obvious. It's the name of the target. When I later call Kluctl Kluctl control I think I'll just say Kluctl from now on because Yeah. Go first. It it seems to be in my mind already. So whenever I call it, I'll give it the name of the targets that I'm referring to,

29:06 which will be this one. I'm But the context is just the kubectl contact. Right? Exactly. The idea is that the target itself is bound to the context that you want to deploy it to. So you don't have to mess around with your local context. You don't have to set it before. You don't have to ensure that you're in the correct context. The target is bound to that one. You can override it, but you normally wouldn't do that. You can also work without the context here, and then it will behave the same as kubectl is, for example, working, just uses the

29:39 current active context. I prefer to always explicitly set the context because then it just it's just impossible to deploy dev to prods by accident. In this example, I'm using the same context twice. We are deploying to the same cluster, which is also fine because, I mean, there might be a test cluster running two different environments for testing purposes, or every developer has its own environment and so on. And in this case, just to showing it's just using the same cluster. So that's the targets. I'm assuming you can enrich that with a namespace somehow for prod?

30:21 Yeah. That's what I'm going to do in the resources later through templating. Okay. What I can do is let's do it now. I can pass arguments to targets. For example, let's call it arc one and give it this one. You could do whatever you want here. Actually, this is plain YAML, so I could also do if it makes sense, I mean, whatever. At this point, you can do pass whatever you want. I think those Rx can be consumed in the template and language. Sorry? I'm assuming those Rx can be used within the templating. Exactly. Okay. These Rx that you see that

31:07 you see see here are kind of the entry point into the templating language. It is not supposed to, like, give this 10 pages of YAML here to configure your target. Instead, you give it the actually, let's let's do it different. Let's give an argument called nth type and call it non prod. I think that makes sense. And one so we have the argument end type, and we have two flavors of it, non prod and prod. We can give it whatever we want. It will make sense later. So the next thing that we need is a deployment.

31:48 YAML. This can get confusing. This is not a Kubernetes deployment. So it's not the kind deployment. It's a Kluctl deployment. And what it does is it defines other deployments. Let's start with a simple one, namespaces. So this is a list of deployment items. An item can be or actually is always a customized deployment. So we said we want to have namespaces. This is, as said, customized. Did I type it correctly? I believe so. Yeah. This is just customized. You can do always everything that you can usually do in customize. You can specify resources. You can use generators. You

32:46 can use patches, whatever you need. Experience shows that usually just resources is used. Sometimes patches are used. All the advanced features of customized, for example, overlays and bases and so on, you can use it, but at the point where you start to use Kluctl, you don't need it anymore. So you don't use it that often. So let's have a namespace YAML. So why would you use a customization YAML rather than just as a straight up Kubernetes YAML? Like, if you're not using bases, you're not using patches, would you not just have, like, namespace dot YAML?

33:29 It's probably just because of historical reasons. Because in the beginning, this was just a wrap up for for customize Okay. And then got more and more and more. I could implement that as an additional feature to just not require the customization YAML. Flux does something like that. If you specify the customization that does doesn't have a customization YAML, it just treats all YAMLs as customization resources by default. I could do that as well. Yeah. I mean, one of my requirements was no boilerplate. So, actually, I could apply that same requirement here as well. Just I'll open it, actually. Don't worry.

34:07 Perfect. That's what I want to see. So we have namespace YAML. Always struggle to remember simple stuff. I think it's just Yep. Kind namespace metadata names. Okay. Now it gets interesting. So I could, of course, just have a hard coded name here, but that's not fun. What we actually want to do is, let's say, demo dash and now dot oh, no. Actually, dot name. So let me describe templating a little bit. What you see here is Ginger templating. You can use it everywhere. There are one or two exceptions. I'm not going to explain them. But, usually,

35:00 whenever you see YAML, you can use gender templating. The templating context starts with this as the entry point. So you always have the target object. The target has the name context. This one is a little special. You can just use args dot env type. You don't have to type target dot args dot env type. So as said, we have the target name, which is set just by default, and we can use it, for example, to have a dynamic namespace name. So everything whatever target we deploy, the name to this will be named differently now. And I think at this point, we are

35:41 done with the most basic deployment. There's one thing that I need to add. It's a requirement. Let's go close it here. IO slash, I'll explain it in a second. Just the requirements, the the root deployment YAML. So we'll later be more deployment YAML involved. The root deployment YAML must list a set of common labels, which are applied to all Kubernetes resources. This is later required to do deletion and pruning of objects because Kluctl must be able to identify what belongs to the deployment so that it can actually clean up and delete stuff. So this is equivalent

36:29 or your alternative to having a state file is to add labels to the resources. Exactly. There is no state involved at all. So I in the beginning, I was like, how do I solve this? And I was thinking, like, maybe I just write a conflict map to to the cluster or something like that, but then I decided just use labels and force the user. And if I wouldn't have specified that this, Kluctl would actually complain that it's missing. So Could you not just do it by default? I was considering that, but the problem is sometimes

37:01 there it's possible to use in a to use deployments without targets, and then this would break if I add some kind of default logic for that. I'm still considering how to solve it. Maybe I or someone comes up with with a solution to that. But right now, it's a requirement. Okay. And I do complain complain to you about that. So we now have a basic deployment. So let's do some Kluctl stuff. First thing yeah. Let's just do a deployment. Let's deploy that first. So as I explained I didn't really explain, but just I I mentioned it. If you do a deployment, what

37:43 it will do is it will first do a dry run and then print a diff. Then it asks you if that's fine for you. You say yes or no. If you say yes, it will actually apply it. If you say no, just nothing else. In this case, it just tells you there's a new object, and that's it. It's what we would have expected. And that's it. We have a namespace deployed right now. Let me figure out how to actually prove that something has happened. I hope everyone knows k nine s. Yeah. Can you It's not increase the font size

38:21 quite a bit. It's very small. You should tell me how to do that. Command plus. Command plus. Yep. That looks good. Two more. Is that okay? One more? There we go. That'll do. Thank you. Okay. Great. So what you should see now is the namespace. Demo dev. Great. So we see the templating value has been replaced. Great. I think it's clear oops. This is not what I wanted to do. I think it's clear that I can now also do This is the wrong Yes. Intelligence. This is Kluctl itself. I have too much stuff. I think it's pretty clear. I can also

39:05 do a deployment to prod now, which is the same cluster but a different namespace, and it's the same thing. And we should now be able to see yep. There it is. And new namespace. Can I suggest some changes just because I am curious now? Can I suggest the next step? Sure. I think the next step is to first close first. Close that one. Yeah. Where's close? Just Just The red button. Other. So I go this one and then file close other projects. That's what I want. Okay. And then namespace dot YAML. Here as well? Or

39:46 Yeah. There. Oh, yeah. Can we add a label? Sure. I wanna see how rich the deaf information gets. So just call this name Rawkode. No. You can't call it name. Just something Rawkode, a b c colon Rawkode or something like that. And then do the deploy to dev again. I'm curious. We've seen new objects on the deploy, but it does the dev give us more rich information as well? Yes. It will give you a diff, and it will not give you a unified diff. Very at least for me, it's very important. Unified diff is a nice thing if you

40:26 want to diff text. If you are diffing structured stuff, for example, YAML or JSON, you really don't want to see unified diff. What you want to see is what has actually structurally or logically changed. So you want to see the path and then the change inside that. In this case, it's easy. We edit. It's this it's a JSON path. We edit the string. Okay. Can you apply that? And then we'll make one more change just because I I always need to kinda see what happens. But let's change Rawkode to have two hours, like, a simple table, you know, and

41:02 then run that again. Awesome. I like this. And it will show you this table for every object where it detects changes. So in the end, let's even if you have hundreds of objects, you are able to scroll through it and at least do some kind of pattern matching. Or if it's just a few objects, really go into detail and figure out what has changed. Yeah. This is something that I would find important in the pull request process. Like, I I I just wanna see this step as a comment on my GitHub or something and just say, hey. This is what's about to

41:36 go to your environment. So yeah. Thanks. This is something I'm working on right now, actually, to have some so maybe another topic. I'm there's also a GitOps based controller, the Flux Clue Cuddle controller, which is doing GitOps style deployments for all the stuff. And I'm also working on another controller, which is not done yet. So it's it's not completely public yet, which will allow to kind of connect your deployments to pull requests to whatever you like. And it will do that. It will show you this. It will tell you if stuff is actually running and ready and so on.

42:19 It will approve for you or unapproved and so on. K. We have a a question in the comments as well from Google who wants to know whether we can now revert this with Kluctl. So can we uninstall production? Uninstall production. Yeah. Sure. We can delete it. It will it's the same here. It will first tell me what it's going to do. It will delete this namespace. And now we see wait. Did I do prod? You said dev. Yeah. You see? Luckily, we have a diff, and luckily, we actually looked at it. So you want to delete prod.

42:56 And then it tells you to delete demo prod. And that's it. Thank you. There you go, Hugo. You can easily revert with Kluctl. I guess I I don't depending on what Hugo was specifically asking, I guess, the the change be could I revert the previous change? Yeah. I mean, that would be a asking about that. That would be a git operation. Alright? That would be a a git reset and then Yeah. If if you do if you do GitOps and or any other type of continuous deployment, then, yes, you would do it through Git. Just revert the change and

43:31 let whatever needs to happen happen. If you are just working from your local machine, then you would just do the change and deploy it and see in the diff if it's what you actually want to do. Yeah. I guess because this is a entirely stateless application, there there's no rollbacks like we would see with Helm. Right? So you use the ability to do that. Exactly. Even the Helm integrations that I implemented, which I'm going to show later, does not use full Helm style installations, so you cannot roll them back because I'm fully deep fully relying on on Git at that point.

44:16 So if you want to revert something, revert it in Git and do a fresh deployment. Alright. That helps, Jacob. Thank you. Cool. Maybe yeah. I'll I'll show that later. So we have that one now. Let's this is an an interesting point now. We always had this problem, and me as well, so you did something. You deployed a lot of stuff to devs, then you did something on prod, and you switched around. And then you're at the point like, oh, did I actually deploy that already to this environment? And I'm at that point right now. I don't even I I completely forgot

44:56 what the state of dev is. And I can just do a deploy, and now I see, oh, it's actually fine. I already deployed everything, which is a good feeling to to trust the tooling and the deployment itself. I hope I made my point little Okay. What to show next? Now we're at the point where we actually want to deploy something. I'm completely open to what to deploy. Usually, I just deploy pod info or something like that. If you have any idea for something that is not too complex, that doesn't need too much configuration, that would usually work with a simple helm

45:34 install, just tell me, and we use it as an example. So you're looking for a helm resource? Yeah. We can we can start with a Helm or some plain resources. Okay. Let's just do a standard deployment that deploys PodM for NGINX. Either or is fine. Okay. It's through Helm or it's through plain YAML? Plain YAML. I mean Okay. Is there anything else you want to show in plain YAML that's different from the namespace example? Yeah. Maybe, yeah, maybe it's easier to just show it based on that and later go into to Helm. So let's do

46:12 pod info. Create a folder. We go to the root deployment again, and we just add in as deployment here, so now what I explained in regard to declarative and ordering and stuff like that. So by default, what Clue CDL does is everything that is listed here is deployed in parallel, so it doesn't care about ordering. But if you realize ordering is important, and in this case, it definitely is important because you cannot deploy port info into the namespace because namespace is available, what you can do is you can add a barrier in between, which means do everything that is before this

46:56 barrier in parallel, then wait till it's finished. Finished means it's applied. It doesn't mean it's ready. It just means it's applied for a namespace that's enough. And then continue with all the stuff following in parallel again. So it's super fast, but takes into account ordering whenever needed. That's what I tried to explain with the declarative versus imperative stuff. It is the same with CRDs. So if, for example, you're deploying the sealed secrets controller, you know it's going to deploy CRDs, and you cannot deploy sealed secrets before you have deployed the sealed secrets controller. So it

47:34 you would add the sealed secrets controller here at a barrier, and then you would deploy the sealed secrets. Okay. So put info. So we have a I called k eight s deployment right now because it might otherwise get confusing with c deployment demos. I cannot remember what deployment looks like. I always had to copy paste. App slash v one. No. I I really don't want to type out the full d engine next deployment now or put in for deployments. I've got it all done by heart. Like, that's how that's the only flex I've got. Sorry. I didn't get it done. It's alright.

48:17 I've just been silly. Okay. Please feel free to copy and paste the deployment. Yeah. Should have prepared one. There is one. The yes. In the comments, I was looking forward to seeing the helm. So we'll get to that in just a minute. Yeah. I'll I'll try to speed up with this one. So I found an engine x deployment that's so do you know if pod in pod in was available as a hand chart. Right? So maybe we do it the other way around. We start with NGINX. So just using this deployment. I'm not going to add a service now. I'm not going

48:58 to add ingresses and stuff like that. We we're just going to ignore that. But we need to do a few things. We, of course, have to deploy to to the correct namespace because otherwise, it would be default. How did we call it? Demo dash targets Target dot name. Yep. Yeah. Let's start with one replica. Everything else should be fine. I'm not going to do any configuration or stuff like that. I don't even know what it will show if nothing is deployed, maybe some hello or something like that, but that's fine. So we need a customization again. Doing some

49:35 copy paste now. And I think we are done. This should be the basic yeah. NGINX deployment. Let's deploy it, and it's done. And in k nine s, we should see it's starting up now. Pulling image, and it's running. So I said I'm not going to deploy services ingresses, nothing like that. I'm just using the port forwarding feature of k nine s. I said, doesn't know k nine s? Really, you have to get to know it because it's just great. So we have local host. Come on. Host. Eighty eighty. And we have NGINX running. That's great.

50:35 Okay. I think that one was quite easy. Maybe before I start with the Helm part, I do some some more in regard to configuration and templating. The deployment YAML also defines which variables are available inside the templating context. It's done by the vars key, and it's a list of vars sources. One of them is the file, and it's arbitrary what I put in here. So it it the only requirement is that it's part of the project that I'm in right now. So let's say inside vast, we have a common dot YAML. So we actually need that folder.

51:23 Oops. Vars. Common dot YAML. Any ideas for for Vars? Let's say replicas. Yeah. Let's let's do that later. So let's make the end of next version configurable. Very important. This is plain YAML. So I could actually do something like that because maybe it's easier to maintain later. I can do whatever I want here. Lists, dictionaries, everything. And I think that's obvious as well now. So that's it. So to explain it again, inside the root deployment YAML, we include the vast file common YAML. It defines NGINX version, and then we can use it everywhere that is included from here. Do you really

52:22 consume it as NGINX.version instead of vars.NGINX.version? Yeah. It's really NGINX.version. So what if I my common dot YAML have target colon name? I think you can actually do that, and it will override your target name. If you do that, bad idea. I'm not sure if I wouldn't if I if I would try to to stop you from doing that. Ideas is my middle name, I'm afraid. I always try to think of how I could break something. So Yeah. I mean, it's your it's your right to do that. I mean, I I think I know what what what you're up to.

53:01 Yeah. I I expected there to be a prefix, like target Yeah. And args and then and then bars. But Yeah. Makes sense, actually. Maybe that's also something I should consider. Yeah. I'll I'll think about that. And you can, of course, do a Got an issue. Great. There there's one thing where it is already implemented this way. So everything that you pass through arcs inside the target definition is available through arcs dot. So for example, I could use n type here. Doesn't make sense, of course, but just to show it. I'll show why the axe are so so

53:35 nice later a little bit. So we have the engine x version here. Let's do a deploy. Nothing should change because we haven't actually changed anything. We just did some refactoring right now. That's also what I explained before. I always want to know if my change has the expected consequences. In this case, it shouldn't have any consequences, and this verifies that it's the case. Let's say if I change this to dot one, I should see it in the diff. So there we see it again. As said, it shows here the JSON path to the point where it's changed, and then it shows

54:14 this unified diff, which is a very short one. Can you open the case deployment dot YAML, please? Yes. Can you remove the namespace from the top? Mhmm. And then run deploy again? It's actually a good idea. Let's do a little bit different thing. I'm going to deploy that to prod now. Okay? It doesn't make sense, but who cares? So I think this is what what you're retargeting, that it's going to the default namespace right now. Let's assume we did that by mistake. We completely forgot that we had to actually set the namespace, and we deployed it to prod.

54:59 Now we realize, oh, what have we done? We deployed something to the wrong namespace, and we have to fix it. Now, the naive solution is to just add the namespace and assume that this has fixed it. But if you deploy that, it doesn't just change the namespace. It actually means I'm deploying a second version of that same deployment to another namespace because the old one is still there. I think that's what you were Yeah. I wanted to see how it how it identifies the replace. Yeah. So what it will show you now wait. This is something it's in my head

55:36 which needs to be changed. So let's do diff. A diff will basically just show show you that and show you often object as well. So it tells you what you actually do right now is you create a new deployment, and then there is an often object which I don't recognize anymore, but it looks like it was part of my deployment in the past. What you can do now is you can deploy it first. In this case, you just see new deployments. It doesn't show you that they are also orphan object. After deployment, it would show you the orphan

56:11 objects. So this is something I need to change to actually show that before as well. So what we have now is we have that same deployment two times, once in the correct namespace, once in the wrong namespace. If your tooling doesn't support you properly, you might end up with garbage all over your cluster because of such things happening, and you wouldn't realize it. With GitOps, you can do prune. You can enable pruning for your deployments and it will handle it. But if you're not using it, you end up with completely Okay. Before you prune that, can you go

56:50 back to k nines? Something's odd. Right? Is that replica set ID is the same on both. How did that happen? Replica is what? One? No. The replica set. The can you run look at replica sets and k nines across all namespaces. Seven five six five eight d four seven seven seven and two namespaces. That's pretty Oh, this is really strange. No. I know what you mean. This is strange. It is strange. Must be something that must be something to do with the deterministic nature of the replicas that Yeah. Are created across that's I've I've never seen that before. I'm

57:38 gonna have to dig in. Yeah. I actually never looked into at that point, but you're right. It's interesting. So there must be some deterministic way to to figure out the names that it uses internally. Yeah. Based on maybe the revision ID, the generation, and the the hash of the object. Yes. Which means you could probably do some this is not And I sort of clustered, but I'm never working out ways that I can do collisions across clusters. But that that's the Yeah. But but I assume it's still fine at least in inside the same cluster because it's still

58:09 namespace. It's still in different namespace. But, yeah, let's get back to okay. So here we have c parts. So you, of course, don't want to have that garbage on your cluster, and you want to clean up immediately when you realize that situation. What you can do this Kluctl is just to prune, and it will delete the objects that it determined as often. Okay. So We have a in the chat from Matthias. Mhmm. And it's something I was thinking too, but they were I'm assuming they maybe are familiar with the tool, but they're asking if there's

58:45 an override namespace in the deployment dot YAML, which is, I think, a good question because I would probably forget to specify the namespace and a resource at some point. So can that I Yeah. I I think that's Matthias. I I think I know him. And, yeah, he's quite familiar with it. I think what he wants to ask is so as we're using customize, we could, of course, also say that we tell it to use this namespace at this point. Mhmm. So this is one option to avoid such situations, just using customize to set the namespace.

59:23 I think it's clear what what I'm going to do here. Right? Demo and so on. I'm not going to do that now for for the demo purposes. Another option is inside the deployment YAML to also say override namespace and basically do the same. So demo target dot name. It would have the same it and not not not exactly. So what override namespace does is every customize that it encounters that doesn't have a namespace set will get that namespace. So if a customization still says I want to deploy it to Bloop, it will still be deployed to Bloop because

1:00:05 Deploying to Multiple Targets (Dev vs Prod)

1:00:06 override is only happening if it's not set. But I'm not I I'll not go into more detail in in in that regard if that's fine for you. Okay. Okay. Where did I stop? So I think we were yeah. We we were here with. So I included a common YAML. That's not very interesting. It's nice, but it's not the most important thing. You remember that I said that the arcs from the target are more like an entry point to the configuration. Because if you would write down all the configuration that is required for one environment, it's

1:00:55 Deploying an Application (NGINX example)

1:00:57 easy to end up with pages of just YAML inside this YAML, which would make it hard to maintain. So instead, I tend to use it just as an entry point. For example, env type, there's prod and non prod. And what I can do inside the deployment YAML then is, as I said, templating is possible nearly everywhere. I can use that to define which file to include. So what we can do now is have a prod dot YAML and have a non prod dot YAML. What you can do now is again, this is arbitrary YAML, and what you can do now is

1:01:41 have the same stuff here. And, for example, say, replicas for non prod, let's have one. For prod, let's have three. Is it clear what this does? It is. Yeah. Great. One thing that I should also mention is this is layered on top. This means first, this one is loaded, then the template context is enhanced, then this one is loaded, having this included as well already. So I could theoretically use engine x dot version here already. It doesn't make sense right now, but I could do it. So I can layer one on another and kind of

1:02:36 do all kind of fancy stuff with that. Then another thing is if one vast file has the same defined as the one above, for example, we have replicas here, it will overwrite this one value. So it does a, yeah, a merge of of the YAML files. So what you can also do is, let's say, we don't define anything for non prod. So the default is to have replicas one. But for prod, we have some special configuration which say which says overwrite this value with three. Is that clear so far? It is. Great. And I think it's obvious. We just use

1:03:26 that value here. And let's do a dev deployment first because nothing happens, which is expected because we didn't change the replicas. Right? Mhmm. But I completely forgot that it's actually expected to nothing, to to change nothing, but luckily, my tooling is helping. For prod, it should look different, and something is wrong. Because you did a print. Oh, yeah. That's what happens if you you see it's really too much. So and it tells us that there is actually a change for prod. And we say yes, and we see more replicas, which we expected. Great. I assume that this feature we see is

1:04:20 I think it's clear. Right? It is. Very important. This is a list of vast sources. File is just one type of vast source. There are other types. For example, HTTP. You can do an HTTP request and load some YAML from from the web. You can load something from some GitLab repo. Does that work for deployments too instead of path? Yes. Awesome. Okay. Say git include, but I'm not going to show that now because that's what require gits to be set up with and stuff like that. So you then also give it the easy path and so on.

1:04:23 Loading Vars from Various Sources (HTTP, Git, Cluster ConfigMaps/Secrets)

1:05:03 What else? Vault. Vault is experimental. We have HWS secrets manager. And what else? Cluster config maps. This is also very interesting. I think it's namespace, name and key. I don't remember exactly which ones need to be specified, but what you can also do is while you're deploying, it's loading something from the cluster using that as variable source, and then you can use it in the templating. Yeah. That's just bit more interesting for me in a personal level. I I do a lot of conference talks. And one of the ones I've been given a lot over the last two

1:05:38 Discussing Cluster ConfigMaps for Environment Config

1:05:48 years is to talk about get ups and how Mhmm. Actually, overlays are an anti pattern because we encode environmental information into our application deployment description when really our application shouldn't actually know the environment exists. The environment should provide everything that needs. And with this cluster config map option, we actually provide a way to say, here's enough information to deploy and get everything else from the cluster itself. Like, that to me is a killer feature. Yep. It is. We use it as an example to provide so so what we do is we have a kind of cluster based deployment,

1:06:25 which is a Kluctl deployment, which contains ingress controllers, gatekeeper, Selium is deployed in. Like, everything you need to have a usable cluster. So you start with a naked cluster and you provide it with everything that you need. What we also deploy as part of that is oh, no. Actually, one step before when we create the naked cluster through cluster RP, we also deploy a config map containing information about the low level infrastructure, for example, networking, which subnets are used for the cluster and stuff like that. So it's just a config map. Every cluster has that.

1:07:02 In the end, the base deployment can then use cluster config map to load that config map, then get information about the subnets, which is usually a mess to get from Terraform into your deployments and stuff like that. So in this way, it's it's quite easy. And then we can use that information to configure Cilium properly to use the correct subnets and so on. I I think you understand this. You can do a lot of stuff with that. There's also the the cluster secret, which is basically the same. Just just the secrets. Okay. We've got just over twenty minutes left, so

1:07:40 Integrating Helm Charts

1:07:43 I think we should get onto the helm stuff and show that. Oh, yeah. Okay. Then so I think we described everything related to that. Okay. So let's do something different. This is very important. I'm not going to directly include the Helm file. I'm going to add a sub deployment, which just contains a deployment dot YAML, which is the same as this one from the ID. And what you do here now is instead of pass, we say include third party, and this one starts with deployments again. And here, we have, again, a customized deployment, and we call it pod info. I know

1:08:30 it's Helm, internally, customize is used to actually deploy Helm. It will get clearer in a few minutes. So we have the pod info. And now we have the customization YAML resources. Ignore that for now. I'm going to explain it in a minute. So now the HAM integration. Now it gets interesting. So for the HAM integration, we first specify which HAM chart we actually want to pull in. I keep forgetting the format of that. Let me do a copy paste. So there's documentation at Kluctl.io. I hope I have documented everything that is needed. If something is missing, just tell me, and

1:09:31 I'll provide it. And I'm copying from there right now. So this is the basic structure of the Helm chart. As you maybe already see, it's just a representation of what you would usually give Helm while you install something. You give it to repo, chart name, chart version, and so on. Dot. So let me look for pod info. There is the pod info chart. I know you cannot see what I'm doing right now. I'm on another screen. Just doing some copy paste. So we specify the repository. We specify the chart name, pod info, and we specify

1:10:13 the version, six dot 2 dot one. Just for demo purposes, let's not use the latest one so that we can later show how an update is actually working. We don't want to skip updates. We are happy with updates here. Release name, it's the same as if you would do a helm install. Let's call it pod info namespace. Let's not forget it this time. What was it? Target dot name demo dash target dot name. Just one output. So what it internally does is it renders the Helm chart through the Helm template functionality. And then it uses the resulting YAML

1:11:03 to write it into some internally temporary file called deploy YAML, and then use customize to actually load the temporary file. At that point, we can use customize, for example, to even patch the HAM chart, which is needed more often than I like, for example, to add port security context and stuff like that, which the HAM chart doesn't support natively. So I think that's it for now. I think I mentioned in the beginning that for the Helm integration, I do pre pulling. That means before I can actually use that, I have to pre pull that Helm chart

1:11:35 Helm Chart Pre-pulling

1:11:45 and put it into my version control. I can do that by using Kluctl helm pull. It will go through the project and find all helm chart YAMLs and pulling it and just putting it near that hand chart YAML. This is really just a copy of the chart itself. It means I can also look into the values YAML, for example, to figure out which values are supported. So I don't even have to go to the to the website and read documentation. The next step is we need helm values. Not always, but sometimes or actually in most cases,

1:12:17 Helm Values File

1:12:26 which is the helm values. And what you can do now, let let's figure out what you can modify. We can modify your replica count. That's interesting. So let's say replica count. As we are running out of time, I'm just going to reuse the NGINX replicas now. It's not correct. Of course, you wouldn't do that in a real project, but for the demo, it's good enough. I think we are done. We right now have a hand chart integrated, and we should be able to deploy it right now. Unknown shorthand. What? You forgot dash t. Yeah. And what you see is yeah.

1:13:09 Deploying Helm Chart (Pod Info)

1:13:09 Yeah. This is the change that I didn't deploy. And you see a list of new objects, deployment pod info and service pod info. Going to deploy that now. And k nine s. Yep. Looks good. Thread. We assume that's normal in the beginning. Yeah. Logs look good. Let's do some port forwarding. 9898. 9 8 9 8. And there we have bot info. You can do stuff here. Nice. So that's the basic HAM integration. Any questions at that point? Any comments? No. That makes that makes sense. Like, our intermediate deploy dot YAML, I guess that's cleaned up by Kluctl.

1:14:04 Cleaned up? Well, I don't see it. Yeah. It's it's not not happening in this folder because I'm Okay. Too scared to destroy something important. What I'm doing is I'm creating a temporary folder, and then I'm rendering the complete project into that temporary folder. And as part of that rendering process, I also create the templates from the hand charts and put the temporary files into that temporary folder so I do not mess with the actual project, which would be scary. Cool. So I think that's clear. And now I did a small mention in in the in the

1:14:49 Templating Helm Values Example (Change Color)

1:14:50 the slides that even the helm values are templatable now. That means I can do stuff like, let's say, in the VARs for prods. Let's say in in non prod, we have prod info, change color, true. Oh, no. Let's say false. And for prod, we say change color, shoe. As said, arbitrary YAML, I could do whatever I want here. In this case, I'm having a Boolean. And what I can do now is in the helm values, ginger templating, if how do you call it? Pod info dot change color. I can do some conditional stuff here. Yeah. Don't don't be confused about the errors

1:15:42 that it's showing because Ginger and YAML and IDEs, lots of good friends. So inside the pod info, where you see them, I've seen that you can specify color. That's all. Let's do think it should support something like this. This is well. And done. So the interesting thing is we know that we have changed some helm values, but in the end, we have no idea what that actually means. Because depending on how the templates are implemented, this could mean everything. And we don't know before it's deployed usually. But with ClusterityO, what we see now is we see a full diff which says nothing

1:16:22 Diff shows changes from Templated Helm Values

1:16:35 has changed because for dev, change color is false. This is a bad example now, as I realized, because we wouldn't see a diff on prods. Sorry? Just swap prod and non prod around to true and the false. Yeah. Yeah. That's Keep it simple. Exactly. So doing it again, we should see the detailed diff about what actually happened. For example, it didn't just change some value, it also added something to the deployment, which wasn't there before. And now I see that this actually had that consequence. And I can either say yes or no, and I'm fine with that change. I don't

1:17:15 know if this green stuff really works, but I assume yes. So after some time, looks like it's already restarted. The port forwarding has to be reset. And it's green. Great. But only on that. So can we do the Helm upgrade to six one one as well? Yeah. So, usually, you would have all this in Git because everyone uses Git. So let's create a Git project first. I wouldn't it's not really required. I could show everything just without Git, but I'd like to show the Git integration as well when it comes to Helm upgrades. I'm doing something that I really hate, and

1:17:39 Updating Helm Charts (`kluctl helm update`)

1:18:03 if I ever see anyone doing that, I'll scream at him. What is it? Oh my god. What is happening here? It's get add dot and then get commit dash m. Okay. Get add dot. Yep. And then you can do get commit with a message. Yeah. Well, what I'm trying to say is never add everything and commit it just without verifying what you actually committed, but that's a different story. So we have a simple git repository now with just one commit. And what we want to do now is we want to figure out for the dozens

1:18:51 of ham charts that we are using. We probably already forgot which ones we are using because it's just so many. We want to just upgrade everyone. Actually, let's just figure out which ones have upgrades. I forgot to tell. Update or upgrade. Help update. And it tells me, oh, there's a ham chart. It has a new version available, and I could upgrade. If I decide I actually want to upgrade, what I can do is tell it to upgrade. This will do the upgrade and write the changes to the local file files, but that's not enough. I actually want to

1:19:27 have it committed as well. So it updated it, pulled it, committed it. So if you look into the, oops, into the logs, we see a commit that has only the specific changes related to that update included. So even if I would have pending changes anywhere else, this commit would be a clean commit just containing the the update. And do you get one that per Helm chart, or is it all grouped together? It's one per Helm chart. The idea is that if you realize, okay, it's nice to upgrade pod info, but upgrading Selium is maybe bad idea right now. You can

1:20:08 revert that one commit, for example, or just rebase and remove that one commit or whatever you want. So you can use Git's features to to manage your your Helm upgrades. So inside the diff of that one k. What? You can then see, oh, okay. The app version has changed. Usually, you would use magic quest or something like that and have a nice view of what we see here right now. But as said, you can do a source level review and verify that what happens is really what you want to happen. And then the next step is, of course, because as said,

1:20:51 in the end, it might be that there are hundreds of lines changed, but it's not affecting your deployment at all or just changing the image version, for example. So the final step is to actually look at the diff because this is the truth. This is what's actually going to happen. What you see here is now the label's being changed. Makes sense. Version information. Version information. The image has changed and nothing else. That looks like a easy upgrade that we just accept, and we are done. So that's the Helm integration. I've been quite fast now. How does that work with Helm

1:21:35 Kluctl Hooks & Annotations (Helm Hooks, Force Apply, Delete)

1:21:35 hooks? Are those supported? Yeah. Sure. Is there an example of Helm Hooks? Yeah. I'm I'm not sure if I'm able to find that. I'm not sure if the Hooks work with Helm template. So I'm assuming maybe we lose access to them. No. No. It's so Helm template just just writes out the same YAMLs. It doesn't care about its if it's a hook or not. Kluctl knows about Helm hooks, and it knows how to handle them. It knows when to deploy them, when to delete them, it knows when to wait for them. It kind of replicates the behavior that Helm does.

1:22:12 At the same time, it allows you to have own hooks, so you don't have to write Helm chart just to have hooks. If you need to do something I'm not able to come up with something on the fly right now. No. That's okay. You would just add annotations. Kluctl.io. Hook. So it's so you have Kluctl specific hooks, which are mostly like what you know from Helm. They are just named a little bit different because in in Kluctl, we don't do installs. We do deploys. So it's all called a little bit differently. But if it encounters

1:23:06 a Helm hook, it would just work as if it has had been from a from a Helm Okay. Chart. Nice. So that's it. And there are other annotations that change how stuff is handled. Example, conflict resolution is very important. There are cases, for example, the Elastic operator, the Elastic Cloud operator, tends to take over ownership of fields that it shouldn't touch. For example, the node specs. And in the end, the managed fields tell you that you lost ownership of that. And you can tell Kluctl to kind of force apply whenever that happens and to take back ownership of something that

1:23:55 you know is yours and no one else should touch it. So you have stuff like Kluctlestar.io, force, apply, and set it to true. Must be string because it's an invitation. And so there are many other things that you can use to control the behavior of your deployments. You can even do stuff like Clue CDL .I o delete true. It's funny because you are deploying something, but you're actually deleting something. So what it will do is it will ignore everything. So it will ignore the complete spec. And whenever it encounters delete true, just delete that object.

1:24:32 This is sounds funny because it's maybe hard to understand why that is needed. One example is if you deploy to a fresh Kubernetes EKS cluster from AWS, you have a daemon set running there that provides the AWS any CNI. So the low level CNI that's HWS specific. If you want to use Selium, you don't want to have that daemon set running there. It must be deleted, actually. And to avoid having manual steps to deploy Selium, you can instead have a dummy daemon set that has Kluctl delete set to true, and then that object is going

1:25:15 to be deleted. You can also do that as part of the deployment YAML. So you can and then it's forgot how to so you specify how to identify it and name, so it's name, and so on. And so it knows that at that point, it should just delete that object. Nice. Okay. Alright. We have five minutes left. That's our Yeah. Issue you wanna cover, or should we jump back to back face mode and just chat for a few minute? It depends. If you have any ideas, any questions where you think it should be shown, just

1:25:40 Wrap-up and Discussion

1:25:55 say it. If not, we can just go to the face to face mode again. Yeah. Let's jump back. Because we have you've you you've covered a lot there. I can cover a lot more if you want. It's when deploying to Kubernetes is a complex topic. That's a fact. It is. What I what I loved is every time I saw, oh, how would I handle this use case or how would I handle this? It's like there was there was a way to modify and change that behavior. Even down to that last example there where we have

1:26:27 either the ability to apply dummy resource with the the delete annotation, but even in the deployment spec just to have to delete objects Yeah. As well. So, like, there's yeah. I'm pretty sure this could probably handle any complex deployment that I was gonna throw at it, which is quite exciting. So Yeah. We have very complex deployments, and we actually deploy everything with it right now. One question in between. Am I still sharing, or are we in face to face mode? Still face mode. K. Then let me open. Where is it? So that I can see you as well.

1:27:05 So no. Okay. I can see you as well. Great. So what was the question? Sorry. I there there wasn't a question. I was just really happy that, you know, I was in my head as we were walking through, you know, I wonder how I'd handle this situation. You know, the EKS one is a big one. Like, EKS ships with a bunch of default resources by default. You either need to modify or delete or replace and the hooks are there to do that. If you're working with Helm charts, you've got the ability to template the YAML. The values

1:27:34 failed, but not even just that. It supports all the hooks. And then, Kluctl has its own hooks. So if I need to do more things, then I have access to that. Like, it's a really powerful tool and something I think I'm definitely gonna have to experiment with. And, you know, I always say my production, but it's like my production, you know, it's my cluster that I do on my YouTube automation on, you know, my website automation So, yeah, this is a really, really cool tool. And I can see from all of those features that you've added to you must have

1:28:04 been working on this for quite a long time. Yes. As I said, it had multiple incarnations, so it was not immediately in that state. For me, it's very important to reduce the set of features to a minimum and not have specific features. Like, in the past, there was a lot of stuff to handle environments correctly, and then I realized I can't do all this with templating. So I removed a lot of features and just stick to the to the base features. I mean, it's still a lot, but yeah. Trying to I think I personally I don't

1:28:41 think I would use. I only have one target, and I would use that config map from cluster to do all the environment enrichment. That's that's the thing that I'm most excited to experiment with as I start to play with quick control. So You can you can mix that. For example, you could decide to use targets just for to targeting a cluster and then hand over to the config map to get in the actual configuration. So you have But if I use it as a get up style environment, I don't really need the target. Right? Yeah. And long term so and the I'm

1:29:15 working on that right now. The next release c two dot 16 will actually improve sets that you can do targetless deployments, which will then kind of behave like Kube Kuttle would do, deploy those current context. And Yeah. Yeah. To me, that that that's a really interesting paradigm because it removes more boilerplate. It moves more logic into the cluster, and it simplifies the deployment manifest from the developer point of view. It's like the environment will decide how many replicas or how the HP should function or what the angers domain names are. The developers really shouldn't have any control over that because

1:29:52 they're not the ones responsible for providing the environment in which the application run. And I think Kluctl I mean, I've tried to do this with Pulumi and CDK, but what I'm seeing from Kluctl gives me a simpler declaration and that I'm just working with YAML, customizing helm tools that are almost ubiquitous to this point, but I'm able to enrich them with the behavior that I need with the templating. And I think that's really interesting. So I'm definitely gonna be kicking the tires on it, so please expect a lot of issues on the GitHub with that. Please.

1:30:22 Please. I've fumbled my way through it, and maybe I'll just have to reach out, but I need some help. And maybe we need a second stream to cover all the other features that we haven't even covered today. So Yep. I can do that. The good thing is, I mean, it the project I'm working on it still since quite some time, but I'm I've not been publicly active in the beginning. So that's what I started the last few weeks or months. That means user base is still, let's say, growing. The advantage of that is that if you have feature requests or whatever,

1:30:56 it's right now, it's still easy to get me and to to get me actually helping you immediately. Well, yeah, there people can go to the GitHub page where you can file issues. You are also in the Rawkode Academy Discord. So if people want more real time communication, I'm sure you'd be okay. I hope I'm just gonna assume you don't mind people tagging me. And maybe we'll even create a channel for quick control there just so that people do wanna chat and I'm really seeing fashion. It is available. But I've been really impressed with what I've

1:31:25 seen. So I'll say thank you for for working on this. I think it's a really interesting project. I'd like I said, definitely gonna try and kick the tires on this for my production infrastructure, and maybe I'll even submit a pull request. We'll see. Happy to hear that, and thanks for having me. Alright. Well, it's been a pleasure, Alexander. Thank you again. Thank you to the people watching at home or watching after the fact via the power of YouTube. We'll keep you updated on my adoption of Kluctl, and we'll be back again in the future. Thanks a lot, and I'll see you

1:31:37 Conclusion

1:31:53 again soon. Bye bye.