Motivation:
Yes, it was a demand for our Helm chart to be in a better registry. But why was it needed? Because I wanted the application to be robust, maintainable, and secure.
I had the same question you have in mind; “But Helm is just a package manager, what does the chart have? It is just the skeleton for my Kubernetes orchestration.” The thought changed when we moved to ChartCenter where it provides all the three aspects which I specified above. Let’s see how ChartCenter provides insurance for my Helm steering in the real SaaS ocean.
What is the Actual problem?
Enough of metaphors!. You say I hear it. Let’s see from the core part of my view:
A Helm chart is just a wrapper for the Kubernetes orchestration templates, call it a package manager. But what Kubernetes runs is a Docker container which consists of applications packaged in different formats like JAR, WAR, TAR, etc.
Maintainability:
Apart from the in-house developed application, we might need some applications as dependencies (sub-charts) which need to be running as a container in our Kubernetes cluster. For example, database, monitoring applications, or log shipping solutions such as Postgres, Prometheus, and Fluentd.
The next complex scenario is when one of your own application(s)/chart(s) is used as a dependency in several applications of yours. If it is confusing let’s take this example:
What if you found a major issue in the Base Chart A - Version 1.0 and you want all your sub-charts to use Version 2.0? Imagine the scale of your sub-charts to be hundreds. Thinking of a lookup in the code from each Helm chart? How many years?
This is where the Maintainable part of the ChartCenter helped us to figure out the way easily:
We found easily that our chart is being used by these other charts with their specific sub chart version!. The rich metadata ChartCenter collects and provides in the intuitive UI helps a lot to maintain the dependencies, maintainers, and various details you need to know about a Helm chart.
Security:
So all that said, we mentioned above that we found a major issue in the chart. How did we find it?
As explained, the Helm chart represents application artifacts, containers, and dependency Helm charts. What if the dependency application (for example, a Maven jar file) has a critical security vulnerability? We definitely need a guard.
The security scans in ChartCenter are powered by JFrog XRay.
The scan results under the “Security” tab showed us that one of the dependency charts -> has a docker image which -> has an application with -> a dependency which had the bug. Think how deep the scan is! An example medium severity issue scan is shown here:
The “Used By” tab helped us to find all the charts (within our namespace) that are using the older version of the vulnerable dependency chart version. Sounds so easy, but it has a huge impact because it is SecOps!!
Last but everlasting - Robust:
With all these features, we needed a repository that will be everlasting. With all the SaaS deployments happening frequently, we have hundreds and thousands of Helm deployments undergoing to pull the charts and spin up the applications in our environment. We needed a registry that is robust all the time to not have failures in our deployments. ChartCenter architecture maintains maximum uptime which is crucial for our SaaS workflow.
What if you want to host the chart?
These use cases explained how our Helm charts moved from just a house to a home. Robustness, security, and maintainability are what we needed for our Helm charts, which were served by ChartCenter registry. If you need your chart to have a home, Click on the “Add Chart” button in the ChartCenter UI, or read the inclusion process on Github.
What do you get more?
In addition to hosting your own charts, as a public proxy, ChartCenter provides you a one-stop shop where you can install everything from one source. In fact, you can still access the helm incubator and helm stable charts here and immutability means they will always be available on ChartCenter.
Top comments (2)
Nice article Satheesh!
Thanks for the feedback, Vivek.