 All right, I always get the question, is Helm popular? Hmm, this room seems to be so much full. So it must be somewhat popular. Hey everyone, welcome to the session today talking about Helm. Chart your course like a champion. My name is Andy Block, I'm at a single shark attack at Red Hat and a Helm maintainer. I wanna introduce the wonderful pal here that's gonna walk you through the entire charting your course like a champion. Let's start over here with Scott, Scott. That'll help. Hey Scott Rigby, I am one of the Helm maintainers. I also co-maintain Flux and some other things in CNCF. And yeah, I used to co-maintain the stable and incubator charts repose so I can help answer questions about that as well and it's just nice to be here. I'm Joe Julian, I also am a Helm maintainer. I work somewhere I can't talk about. Some kind of stealth thing. Stealth thing. I have written a lot of charts professionally so I know a little bit about it. Okay. And I'm Karina Angel. I also work at Red Hat and I'm also a tech lead in tag app delivery, technical advisory group. Does anybody know what the technical advisory groups are? Raise your hands. I don't see many hands. Okay. All right, sounds good. Okay. Go ahead and getting started. Really, we're looking at mastering the art of Helm charts because what is a Helm chart? It is like a recipe. Okay, let's look at the menu. We have our chart structure, our life cycle, our objects. Let's go on to the entrees which they actually are all gonna talk about in a little bit and then your desserts, your testing, your release management. And then as we look at, we don't even have notes up here. What happened to them? I'd like to say that I can do this without notes but it's been a very long week so bear with me while I actually look at the notes. Okay, that's okay. Who here is new to Helm? Actually, okay. Anybody on this side? You are? Okay, okay. If you go to Helm.sh, we have, Helm.sh, we have, it's really comprehensive. Our web docs, all the intro docs, please go there. We didn't focus this on an intro to Helm session because we do have a lot of people here that know Helm. So we're looking at, so I also wanna know who here is a maintainer of a project or contributes to a project? I only saw like three hands, seriously? We're at KubeCon. No, let's be serious. There's plenty of opportunity in the room. I know, right? Okay, okay. Wow, this is gonna be, we have to talk. So I know who wants to be a maintainer? Who wants to contribute? Okay, thank you. Please go to Helm booth. Please show up to the meetings because this project that many people rely on requires contributors, requires maintainers. Not everybody gets paid to do this, right? Anyway, this is a very popular project and for good reason, it's package management for Kubernetes, right? Okay, so who here does use Helm charts in their applications, see? A fair bit more than the number of maintainers and contributors. Right, and who writes Helm charts? Okay, okay. All right, so we have to talk to all of you. All right, so when you're, let's look at the primary components and we'll keep moving on. All right, you have your Helm chart, right? You have your values config. And then using the CLI, we can release your chart and let's look at the chart structure. It's like a tar ball, right? And these are the files that we're gonna look at, but really, I do want to pass this on because actually the meat of this is gonna be between these three. So the Helm chart, as you saw in that structure, has a number of components. The first topmost one would be the chart YAML. It's the tool to tell Helm what this thing is, how it's used, mostly to communicate that to users. So there's references to the chart homepage, there's documentation, there's support resources that should all be linked from your Helm chart so that your users can find out how to use this thing. There's annotations which are fairly free form. If you want people to find your chart, you can go to Artifact Hub, they've got a long list of annotations that you can add to your charts so that it'll actually populate their GUI and make it look all nice and pretty. And it makes it discoverable. Super useful. The big one also is if you have issues with the charts, as you're consuming it, because there's a lot of charts out there in the open source, being able to understand what resources provide assistance, whether it be a GitHub repository, whether it be an email that you can email or email support channel, or even a Slack channel. Being able to provide as much information as you can inside your chart.yaml makes your chart more consumable. The worst that I ever see is a chart yaml that has a name, a version, and a description. That's not gonna be very helpful. If you provide full metadata, you make your chart more discoverable, more usable, and more consumable, and easier for you all. Yeah, can I chime in on that real quick? And specifically, my favorite is the Git repo. So, the reason for that is there are people that want to probably contribute to your chart. There are possibly people that want to contribute to your chart, that's what I mean. I don't know what charts you maintain, or what charts see you, right? But it's very likely, you know, especially if someone finds it there. And what's going to happen if they don't know where the source repo is? There may be emails, you know, for the list of the chart, the maintainers of that chart. But honestly, a lot of people are shy, and also impatient. So even if there's a way to possibly contact you, it's very likely people aren't even going to bother because they say, well, we need to use this now. They're going to fork that, and they're going to make their own changes themselves, and any benefits that they add aren't going to get into your charts. So that's just a suggestion. Please do that. And yeah, if you don't want to know what we're talking about, it's not part of the main chart.yaml, but if you look on artifacthub.io, what Joe was talking about, there's a list of the annotations. So that one would be great. It's just key value, and just say source, or something like that. And people will love you for it. I even do that with the charts I just write for myself. I still post them up publicly. Every once in a while, somebody actually finds one and wants to use it, and actually sends me a pull request. It's really surprising. Oh, and the other thing you can do on them is you can clearly denote which charts are deprecated. So if you're done with this chart, you don't want to do it anymore. There's a weight of mark that deprecated so that people can still find it, so use it, but they'll know that it's the end of life, and they need to figure something else out. Can I see some of those self-documenting? Yeah, I can talk to this as well. Definitely utilize the tools for self-documentation. So if you're looking at really making life easier on yourselves as creators, I can't tell you how much pain I had trying to go and populate or read me to make my values consumable. How many experienced the challenge of creating good documentation for Helm charts? How many of you are doing it manually? There are tools that can help with that. So they're not necessarily a part of the Helm project, but other projects have seen some of the challenges, and you can leverage those and adding comments into your values.yml file will allow those other tools to be able to render, read me automatically. You can create basically a template for your read me, and it can get rendered. You can do it as part of a pre-commit hook. You can do it as part of CI. You can really start taking advantage of the tools available to make a chart, you know, US chart designers and producers much easier. One of them is Helm docs. There's a couple other ones out there, but Helm docs is the one that I personally use. Definitely look into that. Also, honestly, I'm lazy, so I had started for a long time not making a big table of the values in the read me, but if I had Helm docs earlier on, I totally would have done that. But it's also legit to say, hey folks, just do Helm show values or whatever, and just make sure you put comments in your values file. So the next one is gonna be on the library charts. How many of you either know what a library chart is or have used a library chart itself, you know, created one? Okay, as you start to develop more and more charts, similar charts, you're gonna start seeing patterns evolve. And instead of having to do the same pattern over and over and over, one that I use typically is I wanna be able to support either a, for the image reference, either a tag or a char digest. But I don't know which one I wanna use, potentially. Some might be available in shop formats, some might be available in digest formats. So I can go ahead and create a reusable partial function, put that into my library charts and then just bring that into all my other charts. It makes it really easy to create, you know, a set of very clean application charts without having to fill out your helper's demo file or any of your parcels with the same data over and over and over. And then finally, use, you know, intuitive names for your functions and your parcels. Make it so that it is like, you know, like images.name or names.namespace. Makes it really easy for you to plop it in over and over. It makes it easier for consumers to be able to do the same. Now let's switch over to Joe now. So obviously, as everybody knows, a Helm chart is made up of templates that are rendered and applied against a Kubernetes API. So you fill out your mad libs, you got all your spaces there for your values and you just never said it. And it'll create your resource and it will apply it to the API, creating all the deployments and services and all that stuff that you wanted to deploy. For those who don't know, Helm templates use the GoLine template engine with a bunch of functions. There's most of them are sprig. There's a few others that are just built into Helm. But they're a really powerful set of tools even though they're really simple and you can do some really powerful things with them if you use them correctly. And then the other question, which I hear a lot is why do I need to use Helm? Why wouldn't I just create manifests? And I tell people that if manifests are right for you to do it, sometimes you don't need to template things. You only need to deploy the same thing over and over again, it's no point. But if you want to ship your product to other people and you want other people to be able to configure it for their own needs, that's usually when Helm becomes really powerful. Oh yeah, and remember that value sample is not a template. Don't put your GoLine formatting into it because it's not gonna render. But really the powerful part of all this is those functions and name templates. So with name templates, you're able to write your own functions to do processes, maybe they may be complex processes, they may just be repetitive processes like he was talking about. So with complexities, like on this one, I got this complex project. This complex, I've seen actually, this is simple by comparison. I've seen some that have ands or ifs, ands or or ifs. And just like it goes on for like, literally to went for a half a screen that I had to tear apart. It's unreadable, you can't, you don't know why it's doing what it's doing, how it's doing it. It's just really hard to read. But if you take this all apart, and I didn't, I don't have an example, but if you take it all apart and put in a name template, you can actually just do like, if this thing, then do this. And you can like, do a bunch of nested ifs that are actually readable. And then when you go to call it, you just say, include this named function dot, and then it'll do all that complex logic and actually give you a result, whether it's, well, it gives a string result and I'll go over that in a minute. But yeah, it just accepts a dict also, so you don't have to pass it all your values. You can just say, oh, I want this function and it's gonna process these three things and you build your dict and pass it in. So it's really powerful if used correctly. Can I note one quick thing? I don't think, we don't have a slide to talk about this right now, but we can talk afterwards if anyone wants to. If you're not using a post renderer, this is a really good section to think about it in. Because if you've got, I don't know if any of you know about this, but Joe, you were saying, people ask you, why not just use manifest or why not use customize? They are great tools, do it, do it, absolutely. But one thing is you don't have to choose. Either or, you can have your Helm chart with these name templates you can have, basically you're repeating common logic that you two were talking about. But if you've got edge cases, like say you reuse this template across your org, or excuse me, this Helm chart across your org, or between several orgs or whatever, and you've got an edge case that you're only using once, use a post renderer for that. You don't necessarily need to clutter your chart with that logic and what a post renderer is just means that you can actually use a customized patch with a Helm chart and that you don't have to spit out templates for it. You can, there is a step during the Helm release life cycle that you can choose a post renderer and just use that little patch. One or two, however many patches you have for your edge cases. It's nice, it can keep your charts clean and look into it if you haven't. Absolutely. Yeah, it's really great too because then you can take some upstream chart that doesn't support the things you need for your dev integration in prod, and you can use customized to build dev integration in prod. So name templates, here's an example. This actually comes from your basic Helm create function. And it's slightly complicated because first of all, your names of things can only be 63 characters long. So if you happen to name your release, you know, some really long string, it's gonna fail if you try to append, say, the name of your release to it. So you've got your chart name and release name and that's how it creates some defaults. And it shrunk into all the 63 characters. But you also might want to override it and that's where you have the chart name values, name override. So if you put in your values, name override equals something. When it comes to that part, it'll replace all the stuff that it's creating with the name that you wanted it to be. So this is really cool because then you can take and you can put a reference to this any place you need to name something. So all your deployments, your services, your ingress, whatever. And that way you only have to do it once. You don't have to have all this complex logic of figuring out what is the name of this resource. You just have this named template that you call with just a include. And include food.fullname. And it'll actually do. We just spit out the formatted name based on that thing. And you can see, as I did, as I show there, if you run a Helm template, my release foo, that whole thing just creates my release-foo. Anything else to add? And you can do a lot of this stuff because there are a lot of built-in objects. So obviously we talked about values. You everybody knows values. Values is what goes in your values.yaml file. It's presented as values. And then whatever's in your yaml. I think everybody's familiar with that. But there's also release, which actually, the previous slide, can I go back with this? Oh yeah. So you can see here it actually uses .release.name. So it's the name of the release. So when I Helm template, my release foo, my release is the name of my release. And so it actually uses that information in building the name. So you can use, there's several fields under release you can look at. There's actually chart, subcharts, and templates. So under those objects, you actually have all the data that's in the chart, the subchart, the template. I actually have a chart that I wrote at Red Panda that I wanted to pass a bunch of values to it, but I didn't wanna have to make the user duplicate all the same values in the values.yaml file for the parent chart and the subchart. So I had set a flag in the subchart, which is basically tells the subchart don't render this chart. And then I built all the values from the master values for the subchart. And then I just used the files, actually I used files down there to reference the file of the subchart and template the whole thing in the master. It's really hacky, but it works really well. So it's fun little tricks like that. You can use all of these for capabilities, of course, we'll tell you what capabilities your API has. If you run this against the actual CUBE API server, it'll tell you the capabilities of that API server. If you wanted to look at all these objects, which I do all the time, because there's always things that I forget where they are, it's really simple to just create a yaml file that just dump everything. I usually throw something like that into the actual chart that I'm rendering. And then I'll do a Helm template and get all this massive amount of data and then I'll find this piece that I want. But it's really handy to look at all the different variables in there. The documentation lists them, but it doesn't list them in depth because in depth there's a bunch of things that are there that aren't there and only there because of the way you wrote your chart. It's these little tips and tricks that save you a lot of time. You do the same thing over and over and over. Okay, maybe you save 30 seconds here, but that adds up. You can look at all the different types of objects, not all the different options that are available. So we really want to emphasize today is really a lot of the tips and tricks that you will often use to be successful. So out of the functions, those are the built-in objects you can use although much of these functions on those objects. Primarily the functions are provided by Sprig which is an upstream repo. Sprig provides a complete list of a library of functions, the string manipulation, mask, dates, lists, everything listed there and then a bunch more. Some of the ones that I'm going to highlight here to from YAML and JSON, those can be really handy. For one thing, the name templates that I was showing earlier, they always return a string, always. But if you may want something more than a string, you may want it to return a dict. If you take your output from the named pipe, run it through to YAML or to JSON and then take the output of that and run it from JSON, you end up with a dict. It's super handy. And you can do things like version comparison which is also useful. You've got an application that supports this flag this way and this version but then the major version upgrade changes that flag and you have to do it a whole different way. If you compare the, if you do the version comparison against let's say the tag which should hopefully represent the version of your application, you can change the behavior of your chart to match the version of the software you're serving which means you can have one chart that supports multiple versions of your application. I use that heavily at Red Panda. And of course you can also, because it's checking versions, you can also query the capabilities of Kubernetes and it'll tell you the version of Kubernetes and you can check against that and test, oh this version of Kubernetes doesn't have this resource. You're running a very, very old ingress resource for some reason. You can ensure that, well, okay, we want to make sure we use this API group versus that API group. So you can extend the range of Kubernetes versions that you can support with your Helm chart if you have, say, enterprise customers who don't like to upgrade. I know, yeah. Oh yeah. And then a very underused function out of Sprig that I see is dig. Digg's really cool because if you've got your Helm chart, it has, are you seeing, your values and you want to deprecate some value and move it somewhere else. Say I had under, well, Red Panda listeners, HTTP, internal, TLS enabled. That was a long way down. And you had to do that for every listener. And maybe you want that, maybe you don't, but one of the things we wanted to have was like, no, I just want to turn them all on. So we had a top level TLS enabled, but then it was like, okay, well, how do I know if it's enabled? So, well, what if the enabled isn't on the listener? Well, then if you evaluate it, it's always gonna be false if it's not there. But it's not an actual, it's just bizarre because if you wanted to override something, you end up with this false when it's not really false. So a dig you can go through and you can say, from this resource, I want to go this depth, this depth, this depth. And if it's not there, this is the default I want. So you can set something to true even if it evaluated to false, even if the key wasn't there when it got to that level. Which is super handy. So, oh yeah, I actually have an example. So, oh no, this isn't that one. It is that one. Yeah, so this is one where if oh, this is just about returning JSON. Yeah, so returning JSON. So, I think I remember this. So if you, I've got this helper and it's gonna check to see if TLS is set. But TLS is commented out. So, or excuse me, enable is commented out. So, normally it would error if you tried to get values.tls.enabled because enable doesn't exist, he doesn't exist. But with this dig, it's gonna check under TLS. Can I point to it? There it is. Dig's gonna check under TLS, under enabled. And if any of that fails, just the result is false. So even though that key isn't there, it's gonna return false. And because I've got the two JSON, I put it into a deck with the key bool. Then in my template, I can actually pull it back out and I actually get a bool. It's not an empty string. It's not a, you could get an empty string. This is actually, I don't want an empty string. I just wanna know if it's true or false. This is the way to do that. Got any other cool tips? You gotta get them, I gotta roll them. Okay. Version comparison. Again, this is how you can compare your application version. I've got a named template that is called apt-asimver. I can compare the versions and do something based on the results. Or my app doesn't support that deprecated version. I just call a fail and avoid melting your CPU. By the way, the fail function, go back and check this out if any of you aren't using it. It's so handy in so many ways. We can do a whole session on that. So talk to us after. Another spree, another spree function by the way. All right, nice job. All right, test it. Okay, awesome. How much time do we have? Five minutes. Okay, cool, because I can talk for like five days in a row about this kind of stuff and just, I'll try to keep on track, but easy to fill up time. So, oh, thank you. All right, yeah, so, okay. So how many of you actually have like, use Helm testing to test your charts? And you can be totally honest about this. Usually it's not that many people. But it's cool that some of you- We're talking the in-provided Helm testing, not any others. Yeah, yeah, it's cool that some of you do. And it's so handy, basically. I mean, whether you're making your charts available to the public or not, it's really, really handy. It's so handy that when we had maintained the, I don't know how many of you used the stable and incubator repose when you first started using Helm, like Helm install, stable, WordPress, or things like that, that hasn't been around for a few years now. We've moved to distributed repose. But if you did, you'll know that they were all very well tested. That's one of the reasons that people use them. There are still important Helm repositories out there. And not just, I don't mean just necessarily reposing as an HTTP repose, like for example, build Bitnami is one very good example of a Helm repository, even though their charts are an OCI too. But the actual source repository uses Helm testing before every commit and they also regularly run Helm testing. How many of you have either used Bitnami charts or have seen them, referenced them? If you haven't, please just look at them. You don't have to use them. They are a great resource on how to develop against Helm. Yeah, yeah, a lot of the Bitnami folks initially were also co-maintainers of that repo I was talking about, the former centralized Helm charts repository with the hundreds of apps and stuff like that. It's still archived, so you can check it out if you want to, even though they're way out of date now. But the point is, they were on that and they continue to follow a lot of those processes that they themselves set up and many of us also set up and collaborated to develop, to help consolidate and build best practices for Helm charts. Again, some of them, you might have better best practices, so I really wanna hear from all of you who are doing this in the wild now because things continue to improve. But anyhow, so testing, the, really the easiest way to start is you'll see a template if you do Helm create foo, your foo chart is going to have a test, a test directory, yeah, in the templates folder and it's going to have an example template and it's going to use, I think it uses the Helm.sh slash the test hook. It does. Thank you, Andy. Yeah, I haven't looked at it for a while, but yeah, it should if some glad it does. So you can look at that and it's really basically follow a similar model. The idea there is that that, you can put any templates you want in there. They won't run any other time unless you're running Helm test. So it's very handy because if you, if for your chart that you're writing, you need, I don't know, some, you need some custom CRDs. You need some, you need some stateful sets. You need lots of different things that you would be doing in other ways for your actual chart for production or for any other environments. You can mock those inside of this test directory. You got two minutes. Cool, so, so yeah, check that out. Thank you. Also check out the github.com slash Helm slash chart dash testing project. A number of the former charts maintainers are still a team on the Helm team and help to maintain that project as well as other tooling. You could just use that. You could just actually use that and not do anything special in your charts and you will have testing. So basically in a similar vein, that same team of people, a subset of the other Helm maintain, a subset of the total Helm maintainers, also maintain the chart releaser project. That is just a simple way to allow you to have a Helm repo without having to do anything, any kind of special steps yourself. There's a github action setup for it. If you use github, if you use GitLab, you can still use the chart releaser project. You don't need a github, or excuse me, a GitLab CI. But if you do develop one, let us know because we'll, I don't know. Contributions welcome. Yeah, we'd love to have that because right now we only have a GitHub action that wraps that. But the project itself, you can call directly and through any other CI any way you want. So please, please check that out. There is also a nice little setup. It's not actually built in, but there's a nice way to additionally push your charts to OCI registries. Speaking of the devil. Yeah, yeah, exactly. Oh, next one. Okay, so let's, yeah, you should, well, you should consider this. The reasons for it, since I know we don't have a whole lot of time, I'm not gonna just read off of this, but OCI has a lot of benefits as opposed to using HTTP repositories. One being that if you have a ton of Helm charts, there's no concept of an index file in an OCI registry. You don't have to worry about that. It will never be a continually growing thing. How many of you have heard of the concept of OCI artifacts that was like drilled into everyone's brain throughout the keynote in a couple other sessions today? Guess what? Helm has been doing this for many years. So we've kind of trailblazed a lot of the work and a lot of the maintainers are currently working in open source projects like myself. I'm a maintainer on the Aura's project. I joined Helm to become one to help push OCI artifacts across the finish line a couple of years ago. I see OCI artifacts doing a lot of things and Helm is gonna take advantage of this entire ecosystem that is just starting to incubate. And like one way we're using OCI artifacts is around signatures. You can now go ahead and sign your Helm charts. Very easily using tools like SigStor and other tools out there to make it even easier to provide providence data to your charts. Exactly. Pretty much anything that, well, most of the tools that are there to make working with containers nice and secure also apply to the artifact type, OCI type. So take advantage of it. You're all at KubeCon. So containerized workloads is not a new concept. It's been going on for a long time now. It's been going on for less time for config as code. That's essentially what OCI artifacts are. Anything you want to store in there, you can store a database in there, but don't. You want to generally use config and so you can deploy that along with your containers. That's the basic idea. And okay, I mean, I guess, now we just sort of tell you, stop by the booth, right? Please stop by the booth and say hi to us. We've had like really awesome people maintaining the booth so far. I have not done it, but I will tomorrow. And say hi to me and then say hi to us on Friday. Yeah, if you're really interested in, we're gonna make this a little interesting here. If you're interested in contributing to Helm, wanna influence the project, but most importantly, if you're interested in this thing called Helm 4, yes, it's coming, come on Friday. We're gonna talk about it. I know it's unfortunate, the last session of the day at a conference, so if you're able to stick around and join, please come down to us. We're gonna be in room E08 on this level. And aside from that, thank you very much for your attention today and enjoy Helm.