 And good to have you, Sagar, on DevNation Day India. And Sagar gonna talk about HelmChart Hooks, right? That is going to be an interesting topic. And Sagar is joining us from IBM. He is a developer evangelist and software engineer at IBM, working on a lot of technologies ranging from Java, Kubernetes, and Golang, and Terraform, and a lot of cool stuff he's doing around IBM. So, Sagar. Hey, hi, Karan. Hey, hi, Karan. Hey, everyone. Yeah, I hope you are all doing good and great. It was amazing talk so far. I've logged in since 10 a.m. And I'm enjoying each and every talk. I can see Sagar is live since 10 a.m. And the content is so good that Sagar is not willing to go off. I took a day off today just to attend all the sessions. Oh, fantastic. Yeah. Good, good, Sagar. So, yeah, we are excited. We are super excited to learn about HelmHooks. And by the way, it's a very alien topic to me right now. I have not spent any time on understanding HelmHooks. So I'm pretty sure that this is going to be very informative for me. And for me as well. Thank you. Oh, good. And thanks for the interview. So you can share the screen, Sagar. And you can take it. Welcome to the topic. Sure. I'll be sharing my entire screen. Okay. Yes. It's coming up. Let's start. All yours. Yeah. Yeah. Okay. Thanks, Karen. Thanks once again. And hi, everyone. So today's talk is on the demystifier HelmHooks. And basically, it's a very specific topic, right? And the reason why I choose HelmChart Hooks because it's very underrated, but it's very impactful and useful thing that you can play with HelmCharts, right? Now, before we begin on the HelmChart Hooks, if you guys don't know about HelmChart, basically it's the way to deploy an application into Kubernetes or OpenShift, OpenShift containerized technologies. Before HelmChart, basically we can have an YAML, like let's say we have a front-end application or back-end application which has deployment at YAML or service.yaml. Then typically we can use kubectl apply commands to deploy the application. But the whole orchestration is somewhere missing by using those commands, right? And there are certain things that you cannot do. The very basic thing is you cannot change the parameter at the runtime, right? So for those kind of purposes, HelmChart comes into the picture and it solves that purpose very impactful and you just have to write the chart, the templates and just parameterize it and then you can use it, right? For this particular demo, I have a dedicated repo wherein I have created a HelmChart which will have all these templates for this demo. And if you've gone through that HelmChart, you will definitely learn like how we can parameterize those stuff and all, right? So let's get started. So what is a HelmChart hook, right? So what happens is when you deploy an application, right? There is an application lifecycle which takes place in terms of when the HelmChart works, right? So what happens is it first parses the template, replaces all the variables, then put that YAML into the Kubernetes, then Kubernetes will work on that and the object got created. For example, let's say if I have a pod.yaml and let's say if I run kubectl apply.yaml then what happens behind the scenes? First thing happens is an object called object of kind pod is created in ATCD then a trigger comes into the play then the controller takes over and then it gives a direction to Kubelet and then Kubelet sends a container and then the pod is created, right? So similar kind of lifecycle happens when things works with Helm also, right? So what happens is there are certain use cases wherein you have to do some pre-processing or a post-processing. Let's say if I am deploying a database on a container, right? And when I am upgrading my application, when I am upgrading my database, there are some use cases wherein you have to take backup or you have to restore certain data, right? Or you have to create some data, you have to add some data to your database, right? So those come under the pre-processing and a post-processing, right? So those kind of use cases can be covered using the Helm chart hooks. And in the demo that I am going to show today, I will be covering that part, right? So you will see, like, how practically we can use the Helm chart hooks. Now, how Helm identifies whether it is a hook or not, right? Hook is not, it's not some different object, right? It is similar to any, it can be any Kubelet's object. It can be a pod, it can be a job, it can be a secret, right? But how Helm identifies whether it is a hook or not is just by adding an annotation. So for any Kubelet's object, there is an annotation field within the metadata wherein you can add an annotations to it, right? So if you have this specific annotation in that YAML, right? Then Helm identifies it's an Helm chart hook. Now, next is there are different types of hooks that Helm supports, right? All the hooks are based on a different life cycle of an application deployment, right? So there are different life cycles. We have install, upgrade, delete, rollback and test, right? Test could be a separate use case, but install, delete, upgrade and rollback is a very, it's the main life cycle methods within the Helm chart deployment, right? And for every life cycle method, it supports pre-hook and a post-hook, right? If you count this, then we have total of eight life cycle hooks and one hook is for testing your application deployment. Now, test purpose is specific like, let's say you have deployed an application, do you just wanted to make sure whether your application is working fine or not? You can have a template which will just check whether the pods are running, whether the health APIs are working or not, and that you can specify in the test hook. But the other hooks are life cycle hooks. For example, the example that I've took, right? Before taking an upgrade, I wanted to take a backup because there could be a case where while upgrading my database, I'm adding some data which is not relevant or which is incorrect. Or the upgrade itself got crashed, but I have to take the backup of my data, right? So this can be done by using the pre-upgrade hook. That is, before doing an upgrade, run this particular set of commands to take a backup, right? So this is where we can use the pre-upgrade hooks, right? So in nature, these are the life cycle hooks that Helm supports. You just need to specify the value of it and I'll show in my repository how to specify that, but you just need to specify value in this particular annotation. Now, this isn't very important because this processing isn't temporary stuff, right? Then you have to delete those objects as well, right? So let's say I have a job which will take a backup and the backup will only take place when I upgrade my database, right? But after upgrade is completed successfully, I don't need that job to be present there, right? So there are certain things. So this policy is supported by Helm wherein we can add the deletion policy. And this deletion policy is of three types. First is before hook creation. Second is hook succeeded. Third is hook failed, right? So before hook creation is before Helm applied, applies your hook object within the Kubernetes, it will delete any previous hooks, right? Second thing is hook succeeded. That means when the job is completed, I'll come to that point how you will decide whether the hook is completed or not in the next slide. And third one is the hook failed, right? So this is something you just have to, again, you just need to specify this as part of the annotation which is hook delete policy, right? So the default deletion policy is before hook creation. So if you haven't specify anything in your template, then the default one which will take places before hook creation. This is also important. Now it could be a case wherein you have multiple hooks. Now, again, let's take the same example. Now before upgrade, the one task that I have specified is taken back, right? Now there could be multiple steps. Now one step could be is to send a notification to an admin that the backup has been taken place. And this is the details of a backup, right? So for that also, you have a hook. Now you have to pre-upgrade hooks. Now what are the order? What are the order, right? You have to specify an order because these are the steps of automation. The first step is to take a backup. The second step is to send a notification. So the way it works is Hey, Sagar. Sagar, I think there are some disturbance coming at your side. Can you try to check the headphone jack if that is unplugged? We can hear you but there are some disturbance. It is not. So can you try to say something? Is it better now? It is clear. Yes, thank you. So sorry for that. You can share a screen. Can you let me know how much I lost in between? I think one slide back, that's it. That's it. Apologies for that. You can share a screen. So let me go back to a slide again. We were on this slide Hook's Deletion Policy. Now, as I said before these are the temporary operations or an automation step. Let's say we have a job which will take the backup before an upgrade. If the upgrade completed successfully I want that job to be deleted automatically. I don't need to run a separate command to delete that job. Not to achieve that. To achieve that there are deletion policies that you can specify within the hand chart hook annotations. So there are three deletion policies that hand chart hook supports. First is before hook creation. The name simplifies it. It is like before creating any hook delete the previous hooks. Second one is the hook succeeded. So once the hook executed successfully I'll come to that on the next couple of slides and how we will decide whether the hook succeeded or not. Third one is the hook failed. In second case if the hook got completed successfully the job can delete it automatically. In third case if it got failed you wanted to delete a job. In case of success you don't want it to delete a job. All this you can specify in the annotation itself. If you haven't specified anything in this annotation so the default policy which will take places before hook creation. The next point is also one of the important aspect of it because what happens this is the kind of automation I am trying to achieve via the hand chart hooks. Now the automation it could not be a case where it's a single step automation. There could be multiple steps involved. The first step if we take a same example let's say I have a backup second step is I have to send a notification because how come my admin know this is the backup name this is the backup location this is the steps to restore the backup I have two step automation first step is to take a backup second step is to send a notification to an admin. For that I have two hooks pre-upgrade hooks in place. How to decide an order this is in particular order so to decide an order you can use another annotation which is hook weight and you can specify an integer. 0, 1, 2 specifies that 0 is the first one which will execute it goes from a negative to positive. Any negative most value if you specify that will be first executed and then the value which is greater than that so this is how you can specify the execution order. Now in this particular slide I have mentioned that the hooks get deleted when it is succeeded. Now how can we decide whether the hooks execution got completed successfully and in my earlier slides I have said that hooks is nothing but a Kubernetes object right so in that case if it is a pod or a job and if it is completed successfully then Helm knows that this hook is completed otherwise if it is any other object other than pod and job it will mark it as completed as soon as that is loaded into the Kubernetes loaded as in as soon as that particular object is created into the Kubernetes for example if you it could be a case wherein you can treat secret as a hook it could be a pre-installed hook so that means there could be a case wherein you have to create the random password for a database connection or for authentication and for that purpose also you are using a hook so that could be a pre-installed hook now and that is a secret because you will load all those values into your deployment and pod objects respectively so in that case as soon as that secret is created Helm treats it to be a completed and so now the next piece is the demo and the demo is important because all this thing that we have discussed so far could be easily understood by the demo that I have planned for this particular presentation and so what I am going to do is I have taken an example of a MySQL database as a container so I will deploy a MySQL database in containers and the use case is once the installation is done I will seed the database with some data so for adding the data into database post installation I will use post-installed hook so this is how I will demo you post-installed hook now next thing is I will upgrade my database as I have already taken an example before upgrade I will take a backup so I will use pre-upgrade hook and then what happens so this is an intentional mistake I have done is so after the upgrade I will add some more data in version 2 there is some more data that needs to be added I will add the data now the addition of data I have intentionally made a mistake there that I have added a wrong data so once the upgrade is completed successfully and once the test run after it in test we got to know that there is the upgrade which got added in the upgrade is wrong and then we have to roll back it to the previous release so then we will use helm rollback command to roll back to previous release but then we have to restore the previous data the data that we have the data that we have backed up in the pre-upgrade hook process has to be restored so that for that purpose I will use post-restore hook and then we will install the application and I will also show the use case of a post-delete hook basically in my whole demo as the MySQL database is deployed as a container to persist the data of MySQL I am using the host path as a pvc pvc position volume claim so I have to delete some data because that data will there in my component is node I don't want that data to be there so for that also I am using the post-delete hook so this is how I have structured the demo so that you can understand the install, upgrade rollback and delete scenarios and you can use it as your reference when you are developing something which deals with helm chart hooks so let's switch back to demo hey Karan, I am doing a quick check am I okay with voice so far hello can you guys hear me now Sebi? yeah it's all good am I okay with voice so far so then I will switch to demo part yeah you can switch to demo it's all good yeah thank you okay so before switching to demo what I have done is I have created a repo and it's the dedicated repo which will have which will have all the artifacts it will have the helm chart and the code and also and readme which will have the step by step guide so this readme also contains the presentation images that I have showed and also it has a documentation that you can just follow and you can also run this demo by yourself I will show you the demo so what I have done is I have a kubernetes cluster setup it's a single node kubernetes cluster and there are two terminals so first step that I have showed is I will install an application so I have this so I will just a simple command helm install and the so mysql is the name of the helm release and this mysql is the part where the helm chart resides and before that so when I run this command first first the helm first the all the artifacts got installed and then the post install hook will run so meanwhile it is running let us watch what happens behind the scenes so if you see this is the this is the container which will have mysql running and this is the pod for a post install like why it is failing and why it is why it is erroring out because what I have said is the post what happens is how the hooks work is as soon as the mysql object got created within the kubernetes as soon as the deployment for mysql is created it creates the post install hook but what happens is the mysql container will take its own time and it will complete it because it will run a container it will do all the steps which is required and in that case because as it is a job as it is a job it keeps on trying creating the post install job until it is completed successfully so there is no harm if it is erroring out or not because it is an idempotent process so it will just add the data as soon as it connects to the mysql so if you see previously the state is erroring out then it is container got created and then it is completed and then I have also said the deletion policy so it got deleted now before moving to the next part of demo I will quickly show you the yaml so that you can also correlate this with the demo piece so this this is the mysql helm chart and this is the templates so if you see the template there are certain templates which is specifically for the mysql so the ns.yml, deployment.yml and service.yml specifically for the mysql deployment so these are the standard I will not go into this but what important piece I wanted to show is the yaml for the hooks so let's take an example of post install job so this job is nothing but a Kubernetes job and the way I define it to be a helm chart hook is by using this annotation that I have shown in the slides this is a post install hook so the helm identifies that I have to create this job as soon as I install the mysql and you have also seen that the job pod also got terminated because we have said the deletion policy which is hook-succeeded so as soon as my hook got completed succeeded now how it is succeeded because it got completed so it got completed then it is terminated so these are the two important parameters which is with respect to helm chart hooks and the rest is simple Kubernetes job it depends on you what you have written here so for taking and backup and other stuff I am using this particular docker image which is data back slash mysql backup ok so this is the yaml for a post install job right and let me show you the values of yaml here this is the beauty of a helm chart is you can parameterize all your important parameters within the values of yaml that you can change at the run time right because I have so many parameters that will be changed let's say this post install job is a this post install job is a Kubernetes job right and I have created a custom docker image for it so then I have to provide the name of a image here right and the last one I wanted to show is there are two folders because this post install and post upgrade are the custom jobs that I have written something because I am adding a data here so for this I have a docker file in the script ok now let's switch back to the demo so we have so we have installed mysql let's just verify whether the data in the mysql got present or not ok so the way we are verifying the data is I'll just copy this I'll exec into a pod I'll exec into a pod ok and then I will login with my credentials these credentials are hard coded in the chat you can just verify why the host is mysql because my service name is mysql so I have logged into the mysql console the database name is universe the data that I have created here is the list of the superheroes so these are my favorite superheroes Iron Man, Spider-Man and the Captain America right so this is the data I have added into my database ok so we have verified the post install so I have added my added the data to my database now next thing is we'll we'll upgrade the we'll upgrade the helm release and you will see that there are two jobs which will that will get started running so just helm upgrade the release name and the chat I will not change anything in the helm chat I will just run a simple upgrade so when I run an upgrade you will see that the pre-upgrade hook got created it run it will take a backup it got completed then terminated and then the post upgrade hook got created and terminated right so the pre-upgrade hook created a backup file and it stores into the Kubernetes node itself for that I have created a PVC and then the post upgrade hook is added the data into my database so let's see what data is added into this right so mistakenly bob is added and bob is not bob is not a superhero everyone knows and it's not my superhero as well so bob is added now what should I do next as I know that before upgrade the release that I have used is stable and it has the exact data that I want right so what I'll do is simply rollback the release but in the rollback process I will also restore the data so to restore it I'll just use a command who rollback for every release there is a release number the first release number is 1 after upgrade the release number is 2 now I wanted to go back to release number 1 so I have to specify the release number along with the release name there will be some similar thing happening here as well so when I run a rollback the rollback process will trigger a post restore post rollback job which will restore the data now let's quickly verify the data got restored or not yes so data got restored bob is removed from the database so this is the life cycle thing and when I just I can just remove an application by just running this command and it will uninstall the application ok I'm into pod it will uninstall an application so if I run this command you will see that the pod got terminated successfully right after some time so this is what I wanted to show you as part of a demo the last piece the last slide this one this is the repo link I'll share this with Karan and he will share with you or maybe I can share it in a chat and these are you can connect to me via twitter or LinkedIn I'm happy to connect with you and we can discuss more use cases around Helm chart talks I typically use to do this kind of thing like I use technology and then try to create some use case out of it so Karan can you hear me yeah I can hear you ok we can also hear you so yes it would be great if you can share those links right in the chat so that people who are interested can check it out I'll share the links right away yeah great talk I didn't knew about Helm hooks yeah me neither it's very interesting and I think now I can think about more use cases where we can use Helm hooks exactly I was thinking about it and we also have a deep dive about Helm that we presented yesterday by the way in our team and yeah I'm considering adding maybe a section explaining this because I think it makes sense indeed yes one more question from Shiv Kumar are you using Helm 2 or 3 using using 3 n3 good so you got alright thanks a lot for a great talk great talking ideas are coming to me like maybe we can use it in a very different ways to maybe release new apps as soon as I change the secret because that happens in production a lot right so so fantastic great talk no just an apology for a mic thing other than that thank you so much don't worry thank you guys bye