 For one, we're gonna get started. This is about some members from the Helm team giving you an intro to Helm and its ecosystem. Yeah, we were just commenting on how it's great that we have a bigger room this time. Last time in Valencia, it was completely packed and there were a giant group of people outside that couldn't even get in to see. So I'm glad that there's room for all of you. So I'll introduce myself first and then I'll pass the mic off to others. I'm Scott Rigby. I'm a developer experience engineer at WeaveWorks. I am a Helm maintainer and I work, let's see, I'm also a flux maintainer. I also am part of the GitOps working group and co-chair of that. So if anybody's interested in that side of the ecosystem, feel free to come and find me. Thanks, Scott. Hi, and I'm Karina Angel. I'm with Red Hat. Also, Helm maintainer. Andy Block. Good to see you. I'm a Helm maintainer as also part of the six tour community driving a lot of the initiatives around Helm and bringing that into that ecosystem. And hello, my name is Matt Farina. I work over at SUSE on Rancher. I'm a Helm maintainer, artifact help maintainer on the TOC and various other things. So before we get started talking about the ecosystem, we wanted to talk about what is Helm? A lot of people have their own ideas on what Helm is and where it fits in, but we have an idea on where it fits in, which is important to knowing boundaries and what's going on with the ecosystem. And Helm is a package manager, right? And what is a package manager? We call it a package manager. We say it. And a package manager is really about, here's the definitions from Wikipedia. Here's what we say at Helm. It talks about that traditional tool, that thing you can think of as yum or apt or zipper or if you're on Mac, maybe homebrew, something like that, where you package something up. And so these are the definitions and that's what you traditionally think. And this is what I've put together, right? Because there's more to this concept than just packaging something up, right? It's a tool, I think, that enables somebody who doesn't have much knowledge about an application to install it and just run it because somebody else who knows the platform really well, in this case, Kubernetes. And they know an application really well. And if I were to use an example, it might be something like Postgres. And they can package that up into something that somebody who doesn't know either of those systems really well can install, run, and be successful with. And that's really how traditional package management has worked, right? If I go install Postgres on a Linux server, do I know where all the binaries need to be placed on that system? Do I know the config files that need to be there to get it started? I'll admit, I don't. I have to go look those up if I were gonna go do it. But I can just install it and it works. And that's what Helm enables you to do. And with some of those systems, it may seem pretty simple to put some of those things in place. But I like to look and use WordPress as an example. The always-example thing for WordPress. And if you were gonna go install WordPress yourself, you're gonna have all of these different resources, deployments, horizontal pod autoscalers, services, network policies, Ingress, stateful sets, you're gonna have secrets, along with WordPress itself. And you're gonna have more than one of these. You're gonna have over a dozen different EML files, hundreds and hundreds of lines of EML that somebody needs to install. And they need to know your database. They need to know WordPress. All of this stuff to figure out how to do it well. And somebody just says, I just wanna run it, right? That's a lot to have in one place. But when you can package that up and then distribute it for others to use and install, or maybe other people in your own organization, that's a really nice, useful thing. And that's where Helm sits. It is a package manager and we draw our boundaries there. But by drawing our boundaries and knowing what our boundaries are, that means other projects can pick up from there. And when we think about Helm, I like to break it into kind of three really useful parts. The first you have charts, the packages that you package everything up in. And you've got your chart EML, you may have your JSON schema, which is really useful for some things. You've got your templates, maybe your CRDs in there. Hopefully you've gotta read me in notes so people know what they're getting into. But you've got these kinds of things and you package all of that up into a chart. Then you have the Helm client, which is where a lot of people use it. It's that CLI that you go run to install things, right? Helm install WordPress. And in this example, I'm grabbing it from Bitnami because that's where most of the demos do for this. And it goes ahead and installs it into a cluster. And then you can upgrade it, do other things. You can even use values and you can set the title and other stuff for it there because you can encapsulate business logic and pass that through the Helm CLI to pass that along. But there's another important piece to all of this. And that's the Helm SDK. And the Helm SDK is really what the Helm CLI is built upon. We took, when Helm version three was being created, people wanted to build things on top of it, things like flux and other things. And they said, you know, we wish we could access it and it wasn't just part of the main package you can't import and go. And so we converted everything, virtually everything into a package. And then the Helm CLI, the code for that, imports that package. So other things can then build upon it. And that, I think, was one of the best things we did because it enables other tools to build upon that same logic that we have in Helm Client. We fix a bug, they get the bug fix. We add a feature such as when we added OCI, you know, chart registries to push and pull charts from. Anybody who picks it up can then just inherit that feature. And the SDK is this incredibly powerful piece to what makes Helm possible. And when it comes to the ecosystem, somebody sent me a picture just like this the other day and this is an XKCD graphic and I've altered it to put Helm under there. When you look at some of the things that they're gonna walk through in just a minute and we're gonna walk through a lot of different things, you can see Helm is an underpinning. And that underpinning is really important to making, you know, how we build that, how we treat that is really important to everything that's built on top of it. If we break that, we break all of them. And we have to keep those things in mind. So with that in mind, Helm is stable software, right? And in fact, we have a backwards compatibility guarantee. If you go over to github.com slash Helm slash community, we have these Helm improvement proposals. And one of them that I've got up here is our backwards compatibility guarantee where we actually talk about all of the things we're gonna be backwards compatible on and how we do it, right? Are string messages backwards compatible or not? One of my biggest pet peeves is dates. We have this one place where the date format's different and we can't change that until Helm version four because we'll break backwards compatibility for things that read dates. And, but we keep that because we know stability is important for people who use that. We could add a flag. Now we're going down. We did add a flag. So to change the date? Yeah, so the format. So for this, we follow semantic versioning because we think it's important to broadcast our guarantees, right? Major breaking change only happen with the major and we're gonna be backwards compatibility. Minor features come in minor releases three times a year. We're about a month delayed from Kubernetes releases. It's very predictable. It's the second Wednesday of the month unless it comes just after the holiday season in November, then it's the third Wednesday. And you can count on it unless something comes up unless there's something that throws us off. That's what we do. And then patch releases on the Wednesdays when we don't have minor releases. It's very predictable because we know people build on it. They depend on it. They need to know when things are happening. And all of that is why Helm is a graduated project. You probably saw this this morning in the keynote talks and Helm is a graduated project because we had to have that maturity so things could be built upon it. And so with that, I'm gonna hand off to let Scott start talking about our ecosystem. Thanks Matt. Yeah, so some of these initial images are graphs that expand on what Matt was just saying about how to envision where Helm fits within the boundaries of the ecosystem. So the very first one, oh and by the way, these images are modified from a blog post that Matt, Farina actually wrote four or five years ago. But anyway, this just gives you a sense of where the stack is. So in OS generally, we're talking about, I mean many of you are familiar with this, but we're talking about something like Linux, Windows, or even Kubernetes for example is an example of an OS where it's more of a distributed system and not just a single machine. The binaries are the applications themselves. So exactly in the case that Matt mentioned before with WordPress or something like things that it relies on like Postgres or MySQL, those are the actual running applications themselves, those binaries. The config in this scheme is the configurations for those applications. So for WordPress or Drupal or something like that, there are actual config files for that app. For its dependencies like MySQL or something like that, there's a My.com for whatever it is now. I haven't touched it for a while, but the configs for those applications themselves. The package manager is something like, exactly what does what Matt was just saying that really allows users to install all of these things without having to have intimate knowledge with the applications or configs themselves. And then there's the configuration manager, which actually helps you to determine which environments you're deploying on, different things that are important for you in your workflow and your organizations and so on. So just to give you an example of what those are, this is just very general and vague, but it kind of helps to get more specific to what we're doing in Kubernetes to compare it to something like a typical Linux setup. So you've got that Linux layer is maps to the OS. In this case, the ELF binaries, just whatever are packaged, those binaries that are packaged for your Linux environment on whatever architecture. And say you've got your configuration files in ETC or depending on your architecture in another spot, right? And then this is where we compare, with Helm is the package manager in this case is like apt what Matt was mentioning, say this was a Mac environment, it would be homebrew, et cetera, that's actually what controls and helps that process, or it's supposed to anyway, controls and helps that process for users, right? And then what your config manager, the examples here are like Chef, Puppet, Ansible, now GitOps would fit in this category, I probably should have added that to the list, but those are the examples, right? And then, so that just kind of brings us to where we are now. OS is Kubernetes, in this case for Helm, right? The images are the binaries, the configs are the Kubernetes resources, and then there's Helm as the package manager. And so basically like in your configuration management, there's a lot of different options now today. So yeah, I was mentioning like there are GitOps tools, there are various other ways to actually manage those configurations and manage Helm for you. Also the Helm CLI is an example of that when you're just doing it manually. Okay, so I think this section is me again, I'm just gonna go through a couple of options that fit into that top category for platform and app management, GitOps fits in here as well. So one is Flux, I had mentioned this earlier, this is an example of Flux architecture, not having to do with any of the UIs yet, but basically Flux draws from, oh boy, I wish I had a pointer, but on the right Flux draws from things like GitHub and Chart Museum and now also things like OCI registries and S3 buckets and things like that. As sources, it sends that information to the Kubernetes API and then there's a controller in this diagram we're focusing on Helm, there are other controllers, but the Helm controller then talks to the Kube API to get those custom resource definitions and the information about where to find those configs and packages that the source controller pulls into your cluster. And then it manages your Helm releases for you using the Helm SDK that Matt mentioned earlier. Yeah, so that's just an example of that one. I'm a little more knowledgeable about that because I help on that project. There's also the Argo project, which does a similar thing just in somewhat different ways. It primarily uses the Helm binary to template out your resource files from a Helm chart and then it does otherwise a relatively similar thing. It manages Helm in an unattended way for you too. And one of the other examples that's been around for many years now is Helm file. It's a bit of an older example. It doesn't use CRDs to, so there's no exact, let's say API contract for the structured way in which you should manage your configs for your Helm releases. It uses YAML, but that's, I believe, because it was started before CRDs were really mature. And it's a project that people still use and it's still a really good project. People are also using Terraform to manage Helm charts. There's the Terraform Helm provider. So I know a number, well I don't know in this audience, but at least when at the Helm booth, there are a number of people that are using the Terraform Helm provider. There are pros and cons to each of these. I believe there are still some issues with wait time and hooks, but otherwise, and for many folks, it works really, really well and it may just fit your use case. So I think, oh, I guess it's me in this one as well. I'm just gonna fly through chart storage because I know we need to get onto the other folks, but basically, there are different ways to store your charts, right? I had mentioned OCI as well. This first slide shows how, or on the left, you've got your ability to push charts to, in this case, an Azure Container Registry. Really any OCI registry that supports artifacts, in this case, all of the major ones, except currently, there's work being done, very hard work at Docker Hub to support this, and it's not quite there yet. So close, so close, but that's okay because you can use Docker Hub for all of your other containers or some of them, or none of them as you choose. The other, let's see, there's information about how to do that, in this case, in the AWS docs, but every single container registry from every major cloud has similar docs, including GitHub, GHCR, and all of that. Harbor is very similar in this way. I'm actually not really gonna talk a whole lot about Harbor. I think I should probably fly through these now, but you basically, there's additional options for chart storage there. You can, I believe that's a Helm repo, directly right at the HTTP repo with Harbor. I actually never used Harbor, believe it or not, of admitting this. Yeah, so Harbor actually has the two ways to do it. You can use Chart Museum to use Chart Helm repositories or OCI registries. It supports both. I didn't know that part. That's awesome. Okay, so TIL, today I learned, and yeah, so traditionally, so I mentioned OCI registries. Of course, traditional chart repositories that are in HTTP endpoint with an index file, those are still supportive, and that's not going away anytime soon. You can also, yeah, you can use Helm plugins. Helm has a plugin system, so you can store your charts in other places. This is an example of a plugin to allow you to store your charts in S3, or S3 compatible buckets without the need for another tool, like I mentioned, Flux allows you to do that, without the need for some other tool to help you with that. You can do that directly with the Helm binary using plugins. And speaking of plugins, there is now a Helm Sigstore plugin, which I have not used, but I'm very excited to see this. I know we just added that to Flux. I know a few other projects are adding Sigstore. Sigstore lets you sign and verify charts and other cool stuff. Super important for security. You wanna say something about that? Yep, and if you're interested to learn more about Helm in the Sigstore community, I had a talk on it on Tuesday at SigstoreCon, so I'm sure it'll be on YouTube if you're interested in it. Awesome, yeah, perfect. Yeah, the community is huge here. And now I'm gonna pass it off to Karina for discovery. Thank you, Scott. Sure. All right, so if you were using the old Helm Hub to find your charts, we deprecated it. So let's go ahead first. Just how are you finding your charts? Did anybody use the old Helm Hub? No, yeah, sorry. Are you gonna help me use it for a while? Exactly, now we know. All right, so Helm charts were all designed to be shared in a distributed manner, right? And even when Helm had its own charts repo, the whole system was designed to have distributed charts repos. So with the old Helm Hub, yeah, deprecated, it was the first attempt to help people find these charts, but it didn't scale very well. And instead of creating a newer version of the Helm Hub, a artifact hub was created. So this is another CNCF project that you can go join and go add to that community. But the first thing that you could find in artifact hub was Helm charts. However, it was designed so that you could also find I'll talk about that in a sec. So in the artifact hub, you can navigate through your Helm templates and you can compare your differences in the versions and you can read your default values and you can search them. And the JSON schema has a very easy to use user interface to help you navigate them. And- It's really a little tidbit, like please check that out. Yes, yes. And you can see the changelog and screenshots too. So this works again for Helm charts in your Helm repos and your OCI registries. So if you're using OCI. All right. So some of this information bubbles up to the search results and things like a chart being the official chart of a project or that artifact hub has verified the owner. You know, that's very important for a lot of enterprises that are using it. And security scans, also very important. And the images are scanned using trivy and the scan results are available for anyone to read. Okay. And artifact hub again, isn't just Helm hub. So as you can see, you can search for Helm charts, your operators, your tecton chains and so many more things. So go check out artifact hub. And other things are also Helm plugins. So plugin developers can list them here and if you are a plugin developer please go list your plugins and you can search for them here. And of course, artifact hub isn't the only place to discover your charts. You can use the Bitnami application catalog. So Bitnami is now part of VMware and it has a huge collection of Helm charts. All right. And your catalogs come in many shapes and forms. And here's just an example of the Nvidia catalog. Now let's move to discovery and install. So there is more to all of this than just discovery. Default values, JSON schemas and packages means that you have enough to tackle the install problem in addition to the discovery problem. For example, so package managers have been used to build app stores for a long time. And this is an example of POPOS and it can work with multiple package managers. Here's an example of the Rancher Charts catalog where you can search for your charts and easily install them. Look at your chart versions. Nice UI. And if you are using OpenShift go into the developer console. You can go search for your Helm charts and you can deploy them to your project. And the Weave GetOps GUI. With the installer you can go through and install your chart. All right, for the developers in the house we are gonna have a section on developer tools and how you can integrate the Helm ecosystem into your workflows. Let's start out with kind of going back to what Matt started earlier was the SDK. How many here have actually used the Go SDK when doing development? Okay, there's some hands, that's pretty good. Good way for you to get involved if you wanna create an integration with Helm, use the SDK. Now, this is one challenge that I as a developer find especially when I'm developing my own Helm charts is generating JSON schema. While there are two plugins and other options out here to help you generate your JSON schema resources, there are two plugins that you can go to. One of them here on the left is actually deprecated, the Helm JSON Schema Gen. That one is kind of in maintenance mode but the one on the right, the Helm schema is currently being maintained. So if you wanna get some help being able to generate those JSON schema resources, there's a plugin that can help you get that out of the way. If you're a visual person, developers aren't necessarily all command line, there's a React UI that can showcase all the different values that render appropriately so that you can ensure that the values that you expect are available in a nice, rich user interface. There's also a chart verifier. So you can verify certain conditions available for your application. So if you have consumers or producers that you want to serve charts, you can run it through a verifier. This is from our Red Hat friends who can help you provide a way that you can verify different conditions on your Helm charts. Now some tools from the Helm project itself, the chart testing tool. Chart testing is a fantastic tool because it can not only showcase how you can verify that it lends appropriately, but you can also test the chart within a live Kubernetes environment. And if you're also developing, you probably have some CI around your Helm charts. There are a couple of actions that are available from the Helm community to help you. There's the release action that helps you release your artifacts. And then there's also a wrapper around the chart tester that I just mentioned a moment ago. Both really easy to integrate into your GitHub workflow. But those two just from the Helm project are just the beginning. There's tons of actions in the GitHub catalog. So if you're interested in leveraging the various ways Helm can be used in GitHub workflows, check out the different actions that are available. But then there's also just working in your IDE. How do you go ahead and work on your day-to-day life working with Helm and Helm development? Well first, there's the VS Code extension. So if you are a VS coder, being able to integrate Helm into your workflow is really easy. If you want to use an extension, great. It's available if you want to just go ahead and manage it without one. We have options too. And you don't even need a UI. You can just use Vim. And there's a syntax highlighter on there. It's not everything's about the UI, folks. There's always folks who never want to look at a UI. In Vim, there are two syntax highlighters available. One for Kubernetes and one specifically generated for Helm. I'm gonna turn it over to Matt, who's gonna talk about how you all can get involved. All right, thank you. So before I jump into that, I just want to say all of what we just showed you was just a fraction of the projects that are out there that are built on top of Helm. And some of its developer tools, some of it's what you need for production. And all of that is because Helm has a stable API, a stable surface area, and you know what you're gonna get. And without that, we'd be breaking folks all the time. And so that does enable it. Now, if you want to get involved, that's great. We love involvement in the Helm community. And one of the first things is if you have your own project built on top of Helm, we encourage that. Build projects on top of Helm. Get involved. You've got something new to create. There's the Helm SDK. There's even other tools you can use as intermediate layers. Get involved, build something. If you've got an itch to scratch, try. The Helm plugin system is there to let people expand Helm. And so please, and if there's not a plugin access point for it, come talk to us. Let's build one. We might feature it in the next question like this. You can also get involved in the Helm source code. We are always looking for people to help fix bugs, answer, you know, respond to issues and contribute new features and new ways of doing things. Even though we're not breaking APIs, we do add functionality in minor releases all the time. And so come, contribute. If you're using Helm and you're looking, where's some place that I can get involved in the ecosystem and give back? Helm. And we can help onboard you and help you get started. And if you want to know more about all of this stuff, of course, there's the Helm website. You can go over here, learn about plugins, learn about the ecosystem, learn about contributing and getting involved because we tried to document all of it as much as we can. And you can also find more about the Helm community on Slack. We have a weekly community meeting on Thursdays and we have a mailing list. You can do that. You can also, and I failed to put it up on the slide, we do have a booth down there in the project area. And at 2.30 today, if you want to come down to that booth area, you'll find Helm and you can talk to some of us. Could I give a quick shout out before we move from just real quick about the Helm triage. I know we have only a few minutes left. Yeah, there is an official role to help on that ladder of contributing that Matt was discussing called the Helm triage maintainer. We mentioned it in the last talk, so I won't go on too much about it, but just as a reminder again, if you want to get involved in Helm, one of the best ways right now, yes, contributing code, we have something like 200 to 300 open PRs, right, I think in the Helm project, we need people to help review PRs. And that might mean just actually please, because Helm maintainers only have so much time and we're often doing a lot of other things. Helm is a stable project, as Matt mentioned, so we're not necessarily crunching on it all day every day. It runs very smoothly, but we do need more eyeballs and we need more hands on keyboards, right? So if you can open up an issue, if you're interested in getting involved, the path towards becoming a Helm triage maintainer, if you would like, you're still an actual Helm maintainer, it's just on the rung towards helping to maintain other things. You can open up a pull request, or excuse me, go in the pull requests list for Helm Helm, or actually any of the other projects, but I think Helm Helm we need it the most. Open up a pull request, try to see if the issue that's described in the pull request, is it clear about what it solves? Is there an issue that it's tied to? And if so, does that issue have reproducible steps to show you how to break it? Can you reproduce them? If you can, try to pull down the pull request branch and build the Helm binary and see if it fixes it for you. Just that alone, not even reviewing the go code or anything like that, just that really helps unblock Helm maintainers from doing all of that work ourselves because often it can take, I don't know, 15 minutes, 30 minutes, an hour possibly sometimes to get down to the bottom of it. And we might only have 15 minutes to go through the go code and work on it, but we're not gonna spend time doing that if we don't even know what the issue is and if it solves it. So please help and let us know if you want us to, basically with sustained contributions there, you can become a Helm triage maintainer and there really is no cap on how many people can do that. So please let us know. Thanks. All right, thank you Scott. Yeah, and as I talked about this morning in the keynotes, it's we're looking for contributors. The whole CNCF is looking for contributors and we've got a path to help people who are interested in getting into it. And you can learn so much along the way like how to maintain a mature project. What does that even mean? There's so many little things to it and there's opportunities to learn that I've learned play out in my daily life in doing the other things that I do for work. So with that, I guess I'll open it up to questions and again, you can find us starting at 2.30 today in the booth. We'll also be down there tomorrow afternoon as well. Does anybody have any questions? Ah, yes. Do we have, if we don't have a mic, I'll repeat it. Certainly. So he asked if you build a tool for the community, is there a way to showcase that? I would say there's a couple of different ways. One, we have weekly meetings on Thursdays. We love demos. The second thing, or there's more than one way, we have a tag, because you can tag repositories up on GitHub and people can go see all of the things there. And so we have a tag for that. I'm forgetting what it is right now. And then we also have a related page in the docs. So you can go to the docs, go to the related page to see all of those different related things. And of course, if it's a plugin, you can add it to Artifact Hub for other people to discover it. So there's a number of ways to showcase that and we love seeing it. Yeah, and if there's something missing, if you know something missing, open up a request for the website repo. We love those. Thank you. Any other questions? Oh, over here, yes. That's happened. That's where Helm template came from. So he asked, would a plugin ever become so popular that we would pull it into the Helm source itself? And the answer is yes. We've actually done that. That's where Helm template came from. It hasn't happened in a long time because one of the things we are encouraging is a healthy plugin ecosystem around it and letting things naturally come and go that way. But if there is really high demand, it is a possibility. And as far as the Helm diff plugin goes that you asked about, I haven't looked at that in a while. So I don't know if it's in demand or not and nobody's asked for it to be merged in. So that's just, okay. Any other questions? Fantastic. We are actually at time, so it was perfect timing. Thank you all for coming and I hope you enjoy the rest of the conference. Thank you.