Managing Container Images and Helm Charts
Docker Hub, one of the most popular public registries for containerized applications, currently offers over five million individual container images. That astounding figure underlines just how important Docker Hub is for hosting container images that developers want to make available to the public.
But despite Docker Hub’s massive popularity, the platform isn’t always the best solution for container image hosting. Some teams need to host container images in a way that keeps them private or (even if they are public) offers more granular levels of access control than Docker Hub supports.
In other cases, organizations may need a solution that can host not just container images but also Helm charts, which are another way to distribute containerized applications to users. Docker Hub doesn’t support Helm charts.
To provide guidance in identifying the best container registry or Helm chart repository solution for your needs, this article walks through key considerations and best practices for managing container images and Helm charts.
What are container images?
Container images are the blueprints that are used to launch an application that runs inside a container. If you have an application that you want to run using a container, you create a container image for it. Then, when you want to run the application (or want to make it available to someone else to run), you download the image to whichever computer is going to host the container and start launching containers based on it.
Container images are sometimes also called Docker images because most of them are designed to run with Docker. Technically speaking, though, Docker is only one of several platforms that supports containers.
Container images are typically hosted inside container registries, which are repositories from which the images can be downloaded. Registries can be public, which means anyone can download images from them, or they can be configured to be private, in which case access is restricted to certain groups.
What are Helm charts?
Helm charts are packages that automatically install and configure software on Kubernetes. They’re managed by Helm, an open source package manager designed to simplify software management for Kubernetes.
In most respects, Helm charts are to Kubernetes what Debian or Yum packages are to Linux, and MSI files are to Windows. They provide all of the information necessary for installing and configuring an application to run in a certain way.
However, Helm charts are a bit different from other types of software packages. They typically don’t include application binaries themselves; instead, they provide instructions that tell Kubernetes where to find the container images that it needs to run a certain application. Another notable feature of Helm charts is that a single chart could install multiple applications. For instance, if you need to deploy a Web server and an accompanying database, you could do it all through just one Helm chart.
Helm charts vs. container images
While container images and Helm charts are both solutions for installing and running containerized applications, there are key differences between them – the biggest is that container images provide just an application (or, in some cases, part of an application), not the configuration data necessary for running it. Downloading a container image is akin to downloading a binary application to your computer (as opposed to downloading a package or installer for the application): You get the application itself, but if you want to run it, you’ll have to configure and launch it manually.
Helm charts are more like a complete software installation package. When you run a Helm chart, it installs not just application binaries, but also all of the configuration data necessary to run an application.
The major limitation of Helm charts is that they work only for installing software on Kubernetes. You can run a container image on Kubernetes, too, but you can also run it anywhere else where you have a compatible container runtime (the application that executes containers) installed.
Best practices for managing Helm charts and container images
The easiest way to make container images and Helm charts available for usage is to host them in a registry or repository from which users can download them. Container registries and Helm chart repositories are akin to an app store: They’re places where people can find a container image or Helm chart for the application they want to run, then download and execute it.
The ability to distribute container images and Helm charts in this way is part of what makes these resources so powerful. It’s easy to integrate them into automated application deployment pipelines, as well as to support a broad set of users, when all of your container images and Helm charts are accessible from a central location.
That said, in order to get the most value out of container image registries and Helm chart repositories, it’s important to manage your images and charts in a way suited to your needs.
Don’t default to public repositories
It can be tempting to store images and charts in public repositories, where they are freely accessible to anyone, and you don’t have to worry about configuring access controls. However, if you are deploying applications that are for internal use only, you should use a private repository that is accessible only by users whom you designate.
And don’t make the mistake of assuming that simply hosting a public repository on a URL that is not public will protect it from unauthorized access. That is a lesson learned the hard way by Vine, whose source code was exposed when someone guessed the URL of its supposedly private container image repository.
Know what’s in your repositories
The Vine story is also a reminder that it’s important to know what data is actually in your repositories. In general, it doesn’t make a lot of sense to store data like source code inside what is supposed to be a container registry. Although in some cases you may wish to store other types of artifacts (meaning any kind of binaries or data) alongside Helm charts and container registries, you should at least keep track of what is stored where in order to avoid security oversights.
Granular access control
Sometimes, you want some container images or Helm charts to be accessible to the public, but others to be private. You might have an open source application to distribute to the world at large, for example, while other images or charts are for proprietary, in-house software. Or, some images might need to be accessible only by one department within your company, while other images are for use by a different department.
In this scenario, it’s beneficial to choose a repository that supports granular access control, allowing you to specify exactly who has which levels of access to each item in the repository.
Version control
Although most users will want to download the latest version of your applications, plenty of situations arise where older versions are necessary. A compatibility issue may prevent the latest version from running in a certain environment, for example, or the latest version may not be fully tested yet. To ensure that your users can always download the exact container image or Helm chart version they need, configure version control in your repository.
Keep images and Helm charts small and discrete
As a general rule, it’s best to provide one container image or Helm chart for each application or microservice that you need to deploy. While it’s possible to combine multiple applications or services into a single image or chart, doing so can lead to bloated packages that are harder to work with.
Part of the beauty of a central repository is that it can efficiently host and manage as many discrete objects as you need. Take advantage of that fact by keeping your images and charts small, even if that means having more of them to manage.
Final thoughts
Container images and Helm charts are valuable tools for simplifying the deployment of containerized software applications. To get the most value out of them, however, you’ll want to host them in a repository that offers the level of access control, version control and manageability that your organization requires.
JFrog Artifactory provides a secure solution that can function as both a Docker image registry and a Helm chart repository. No matter how many images or charts you have to manage, or which types of deployment and installation tools you need to integrate with them, Artifactory offers a flexible way to manage all of the data that drives your team’s software delivery processes.
