 Yeah, so welcome to my talk called Helm for Beginners on the Kubernetes community's day Churnay today. So let's start with the today's agenda at first. So today we have a very interesting agenda. First we will understand Helm 3 and then understand what is Helm 3, why we use Helm 3 and how we can use Helm. We will understand a bit of architecture of Helm 3 and about Helm charts and Helm depositories. So this is the agenda for today, a bit about myself at first. I am from Kolkata, India. I am a sophomore year student. I am a Gold and Magical student ambassador. And here are a couple of my social connect with me. So the first question, what is Helm? So Helm is a CNC graduate project. And there were a couple of versions for Helm. The first one was released in 2016. And the latest one, which is version 3, is released in 2019. So the version 3 is widely used right now. And the version 1 and 2 has some dependencies which are not there in version 3. So version 3 is quite good. And whenever you start with Helm, it's recommended to use version 3 because it has various features which you require. So what exactly is Helm? You understand it's a graduate project. You understand there is a new version. So Helm is like a package manager. Like in Ubuntu, you have a package manager called APT or like in another distro, you have different package manager. Helm is a package manager for Kubernetes. So Helm uses depositories and manifest to create objects automatically. For example, if you want to deploy a WordPress website, then you can either deploy it by creating one component after another or you can go and deploy the whole website using Helm because it's easier and you don't need to create hundreds of objects in it. It's easier by creating one chart and then using the chart to deploy your objects. So why should you occur? As I told, manual deployment is tiring. Whenever you go and create a WordPress website or some other cloud native application inside your cluster, you need to go and manually deploy all of those things which will be very tiring because you need to go and create the services, the replicas, the deployments, the custom resource definitions and all those things. Helm comes as a package manager which will go and deploy all those things and say you don't know if everything that deploying will be working together correctly or not. So we leave the experts to package the application so that it's easier. Manual deployment isn't reproducible because a problem inside a cluster is like if you deploy something in a half a second manual, it's very hard to reproduce that. So you need some versioning kind of thingy. Either you can use GitOps or you can use Helm in which you can deploy a lot more things with a lot more control. You can also change parameters inside your image and all those things which can be helpful for your deployments. Because application updates with manual deployment is prone to errors. For example, whenever you want to update your application, for example, you are using version one of custom resource definition. And now you want to go to version two. Then you can just go and change the values.yaml file inside Helm and everything would be updated. You don't need to go and update everything from scratch and find things which are there and which are in there. And if something goes back, it's very easy to roll back. So this is one of the advantages Helm provides us which is very hard for manual deployment. To summarize, you can deploy things using charts and you can roll back or you can reproduce your deployments by packaging. Hello, Ritik. Sorry to interrupt. Your screen size is a bit smaller. The slide size is a bit smaller. Could you please reshare? I think you need to share the entire screen. Then only the slide size will be bigger for us. Okay, sorry, sorry. One second. Please share the entire screen. Yeah. Yeah, now it is visible. One second. Yeah. Yeah, thank you. Yeah. So as we discussed, how Helm helps. So first one is it gives us an easy way to deploy a complex application. Like suppose you want to deploy a WordPress application as we discussed in our previous example. So it gives us an easy way to do that. It also gives us an easy way to update specific values. For example, if there is a container in which you need some specific values, like for example, you want to create a container with the red color in it, then you can package that in such a way so that it becomes easier for the person who's deploying the application to update that. He or she doesn't need to go and debug everything inside that to deploy that. Also, there are other things like provides a way to share your templates across organization. Once you have created a template, you can just upload that and then people can go and use that and share that across the internet so that anyone can use that. Suppose I have created a Helm chart, then it will be easy for me to share that so that another people can go and use that. So the second another advantage of this learning curve is very low. To understand how you can deploy an object, you need to understand when it is deployment objects and other objects also with that. But Helm, you don't need that much information regarding all of those. If you have the repository name, you can just apply Helm apply commands and then you can use that to deploy all of your object without knowing a bit more about Kubernetes if it's required for use case. Then as we told, it's very easy to manage dependencies with Helm because you can go and update the versions as required. And also, if something goes wrong, you can go back to previous change. So to understand the architecture of Helm, let's understand this is your Kubernetes cluster. This is your Helm CLI and this is your Helm repository. So here is where people upload their charts and all the other things. And then whenever it's required, you can pull the charts using the following repository to your any storage bucket or anywhere in your command prompt also. And then you need to authenticate using your Kubernetes cluster which can be done using Kube config file or something else. And then you can deploy your repository into your cluster. When you deploy your repository, this is a release and with the release, you can deploy any application which you require. So to understand components of Helm, there are a couple of components. First is the charts.yaml. So charts.yaml has an API version named version description dependencies, keywords which are required for you to index. So API version is the version of the Helm chart. The name is whichever you can give. The version is one version in which you can index and query your Helm chart. Description is there for people to understand what this chart does. And the dependency is there. Suppose you want something deployed before the Helm chart starts to deploy, then you can use that using dependencies. You can add those lists over here. Those are things, keywords are there to make it easier to search. We have maintainers, name, icons and all those things so that it becomes easier for you to post this on some depository. So in summary, charts.yaml contain information about the chart itself. Okay, so now we have two other files. One is deployment.yaml and one is values.yaml. So deployment.yaml are your regular Kubernetes object in which you can have a lot of things like your container name, the image name, the ports and all those things. The good part about Helm is like you can change the values.yaml and then these things would be here. So Helm provides us with templating in which if you want to change some specific thing, we can do that. Suppose right now you want to deploy an IngenX image, then you can just change the IngenX image from here. You don't get the deployment.yaml and change everything from there. It's tiring and it's hard. So Helm provides with a value.yaml file which will help you to change the things as required. Then we have a Helm template. So Helm template is created by those two combined. So whenever you apply a new replica or a new release, so you will see these values are replaced by the ones in the values of.yaml. So the IngenX image is being used right now and we have replica count as one. So our replica is one. So when we are going to deploy Helm chart, this will be the final state of the thing which will be used to deploy. So if you change this thing to two, then the following will be becoming two over here. So as required, you can update the values.yaml without going deep into the deployment.yaml which might be big according to a bigger application with a lot of services in it also. So values.yaml gives you that. So there are a lot more commands. If you want to search some repository, you can use Helm search. If you want to pull some image, so suppose if you want to pull some image from the Helm repository, you can use Helm pull and then Helm install is also there which will help you to install the repository which you have pulled in there and then Helm list is there to find all the charts which is available in your cluster. Artifact is where you can put all of your repositories in it. So it is a way in which you can keep your repositories for people to use that and yeah. So we will just go and check a bit of Helm repositories. So there are a couple of Helm repositories, one of the properties achieved in which you can have a lot more repositories and you can manually deploy the repositories as well also. So if we open the terminal, just taking a bit of time. Okay, so there are some issues with this site I guess. But yeah, that is what today. So yeah, so if you want to get more Helm charts, you can go to Artifact Hub and here you can explore all the Helm charts that is available. So one of the most popular repositories from Bitnami in which you can find Helm charts for Redis Postgres and a lot more images and requirements so that you can deploy your cloud native applications into it, into your cluster. So yeah. Thank you Hrithik for this knowledgeable session. I hope our audience too would agree with me.