Red Hat OpenShift OpenShift Commons Gathering 2021 Kubecon EU, 4 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Streamlining OpenShift Developer Experience by Building an Enterprise Helm Chart Repository Discover

Description

OpenShift Commons Gathering at Kubecon/EU 2021
May 4th 2021

Title: Streamlining the OpenShift Developer Experience by Building an Enterprise Helm Chart Repository

Speakers:
Sachin Chavda (Discover Financial Services)
Austin Dewey (Red Hat)

Abstract:
Developers have busy schedules when it comes to meeting deadlines. Using OpenShift accelerates delivery, but it takes time out of a developer’s schedule to become proficient, which can put deadlines at risk. To avoid this risk, OpenShift admins within the enterprise must provide a streamlined developer experience. Admins can provide such an experience by building an enterprise Helm chart repository. This repository contains Helm charts that abstract the complexity of deploying applications to OpenShift. The Helm charts do the heavy lifting of configuring OpenShift resources, so all the developer has to do is install the Helm chart using a single command from the Helm CLI. By using Helm charts, the developer experience on OpenShift is streamlined and allows developers to stay focused on meeting their deadlines. In this session, participants will learn how to design and build an enterprise Helm chart repository that will help drive OpenShift adoption within their organization.

https://commons.openshift.org/gatherings/OpenShift_Commons_Gathering_at_Kubecon_EU.html

A

Welcome everybody uh today we're going to be talking about streamlining the openshift developer experience by building a enterprise home chart repository. My name is austin dewey, I'm a senior consultant at red hat. I've been with red hat for about four years, and I've been working with discover for about two on their um openshift uh adoption. uh Sachin. Do you want to introduce yourself.

B

Yeah hi, my name is sachin chava, I'm principal system architect at discord, financial services uh with the discord. I've been working with three years and I just started with the openshift team a year ago and started working on the kubernetes and openshift.

A

Platform all right.

A

All right so, as you are probably aware of openshift, provides many benefits for developers and application teams such as application, auto scaling, self-healing applications.

A

It has an s2y system to enable easy builds within the cluster, there's all kinds of benefits, all kinds of reasons to adopt openshift.

A

But of course, anytime, you move to a new platform, 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 four high-level reasons, one or one is new workflows.

A

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?

A

What is devops so there's all kinds of new terms and phrases to learn there and then new concepts and that kind of goes hand in hand with the lingo. You know concepts around or best practices around containers around deploying applications in openshift, so on and so forth.

A

uh There's many different ways to approach application development on openshift. um You might have asked yourself one 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 the community?

A

How do you know which are the which tools are the right tools for you 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?

A

How are you going to provide reusable components for other teams? There's a lot of different app teams in your organization. You don't want them all to have to reinvent the wheel. You want to provide something for them so that they can hit the ground running sooner. They can become productive in the platform as as soon as possible.

A

Two 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 openshift resources do we need to configure right? If you are familiar with openshift and kubernetes, you know there's a lot of resources. There's deployment services routes.

A

How do you know you're using the proper services for or the proper resources for your use case?

A

So as a member of a openshift 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.

A

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.

A

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 their own. They can use what you've already provided, what you've already tested and vet it out to make them more productive.

A

So our solution that we came up with at discovery is to build an enterprise home chart repository. So you can see a few different helm charts here, image build node.js, so on uh 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.

A

It's it's named that because it's very similar to an operating system package manager, if I say yum, 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 home.

A

I left a couple links there about the project it just received, or it just reached graduated status with the cncf last year, which is very exciting and they have a highly active development community and there's some stats that you can see so helm101 here helm creates a wrapper called charts around ocp resources, and so what you can see here is is a home chart, wrapping around a deployment, a service, a config map and a route, so four common resources that you might need to deploy as openshift application and then a user instead of having to go in and create each of these resources by hand, they can just run one command home install and it's actually going to go and create each of these resources.

A

For them, um a helm 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.

A

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 a 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 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.

A

So you can see you know going back to what I was saying earlier: the number of replicas the image uh resources so on and uh to install that they run one simple command home install and they give it a name. So my app uh point it to the helm chart that they're using um so our spring boot home, chart and then dash dash values. It should be two dashes there values, dot. Yam will start to refer to those parameters, and then there you go.

A

It gives you those resources there without you having actually have written the hundreds of lines of demo to that, you would normally require to to configure those.

A

So uh at this point, I'm going to hand it over to sachin he's going to get more in detail with the dfs home chart repository I'll, stop sharing sachin, and then you can take it away.

B

Thanks austin uh for explaining about the uh and the kubernetes package manager, so at the dfs discord financial services, we have a helm uh chart repository where we are maintaining the charts. Now this helm chart has been maintained by the openshift platform team.

B

The source code for the charts are located in the github. We try to package this chart and archive into the artifactory.

B

We try to maintain the good versioning of the all the changes with respect to the change logs and then uh team can pin to specific version of the chart so that it's not the breaking changes for the application.

B

uh The home charge provides the common set of components for all the application teams and it's open needed towards the you know, uh uh solution to prescribed by the enterprise platform team.

B

So uh we have like a we have built. We started with the building. The image build chart for kind of building. The uh application image is which translate into the openshift build config.

B

Then we have a specific set of deployment chart for each set of technology, uh like a node.js chart for the node.js applications uh springboard chart for the springwood application, and then there's a generic deployment. Chart so this chart is kind of unup muted towards the any language or framework, and then there are set of common templates or body part codes. We are trying to abstract that in the library chart.

B

So the way we have structured, this is if application developer needs to work with the helm cli. They need to install this repository home repository using the helm, repo ad command. Once they add the helm chart repository into their local workstation, uh they can work with the specific helm chart uh and then they can issue the help. Install or update releases uh based on the specific uh iron chart like in this example, is a springboard headshot and then they can provide these set of values.

B

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 10 can utilize those helm chat via the ui open shift. Ui.

B

So running the application on the open shift, there are two high-level steps. One is a build and deploy, so we are targeting uh in terms of the specific helm chart uh for this build and deploy process. So building the application uh 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.

B

The way it works, like uh uh abdel 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 active team, so they will be referring to those 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.

B

Now there are set of flags which they can enable so that the build starts automatically or they can manually trigger the build.

B

So once the build is done, next step will be building creating the artifactory image it will be stored and then now next step is for deployment now based on the technology uh the application is built on, they can use either springboard node.js or generic deployment uncharts. So they'll review the chart documentation.

B

We are providing the examples of the demos uh application so that they can refer those values files and then they can issue the helm, install command with the specific uh technology related handshard like in this example, springboard and deploy those application image to the openshift platform.

B

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.

B

Now, creating an enterprise home chart repository um the specific set of requirements, so uh the code base, so we are maintaining the helm chart code based on the github and uh it follows the specific structure. So in our case, this are a series of hand charts, so we are minting those in the github repo, along with the readme and its pipeline, and then in terms of the storing the helm chart.

B

uh We are using the image registry in this case, if one can use the artifactory nexus and in terms of the image registry for the along with the helm, chart repository.

B

So there are high level design consideration while building the helm chart. uh Consider the user experience design the charge 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.

B

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 help 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 charge properly.

B

So there are no breaking changes if application is using specific version of the chart- and you have upgrading it- you just make sure that your versions are maintained so that it doesn't break the application document. It charts, enter and use.

B

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 content register, urls, enterprise control, image, values wherever is possible and provide the examples, demos of the project, so that community can learn faster and they can utilize those uncharted.

B

uh We can make the head chart uh development easier with the uh library chart like we can abstract the uh common code into library chart so that it can be used by the other charts. So in this example, we are trying to, you know, uh define the library chart which is going to capture the boilerport reusable code, and then we can use that library chart as include in terms of the specific chart.

B

So, for example, if you're building a generic deployment chart, you can include that library chart and also, if you are so building the springboard or node.js. You can include this library chart reference into that and uh for the uh since we are building the han chart. We run through the uh cicd process for the helm chart all as well like there's a ci pipeline, which is a testing packaging and releasing the head shot based on specific version of changes.

B

So we are using the ct tool which is going to uh chart testing tool, which is the assist of steps going to follow. City in it is going to list all the update chart. uh Then city install is going to install the chart, helm packages to package the chart, and then we can push it to the artifactory or repository using the call command.

B

Thank you and let us know if any.

A

A