 you all in the afternoon session of KCB chain night 2020 day two. In this talk, we will be talking about are you helping in the right way? Quick introduction about myself. This is Precursor. I'm a Solutions Architect at DevTron with more than 11 years of industry experience. Also an active contributor and maintainer of the open source DevTron project on GitHub. You can connect with me on the following social media links on Twitter, GitHub and LinkedIn. Coming to the agenda of today's talk, we'll be talking about what is Helm and some challenges faced by Helm users. And I'll be introducing you to DevTron and how DevTron helps you to overcome those challenges faced by Helm users. Next, I'll also be talking about some other DevTron integrations which will be followed by Q&A. Moving on to the next slide. What is Helm? People in the Q&A ecosystem might already be aware of this term and they might have already used Helm. But people who are new to the Q&A ecosystem, Helm is the most popular package manager for Q&A. Just like you have FIF for Python and NPM and then we have Omri for Mac. Similarly, we have package manager for Q&A, which is called Helm. And this is the most widely used package manager across the Q&A ecosystem. Helm chart is basically a collection of templates which renders some values and generates Q&A manifest. So that gets applied to the cluster. You can package, configure, distribute and deploy applications using Helm chart. It is the most popular distribution channel for open source application that can be deployed on Q&A cluster. And chart repositories is where we post the Helm chart. So there are different chart repositories which are maintained by different maintainers now. So you can just add those repositories when you are using the Helm and you can use the already existing charts over there. And you can also create your own custom charts if you want and deploy your own custom applications. On the left we have a very simplistic representation of how exactly we can work. So we have templates and then we have some values. So the values are, the Helm engine is a templating engine which renders these values to these templates and generates the Q&A manifest which gets applied to the Q&A cluster. Next we will be talking about challenges faced by Helm users. So I will be discussing each of these challenges one by one in the following slides. And we will also be discussing how Defront helps you resolve those challenges. Let's introduce you to Defront. Defront is an open source dual integration platform that integrates with multiple cloud native tools to give you a unified dashboard for a seamless experience. And deploy, observe and monitor all the Q&A microservices deployed in multiple Q&A clusters across multiple cloud providers or even on-premise. Let me give you a quick demo of how you can easily deploy any help chart using Defront. On the left pane you can go to the chart store. You will find me with these charts listed in this chart store. You can also add your own chart repos and it will list all your charts and show it over here. So let me just pick one chart to deploy. I will deploy a big Nami Apache. So on this page it shows all the information about the chart. If there is any existing deployments for that particular chart, it also shows up over here. You can select the chart version I want to deploy and the chart values and then click on deploy. I will give it a name MO4 Apache and select the environment where I want to deploy. So I want to deploy this in Defront MO namespace. I want to save some values. I don't want to provision a load balancer. So I will be changing the service type to plus RILP. And I can refer the review from the left if I want to. For this demo I don't require. I'll just close this down and hit on deploy and voila. That's how you deploy a help chart using Defront. So that has been deployed. You can see that it's creating the resources. It has created a deployment object and then it is creating a pod. So let me check the events of the pod. Okay. I also have an option to take the logs of the pod. The first and foremost challenge that is faced by most of the users which are migrating to Kubernetes or adopting Kubernetes is access management for various team members. And when I talk about the way the team members includes infra, DevOps, and as well as developers. So corner the days when developers used to just test out their code in local environment and commit it to the GitHub repository. They want to do more now. They want to follow the deployment process. They want to see what is happening after the release has happened. They want to actively monitor the application, monitor various mood rates of the application. So it becomes crucial for them to have access of the application that they are owning. So I'll quickly give you a demo of how you can manage access and provide access to all the team members using Deftron PY. Okay. So this is the Deftron PY and under global configuration. So you would find you use that access. So you have an option to like give individual accesses to various users in the organization. Or you can also create various groups for various types of access that you wanted to give and then assign those groups to various users. So I'll just show you how you can create a group and how you can manage the accesses. So I'm going to create a group for which will give users access to a certain namespace, which is the QA namespace. And the users will have the only access to this particular namespace applications. So for that I'll have to project to something that will only come into picture if you're deploying the applications using Deftron. If you're not deploying the application using Deftron, it always lies under an assigned project category. So I can select the environment and namespace that I want to give access to. So environment here is a combination of cluster and namespace. So it shows the cluster name, which in this case is the default cluster right now and Deftron I can demo as the environment. So I want to give access to this particular environment. I can select multiple namespaces as well. And I can also select multiple namespaces across various environments. So if I want to give access to the user for two clusters, I can also do that within this scope. Right now I am just giving access to one namespace and then I'll have option to select application deployed application. So if I want to give access to entire namespace, I can also do that. If I want to give access to only certain applications which are deployed in that particular namespace, I can also do that. In this case, there is no application deployed yet. So it's not showing me populated in this particular case. So I'll just select all applications in this particular namespace and then I'll proceed to the permission level. Deftron currently supports three permissions level for the Helm charts, which are view only, view and edit and admin. So view only, with very only permissions, user will be able to view all the resources that Helm chart has deployed. And we will be able to check the logs of the application, check the metrics of the application. The user with view and edit access will be able, in addition to what new access users can, he will be able to edit the resources of the given manifest and apply it back to the cluster as well. Users with admin access will be able to deploy, edit and view all the resources of that particular within the scope of the application or the environment. So once you have defined the accesses, you can just save this group and then you can go ahead and assign it to any user. If I want to assign it to my users, I can just select it from this dropdown. So right now we have only this group, so I have already selected that and once I've selected it, I can just hit on save and it gives me permissions, all those permissions which you gave to this particular group. Similarly, you can also give group permissions paired with individual permissions as well. So if I have to give one permission to this particular user, let's say the front CD in an in-space and all applications, I should be able to deploy all the applications I'm giving admin access and I'm going to save it. So this is how you can give individual accesses to the users as well. So the next challenge that Helm uses generally faces is that there is no active monitoring of the resources. When I say there's no active monitoring, which means that after the release has happened, if somebody by chance has deleted any of the resources or by any chance there is a pod that gets into crash tube backup, Helm has no way of monitoring that. I'll quickly switch to the demo and show you how Debron helps you actively monitor the resources even after the deployment happens. Okay, I'm back on the Debron UI for a quick demo. So just select one of the applications. So this is one of the Helm chart which has been deployed. This is using Bitnavi Elasticsearch Helm chart to deploy an Elasticsearch stack into a Kubernetes cluster. So right now if you can see the application status of this chart shows as building. So let's see what happens when I delete this pod, the Kibana pod. So as soon as I delete this pod, there is a new pod that gets created because of course it is controlled by the deployment controller. But the status of the application changes to progressing. And when I click on the details, it shows me what resources exactly are in progressing state. If I can see here, it's the deployment which controls the replica set and that controls the pod, which the three are in progressing state right now. Okay, so let's wait for this to get into the healthy set. Meanwhile, I can go ahead and delete any other resource like let's say Ingress. So Ingress, if I delete this Ingress, it is not controlled by any controller. It will not get replaced with a new one. So as soon as I delete the Ingress object, it starts showing as missing and the entire application status also shows missing. And when I click on the details, it shows me exactly what resource is missing, which is the Ingress. Okay, so this is exactly how Teotron actively monitors all the resources of your deployment. The next challenge faced by Ingress is that there is no proper grouping of resources which are deployed by any Helm chart. The Helm chart can create multiple resources ranging between 10 to 50 or even hundreds of resources for some big Helm chart. So when it comes to debugging some issues that you have with any of the deployments, it becomes so very difficult to sort of debug things. So because of no proper grouping of resources, so I'll quickly give you a demo of how Teotron helps you here. All right, I'm back on the Teotron UI. So this chart which has been deployed using Helm, I can see that it has created 38 odd resources. And I can see that all those resources grouped under these categories over here. So under Workloads, I have various boards which are created using deployments. I have stateful sets as well. Then I can see there are endpoints, Ingress, service. The config and storage has config maps versus the volume planes, secrets. And then there are some RBAC objects as well along with the custom resources that it has created. So this is how Teotron shows you all the resources that this particular chart has created, categorized in this particular format. And it's very easy when it comes to debugging because there are any events. So you can check events. You can see the events. I can even see the logs for any of the container of this part. I can do a quick grip. So I can even exit inside the container using the same UI. So I am inside the container in the Kibana port. I can do my debugging activities over here. So that's all you can do. Log analyzer helps you see logs of various resources of your chart deployment. That's also an added benefit to a DevTron that you can see in analyzed logs of various resources right from the UI. So let's suppose that you have a demo set that has 50 pods running. So you don't have to go out for two inch pod and check the logs. You can check the logs of all the pods using log analyzer. Moving on to the next problem by the Helm users is when they are trying to deploy a Helm chart, which has a lot of information in the values file and a lot of parameters that can be configured. So generally what Helm users do is they have the values file open in their web editor and then they are referring to various parameters on the readme of that particular chart's repository. And from there they are referring to parameter and then they are making changes inside the web editor and then they go ahead and deploy it. But DevTron gives you a better way to do that. Let's see how you can do that in DevTron. I am back on the DevTron UI again. So let's go to the values. So if I have to configure some values in this Helm chart, I'll just click the readme on the left side and it opens side by side or readme for me. So if I have to change some parameters over here on the right pane, I'll refer to the parameters and I'll see to the description what it does and I'll name the changes accordingly in the right pane and go ahead and deploy this application with the changes. So that's very handy when it comes to editing long value files like engineering risk controller or maybe Elasticsearch itself has a long value file. So any chart which comes with a lot of resources has a long value files and it really comes handy when you have the reference to the various parameters opened up on the left side while editing those values. Next problem. We have just no unified interface for managing Helm applications across all of your clusters. So you might have multiple clusters, some non-prod, some mini-prod, but there's no unified interface from where you can control all the deployments or monitor all the resources from. So DevTron gives you a way to do that. So I'll go to the global configurations and under clusters I can see that I have two clusters listed over here. You can add multiple Kubernetes clusters. It doesn't matter what version they are or on what cloud they are. It can be on GCP, Azure or even on on-premise cluster can be added to this DevTron instance. And once you add the clusters to your DevTron, you should be able to see all the Helm applications which are deployed in those particular clusters in all the new spaces. You can select the clusters from the dropdown here and it displays all the Helm applications which are present in those two clusters that I have selected. And this is all with the RBAC policies in place. So if the user has access to only one cluster, he will be able to see applications which are deployed in that particular cluster or in a particular new space. If he has access to that particular new space. Now the work support for hibernation of workloads. So with Helm you can either have it installed on your Kubernetes cluster or you can just uninstall which will remove all the Kubernetes objects that it has created including all the workloads. But you may be in a situation that you are doing a long term POC and for which you require some Helm charts to be deployed. They may be resource intensive as well. So and then you might want to pause those POCs for a while to switch on some more priority tasks. So in those cases, what normally you will do is you'll actually remove those resources and re-appear your Kubernetes cluster. But Deftron gives you a better way to tackle that problem. With Deftron you have an option to scale down your workloads so they are not required. As soon as I click on scale workloads it shows these workloads that this particular Helm chart has created. So I can selectively select all the resources that I want to scale down. So I see that these are the most resource intensive workloads. I want to scale down. So I'll just select it. I'll leave Kibana, not that resource intensive and I'll scale all the workloads to zero. So that will scale all the selected workloads to zero. And you can see that all the boards will start terminating and the status will change to partially hibernated. We go see that the boards are not there. If I see there's only one board now, which is the Kibana board and all the other boards have been scaled down. If I want to scale it up anytime I can go to the scale down workloads. I can select the objects that I want to scale, workloads that I want to scale up. I can click on restore workloads and it will just bring up those workloads again. So it helps you save costs on your non-prod clusters when you're doing a lot of VOCs and you might not want to work on a certain chart for a longer duration or maybe over a weekend. So you can do that easily from Deptron UI. Okay, HEM doesn't give you any intuitive way to compare the values file that you have previously deployed. So you can of course do this with some happy ways. You can get the values from HEM get values and then use WEM Dev to compare those values against the changes done. But Deptron gives you a more intuitive way of doing that. It highlights all the changes that were done and you can select the date and time of the deployment that happened in the past and you can compare them to changes against the currently deployed changes in a side-by-side comparison. Okay, so let's talk about some more Deptron features and integrations apart from the HEM plugin that we just saw. So I would show you a quick demo because we have less time for an application. So if you can see, the UI is pretty much the same as it was there in case of the HEM applications. It's just that you see these pretty new tricks over here which shows you CPU usage, memory usage, throughput of the application, the latency of the application. You can also select to show these new tricks on board basis as well since this has two ports. So now it shows you the new tricks on board basis. It also shows if there are any critical vulnerabilities in the image which is deployed. It shows two moderate vulnerabilities and five low vulnerabilities which this image has, nothing critical as such. And then this Deptron integration also comes with SSO login. So you can directly create users and let them log in through their organizations provided by Gmail or Microsoft, or you can even configure GitHub. So here's some information that I would like to share about the Deptron project. You can check out the Deptron repository art, Deptron pipeline labs, you can fork out this repository and also contribute back to the additional project. Deptron is licensed under Apache 2.0, which is the most liberal license in the open source. You can go on this link and join our Discord server. You can even check out the documentation and you can see how you can install your own Deptron cluster either on a local Kubernetes cluster or on a production-grade Kubernetes cluster. There are many organizations which use Deptron for deployments in the production environments. More than thousands of microservices are being deployed using Deptron on daily basis. There are some prominent organizations which are using Deptron as enterprise customers and there are tons of other open source users which are using Deptron for non-prod or production use cases. So the session is open for any question and answers.