We are already storing our images in Docker Hub (https://hub.docker.com/). We could have chosen a different container registry but, since Docker Hub is so convenient, we'll continue using it throughout the book. Even though that might not be the best choice, if we move the discussion about repositories for container images out of the way, we can focus on YAML files or, to be more concrete, Helm Charts.
At this point, you might be thinking that being able to run Charts located on your laptop is an excellent way to go. All you have to do is check out the code of an application hoping that the Chart is there and execute a command like helm upgrade -i go-demo-3 helm/go-demo-3. You'd be correct that's the easiest way to install or upgrade an application that you are developing. However, your application is not the only one you'll be installing.
If you are a developer, you will almost certainly want to run many applications on your laptop. If you need to check whether your app integrates with those developed by your colleagues, you'll want to run theirs as well. You can continue down the same path of checking out their code and installing local Charts. But that already starts being tedious. You'll need to know which repositories they're using and check out more code than you truly need. Wouldn't it be better to install your colleagues' applications in the same way as installing publicly available third-party applications? Wouldn't it be great if you could execute something like helm search my-company-repo/, get the list of all the apps created in your organization, and install those you need?
We are already using the same approach with container images (for example, docker image pull), with Linux packages (apt install vim), and many other packages and distributions. Why not do the same with Helm Charts? Why would we restrict the ability to pull a definition of an application only to those created by third-parties? We should be able to distribute our apps in the same way.
Helm Charts are still very young. The project just started, and there aren't many repositories to choose. Today (June 2018), ChartMuseum (https://github.com/helm/chartmuseum) is one of the few, if not the only one available. So, picking the right solution is very straightforward. When there aren't many choices, the selection process is easy.
In this chapter, we'll explore Helm repositories and how we can leverage them to distribute our Charts across an organization, or even publish them to a broader audience if we are in the business of providing software to the more general public.
As always, we need to start from somewhere, and that is a Kubernetes cluster.