 Welcome everybody. Today, we're going to be talking about streamlining the open shift developer experience by building a enterprise home chart repository. My name is Austin. I'm a senior consultant at red hat. I've been with red hat for about 4 years and I've been working with discover for about 2 on there. Open shift adoption. Uh, Sasha, do you want to introduce yourself? Yeah, hi. My name is Sasha and I'm principal system architect. Discard financial services with a disc or I've been working with 3 years and I just started with the open shift team a year ago and started working on the Kubernetes and open shift platform. All right, all right. So, as you are probably aware of, um, open ship provides many benefits for developers and application teams, such as, um, application, auto scaling, uh, self healing applications, uh, it has a system to enable easy builds within the cluster. There's all kinds of benefits, all kinds of reasons to adopt open shifts. But of course, anytime you move to a new platform, uh, there's going to be. There's going to be some time that it takes to actually ramp up on that platform. It takes time to become proficient on a new platform. Um, there's a lot of reasons. Here's 4 high level reasons. 1, 1 is new workflows, um, you know, new ways of doing things in the platform, new tools to get there, such as the OC CLI, the helm CLI, which we'll learn more about later. Um, there's new lingo, right? What are containers? What is DevOps? Um, so there's all kinds of new terms and phrases to learn there and then a new concepts and that kind of goes hand in hand with the lingo, um, you know, concepts around or best practices around, uh, containers around deploying applications and open shift, um, so on and so forth. Uh, there's many different ways to approach application development on open shift. Um, you might have asked yourself 1 of these questions, or you might have asked yourself all of them, right? Which tools will we use? There's a lot of tools out there in, uh, in the community. Um, how do you know which are the, which tools are the right tools for you? Um, and kind of going off of that, how will you actually build and deploy your application images? Once you kind of have a process in place manually, how are you going to automate that? Now, how are you going to provide reusable components for other teams? There's a lot of different app teams in your organization. Um, you don't want them all to have to reinvent the wheel. Um, you want to provide something for them so that they can hit the ground running sooner. They can become productive on the platform as, as soon as possible. Um, 2 more here, you know, how do people know what they're doing? Is the recommended solution when they're new to the platform? How do they know what they're doing is actually the best practice and what open shift resources do we need to configure? Right? If you are familiar with open shift and Kubernetes, you know, there's a lot of resources. There's deployment services routes. How do you know you're using the proper services for the proper resources for your use case? So, as a member of a open shift operations team or as a member of a DevOps team, we feel that it's, it's your job to provide a set of common tooling and processes for application teams. And by doing that, what you do is you decrease the amount of training and overhead that application teams feel to get acquainted with that environment. Um, you establish a direct and trusted approach maintained by the platform team. When people have questions, they can come to you as, as the subject matter experts as the maintainers of, of their tooling that they use to develop on the platform. You know, like I was saying, they have a centralized location for getting support. Um, they have a set of reusable components. And so that goes back, you know, team to team, you have a set of components that you can distribute throughout there. And then, and out of the box working solution, you know, they don't have to develop this on the loan. They can use what you've already provided. What you've already tested invented out to make them more productive. So our solution that we came up with at discover is to build an enterprise home chart repository. So you can see a few different home charts here, image bill, no, jazz, so on. We'll get to each of these in detail in a little bit. First, I want to talk a little bit about helm, give a little bit of a helm 101 before we dive into the nitty gritty technical details here. So a quick review of helm, helm is known as the Kubernetes package manager. It's named that because it's very similar to an operating system package manager. If I say young install Ansible, I just expect Ansible to be installed on my computer. Helm kind of works in that same way with Kubernetes. And so quick little glance at helm. I left a couple of links there about the project. It just received or it just reached graduated status with the CNCF last year, which is very exciting. They have a highly active development community and there's some stats that you can see. So how I'm, how I'm one of one here, how I'm creates a wrapper called charts around OCP resources. And so what you can see here is is a home chart. Wrapping around a deployment service config map and a route. So for common resources that you might need to deploy as open ship application. And then a user and having to go in and create each of these resources by hand, they can just run one command helm install and it's actually going to go and create each of these resources for them. A home chart is written by a subject matter expert, you know, by a member of your operations team or your DevOps team. And so this is what they would see. And the benefit that they have is that YAML definitions are dynamically generated. So you can see there in red, those are placeholders for parameters. So, you know, the number of replicas that you want in your deployment. The user can specify that the user can specify the image that they want in their container the resources there. So an operator, you know, the human operator would would write this YAML. And then the user would receive the benefit by not having to write all of the YAML there in black. Just the red there would be replaced by their input. So kind of expanding on that users configure their installation using values. So there's kind of an example values file there. So you can see, you know, going back to what I was saying earlier, the number of replicas, the image resources, so on. And to install that, they run one simple command, Helm install, and they give it a name. So my app pointed to the Helm chart that they're using. So our Spring Boot Helm chart and then dash dash values should be two dashes there. Values.YAML, to refer to those parameters. And then there you go. It gives you those resources there without you having to actually have written the hundreds of lines of YAML that you would normally require to configure those. So at this point I'm going to hand it over to Sachin. He's going to get more in detail with DFS Helm chart repository. I'll stop sharing Sachin and then you can take it away. Thanks Sachin for explaining about the Helm and the Kubernetes Package Manager. So at the DFS Discord Financial Services, we have a Helm chart repository where we are maintaining the Helm charts. Now this Helm chart has been maintained by the OpenShift platform team. The source code for the charts are located in the GitHub. We try to package this chart and archive into the Artifactory. We try to maintain the good versioning of all the changes with respect to the change logs and then AppDev team can pin to specific version of the chart so that it's not the breaking changes for that application. The Helm chart provides a common set of components for all the application teams and it's open-ended towards the solutions of Pesky by the Enterprise platform team. So we have like a, we have built, we started with the building the image build chart for kind of building the application image which is transferred into the OpenShift build config. Then we have a specific set of deployment chart for each set of technology, like a Node.js chart for the Node.js applications, Springboard chart for the Springboard application, and then there's a generic deployment chart. So this chart is kind of unaffinated towards the any language or framework. And then there are a set of common templates or boilerplate codes. We are trying to abstract that in the library chart. So the way we have structured this is if application developer needs to work with the Helm CLI, they need to install this repository, Helm repository using the Helm repo add command. Once they add the Helm chart repository into their local workstation, they can work with the specific Helm chart and then they can issue the Helm installer update releases based on the specific Helm chart. Like in this example, the Springboard Helm chart and then they can provide these set of values. Now there's also a way in terms of the OpenShift UI, which we are going to explore it in the future, but this UI provides a nice way to configure the Helm chart and then application team can utilize those Helm chart or the UI, OpenShift UI. So running the application on the OpenShift, there are two highlights steps. One is a build and deploy. So we are targeting in terms of the specific Helm chart for this build and deploy process. So building the application is like building the application image and pushing it to the OpenShift registry. And for deployment, it's going to pull from the OpenShift registry and going to deploy on the OpenShift and create the set of resources on the OpenShift platform. The way it works like, Abdev will be reviewing the image build chart. In our case, it's image build, which is building the image. So it's going to read the documentation and then we are providing the samples for the Abdev team. So there will be different samples trying to clone those values into their local repository and then they're going to issue the Helm install command and that's how it's going to start building the application image. Now there are set of flags which they can enable so that the build starts automatically or they can manually trigger the build. So once the build is done, next step will be a build is creating the artifact image that will be stored and then now next step is for deployment. Now, based on the technology, the application is built on. They can use either Springboard, Node.js or generic deployment and charts. So they'll review the chart documentation. We are providing the examples of the demos application so that they can refer those values files and then they can issue the Helm install command with the specific technology related Helm chart like in this example, Springboard and deploy those application image to the OpenShift platform. So it also works with the grid with the CI CD pipeline. What I explained in the previous two steps is more of the manual way of using the Helm CLI in terms of the for the local workstation. But if they have a Jenkins kind of a pipeline, then they can plug in these two stages like the one is the build stage where they're going to use the image build chart to build the application image. And then it followed by the deploy stage where they're going to deploy the application to the OpenShift platform. Now creating enterprise Helm chart repository. There are specific set of requirements. So the code base. So we are meeting the Helm chart code base in the GitHub and it follows a specific structure. So in our case, there's a series of Helm charts. So we are meeting those in the GitHub repo along with the Readme and its pipeline. And then in terms of the storing the Helm chart, we are using the image registry. In this case, one can use the Artifactory in access in terms of the image registry for the Helm chart repository. So there are highly designed consideration while building the Helm chart. Consider the user experience. Design the charts to require a few values input as possible from the user. So you can abstract some of the values from the user so that user can provide the minimal input in terms of values. You can abstract the service integration as well, like if they are trying to connect to the external service via proxy or database, you can abstract that in terms of the Helm values. And try to design the chart as flexible as possible so that user can provide its custom input as well. In terms of the init container, sidecar container. And you have to make sure that you are versioning the charts properly. So there are no breaking changes. If the application is using specific version of the chart and you are upgrading it, you just make sure that the versions are maintained so that it doesn't break the application. Document each chart's intent use. So it's a clear in terms of usage. If it is a generic chart, make sure that you define the requirement for that. Simplify the internal reference such as container registry URLs and enterprise control image values wherever it's possible. And provide the examples, demos of the project so that community can learn faster and they can utilize those Helm charts. We can make the Helm chart development easier with the library chart like we can abstract the common code into library chart so that it can be used by the other charts. So in this example, we are trying to define the library chart, which is going to capture the boilerplate reusable code. And then we can use that library chart as a include in terms of the specific chart. So for example, if you're building a generic deployment chart, you can include that library chart. And also if you are building the spring boot or Node.js, you can include this library chart reference to that. And for the since we are building the hand chart, we run through the CI CD process for the Helm chart all as well. Like there's a CI pipeline, which is testing, packaging and using the Helm chart patient specific version of changes. So we are using the CT tool, which is going to chart testing tool, which is the assist of steps when to follow city in it is going to list all the update chart. Then city install is going to install the chart and packages to package the chart and then we can push it to the artifact tree or repository using the call command. Thank you. And let us know if any questions.