DEV Community: Prasanna Raghavendra

Hosting helm charts: A Maintainer’s Perspective

Prasanna Raghavendra — Tue, 07 Jul 2020 02:07:02 +0000

Helm charts is becoming one of the best ways to package any kubernetes application and indeed becoming popular among contributors and contributing companies. It provides a consistent management of any application on kubernetes and a very easy way to override default parameters.

With the release of ChartCenter by JFrog and given that I own hosting JFrog charts, it was important for me to look at this with a finer tooth.

I wanted to take a step back and see who are the providers of chart hosting and hit this nice blog. Let us take this a step further and try to compare them and see how we can leverage these options.

So, here goes my review of these options, against the following 8 criteria.

Host helm repo centrally

We need to ensure that our consumers can download these charts fast and effectively. We will need a way to host on a platform which provides a very good content caching so we are sure that this is available 24*7.

ChartCenter does provide this by running this on a well proven Artifactory, and an operation team who have managed bintray.

The other providers seem to be only working as a directory as they directly provide install commands to the maintainer’s repo. This leads maintainers to take the burden of hosting helm repo effectively, behind CDN.

Clarify chart dependencies

A maintainer would like to ensure that the consumers are clear of the dependencies that the chart has on both sides, where all it is referenced so the consumer can choose a larger chart if needed, and what it references further down, to ensure the consumer is aware of what consumer is picking before he/she installs without having to open the chart.

ChartCenter does provide this effectively.

Did not see them in any other.

Amount of charts hosted

This is important to ensure that as a maintainer you are hosting on a site that is popular and more consumers are on it. It is clear from the numbers (provided in the summary table below), all are in early stages and will surely evolve in the next few months.

Download metrics

Providing information on who is downloading which version of the application is very useful. I found all of them having gaps in this.

While ChartCenter does provide download information, (by of course allowing downloads directly from ChartCenter), it reports by chart version which is not that relevant in the world of applications. It is preferable to have this information by application version and also provide a trend, with download regions, something that was a given in bintray.

Others, being only a portal, cannot provide download functionality and hence no download information.

Related charts

When a consumer comes in a discovery mode, having related content makes a lot of sense to helm the consumer pick the right application.

Artifact Hub provides this well and felt it had relevant charts as well, when I tried wordpress.

ChartCenter, Kubeapps hub and Helm hub seem to be lacking in this area.

Deep curation

Having thoughts and reflection (provided by the host) on charts helps deepen one's understanding on how to compare, install and use applications.

Bitnami (Kubeapps Hub) includes their perspectives in a blog for each chart (of course popular ones). This gives a very good view-point on how one may end up using the chart.
The other three players have not been present in this space.

Make overall usage safe and secure

Having a security report at a chart level provides another nice perspective to know what is going on with the images bundled. This is an area where every chart maintainer is catching up and clearing up their internal security and also working on to depend on the cleanest and latest charts.

ChartCenter is the only one providing this perspective. They are extending this further to allow providers to provide their view-point on some of the open issues. This is an interesting direction ChartCenter has taken and I like this one very much.

Smarter set-me up for better on-boarding

Not all charts are completely independent, especially when you are looking at extension products where you expect some other service is already running, then charts would make a few mandatory values to be filled before getting them working.

Almost all of the providers seem to provide vanilla install commands ignoring some of the mandatory values to be passed, finally leading to a situation where they are actually incorrect.

Summary:

Criteria	HelmHub (CNCF)	Kubeapps Hub (Bitnami)	Artifact hub (OSS)	ChartCenter (JFrog)
Chart hosting	no	no	no	yes
Chart dependency	no	no	no	yes
Deep curation	no	yes	no	no
Chart numbers	Charts: 1355 Versions: NA	Charts: 1400 Versions: NA	Charts: 820 Versions:21k	Charts: 1521 Versions:29k
Download metrics (application level)	No (dependant on hosting)	No (dependant on hosting)	No (dependant on hosting)	Partial
Related charts	no	no	yes	no
Security	no	no	no	yes
Smart installs commands	no	no	no	no

As you can see in the table above, all charts are hosting a limited number of charts, while this ecosystem will start growing. Soon, you will see more and more on-boarding into many of these.

If your requirement is to have a completely hosted support, ChartCenter stands out as the only example. If you want to be aligned with the CNCF ecosystem, you could look at helm hub. If you would like to have a third-party validation along with hosting, Bitnami is a good solution.

However, you could also add ChartCenter for hosting and have the other three list your charts so you have the best of the breed.

Let me know, what do you guys think?

Should the developer in you care about Unified Platform?

Prasanna Raghavendra — Wed, 04 Mar 2020 03:25:20 +0000

There has been a lot of buzz around unification of services to provide a single window for end users to work within our new JFrog Platform. What does this single window look like for developers? This is an important question we asked ourselves when we were building a Unified JFrog Platform. These were the services we saw that needed to be unified to ensure developers and administrators were able to optimize their work.

Unified UI: As a developer, one of the most important features of a binary store is an ability to search the repo to pick the right package for use. We introduced global search, in the unified UI, which can help you search across any packages, get details on the downloads, license information, security issues, and versions available in the package. Especially helpful to developers is a keyword-based search that enables you to dive right into the package you are looking for.
For example, you might perform a complex search for all packages that:
- were uploaded after Feb 1st
- have a high violation severity
- have vulnerability CVE-2019-12
These conditions can be expressed in a simple search string:

after:2020-02-01 cve:CVE-2019-12 severity: high
Unified Configuration. Artifactory alone offers a great many configuration options,. so one might expect that configuring a unified platform will be complex by an order of magnitude. But the reality is that it has become much more simplified. The secret behind this is that all products are each configured through their own system.yaml file that shares the same common structure across the platform. This enables more consistency and re-usability of configuration snippets, streamlining automation of configuration changes. (For a detailed look a the new and shining system.yaml see here
Unified Installation. Our goal was to have all JFrog products install similarly to aid developers in automating installations and upgrading across all products...as if it were one product. This led to more consistency and faster turnaround of fixes. A more depth discussion on this topic can be seen in Vivek Kodira’s article on

Lessons Learned Building JFrog Platform Installers: Applying the Template pattern to Shell Scripts

Vivek Kodira ・ Feb 25 ・ 4 min read

#jfrog #shellscript #designpattern
Unified Folder structure. Extending the principle of common configuration, we adopted a common folder structure for all our products, to allow a clear segregation of immutable and mutable software components. Eldad Assis elaborates in more detail on this topic in

The JFrog Platform - The New File System Layout

Eldad Assis ・ Feb 27 ・ 2 min read
Unified Communication. We also streamlined all the communication across our products and services. This enables net-native architecture to be used even in a standard VM based installation, while allowing cloud native services to leverage net-nativeness of the overall architecture. Introducing router services in the new platform which allowed us to remove redundant code across all products to handle communication, service registrations, SSL services, routing logic, health-check services and meshing of services. More details about this bundled service is here
Unified Naming. We took this opportunity to streamline the names of all the different packages. This enables a simplified continuous upgrade by watching out assets in Bintray. The table below shows the new naming conventions:

Installer type	Artifactory	MC/Xray/Distribution
Linux	jfrog-artifactory-oss-7.0.0-linux.tar.gz	jfrog-xray-3.0.0-linux.tar.gz
Mac	jfrog-artifactory-jcr-7.0.0-darwin.tar.gz	jfrog-mc-4.0.0-darwin.tar.gz
Windows	jfrog-artifactory-pro-7.0.0-windows.zip	Not Available
rpm	jfrog-artifactory-pro-7.0.0.rpm	jfrog-mc-4.0.0-rpm.tar.gz
Debian	jfrog-artifactory-pro-7.0.0.deb	jfrog-xray-3.0.0-deb.tar.gz
Docker Compose	jfrog-artifactory-pro-7.0.0-compose.tar.gz	jfrog-mc-4.0.0-compose.tar.gz

We at JFrog hope you will love these features as much as we did working on them. Keep those feedback coming!

The Saga of `latest` in Container Registries

Prasanna Raghavendra — Wed, 18 Dec 2019 01:34:31 +0000

When you are delivering continuously, it makes sense that you always want to use the latest dependent binaries. Similarly, the testing team would like to use the latest binaries produced for tests. With that being said, it’s important to make it easy for users to pull the latest images from a container registry. I had mentioned this in my earlier blog:

10 Things You Should Expect From a Container Registry

Prasanna Raghavendra ・ Nov 24 '19 ・ 3 min read

#containerregistry #kubernetes #devops #docker

Docker Hub provides a simple tag model where you tag an image as latest and when you pull latest you get that image. This model has inherent issues as discussed in various forums. One example below:

The misunderstood Docker tag: latest | by Marc Campbell | Medium

Marc Campbell ・ Jan 13, 2016 ・ 3 min read
Medium

.
In addition to the issues discussed in the blog, sometimes you may have a version that’s tagged latest in your local repo but that may be old because the remote server built a newer one.

Example:

Prasannas-MacBook-Pro:keys prasannaraghavendra$ docker images
REPOSITORY                                 TAG                                   IMAGE ID            CREATED             SIZE
bintray_kramdown                           latest                                9b919eb86d92        2 months ago        512MB
registry.access.redhat.com/ubi8/ubi-init   latest                                1de7d7b3f531        2 months ago        223MB
registry.access.redhat.com/ubi8/ubi        latest                                11f9dba4d1bc        2 months ago        208MB

As you can see, these are two-month old images but tagged latest. If I run a ‘compose’ or a ‘run’, expecting a ‘latest’, what I end up with is a two-month-old image! In addition, there will be no error anywhere in the process, unless you start looking at the CREATED field above.

There is a certain way to handle this situation - by always deleting latest, but when you do this, you lose bandwidth when you actually have the latest locally.

In addition to this, there are a number of other requirements that can make this more complicated than just getting the latest version of an image from a repo. Let us quickly consider these three examples:

I want the latest of all tested dependencies- I am not just looking at the latest of an image, I also want to pull the latest of the local dependent images that are tested against this image.
I want the latest of released branches- I am looking at the latest released images across all released branches to ensure I can verify a newly discovered vulnerability.
I want the latest of a given branch- I am checking out the latest image in a branch, but then how would I then ensure all my dependencies are pulled from a similar branch or not?

All three examples relate to the necessity for container registries to provide the ability to add metadata and a flexible query construct.

I must say, Both Artifactory and JFrog Container Registry provide this efficiently.

Let’s look at the example of the query below using JFrog CLI:

jfrog rt s "libs-staging/*/*application*.tar.gz"  --limit=1 --sort-by=created --sort-order=desc | jq '.[0].props."dependencies.*"'

The above example pulls from JFrog Container Registry the latest image in staging for application, and parses the list of dependencies that are already marked in the build info [aka metadata]

This is of course just the beginning, you can extend the way you want using the developer in you!

10 Things You Should Expect From a Container Registry

Prasanna Raghavendra — Sun, 24 Nov 2019 14:41:14 +0000

Container registry technology is picking up steam parallel to Microservices Architecture with current Google trends indicating clear growth in this area. While there is no disagreement that a registry is needed, it is clear you need a robust one to deliver your container images to customers effectively. We should level-set what our expectations should be when working with a container registry.

Consumer-Centric: When you create a container image, you definitely need a registry so your consumers can effectively consume both the first version, as well as subsequent versions. With continuous image updates, customers must be notified of the new versions so they can easily pull these new images in an effective and seamless fashion.
Integrated Container Environment: When you are producing images as a way to deliver your software, you need hooks, plugins, and CLIs to ensure your developers can push into a registry from within an IDE, or development environment. Container registries are expected to provide this integration for overall developer productivity.
This requires registries to provide an ability to push or pull images in various kinds of repositories (remote or virtual) and query them with various metadata information, including time-stamp, to ensure they get the exact image they need.
An example would be aql from the JFrog Container Registry, which provides a very deep and flexible way to get your exact image, which can be a small query, in a developmental environment to be consistent with what image you plan to use. Some registries have had issues as simple as getting the latest image consistently from different container registries. Using aql allows us to resolve this issue.
Distribute Fast: The fundamental need for you to push the image here is to ensure it can be accessed globally, with the right versions available, in all the caches provided and in the fastest possible way. Ensuring your registry provides you with enough caching support is critical.
Multi-Cloud: The way to go is cloud-agnostic. You are already multi-cloud, but it is very hard for you to manage these images across these container registries being provided by these clouds. You should consider using providers who are cloud-agnostic and serve you registries that you can install yourself, giving you the flexibility you need to deploy it where you want to.
JFrog Container Registry provides you a downloadable registry to allow you to be cloud-agnostic, while also providing you the flexibility to install in any cloud environment.
Optimization: Storage usage optimization allows for effective storage and provides enough strategies to allow for continuous clearing of development versions, vulnerable versions, and versions not supported anymore.
Support Evolving Standards: Your registry should align with the OCI standards of today, as well as continuously evolving to support the changing standards.
Secure Distribution: Ensure that you never deliver vulnerable software to any of your customers and your registry should always stay on top of the latest vulnerabilities.
Private Repositories: Keeping your binaries separate and private to use them only amongst your partners, either during development or as a standard business practice, is an important expectation from your container registry.
Hosting Multiple Versions Across all of your Microservices Daily: There are significant scaling expectations that need to be met by the container registry, especially with millions, or even billions of downloads. Can the registry scale to these needs?
Control of the Software Flow: Last, but not least, the registry should allow you to always be in control. In particular, with how it operates; deleting older images (be it dev, be it unused, etc), how it provides the insight on the usage, how granular access controls are, or how to turn off and pull back published images that are found to be vulnerable post publishing.

Do you think I missed something, Let me know.

DEV Community: Prasanna Raghavendra

Hosting helm charts: A Maintainer’s Perspective

Host helm repo centrally

Clarify chart dependencies

Amount of charts hosted

Download metrics

Related charts

Deep curation

Make overall usage safe and secure

Smarter set-me up for better on-boarding

Should the developer in you care about Unified Platform?

Lessons Learned Building JFrog Platform Installers: Applying the Template pattern to Shell Scripts

Vivek Kodira ・ Feb 25 ・ 4 min read

The JFrog Platform - The New File System Layout

Eldad Assis ・ Feb 27 ・ 2 min read

The Saga of `latest` in Container Registries

10 Things You Should Expect From a Container Registry

Prasanna Raghavendra ・ Nov 24 '19 ・ 3 min read

The misunderstood Docker tag: latest | by Marc Campbell | Medium

Marc Campbell ・ Jan 13, 2016 ・ 3 min read Medium

10 Things You Should Expect From a Container Registry

Marc Campbell ・ Jan 13, 2016 ・ 3 min read
Medium