Distributing Kubernetes Applications

Being able to package applications is of no use unless we can distribute them. A Kubernetes application is a combination of one or more container images and YAML files that describe them. If we are to distribute our applications, we need to store both container images and YAML definitions in repositories.

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

Creating a cluster and retrieving its IP

You know the drill. Create a new cluster or reuse the one you dedicated to the exercises.

First, we'll go to the local copy of the vfarcic/k8s-specs repository and make sure that we have the latest revision. Who knows? I might have changed something since you read the last chapter.

All the commands from this chapter are available in the 05-chart-museum.sh (https://gist.github.com/vfarcic/e0657623045b43259fe258a146f05e1a) Gist.

 1  cd k8s-specs
 2
 3  git pull

The requirements for the cluster are now slightly different. We'll need Helm server (tiller). On top of that, if you are a minishift user, you'll need a cluster with 4 GB RAM.

For your convenience, the new Gists and the specs are available.

• docker4mac-helm.sh: Docker for Mac with 3 CPUs, 3 GB RAM, with nginx Ingress, and with tiller (https://gist.github.com/vfarcic...

Using ChartMuseum

Just as Docker Registry (https://docs.docker.com/registry/) is a place where we can publish our container images and make them accessible to others, we can use Chart repository to accomplish similar goals with our Charts.

A Chart repository is a location where packaged Charts can be stored and retrieved. We'll use ChartMuseum for that. There aren't many other solutions to choose. We can say that we picked it because there were no alternatives. That will change soon. I'm sure that Helm Charts will become integrated into general purpose repositories. At the time of this writing (June 2018), Charts are already supported by JFrog's Artifactory (https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories). You could easily build one yourself if you're adventurous.

All you'd need is a way to store index.yaml file that contains...

Using Monocular

I don't think that UIs are useful. We tend to focus on the features they provide, and that distracts us from command line and code. We often get so immersed into filling fields and clicking buttons, that we often forget that the key to automation is to master CLIs and to write code that lives in a code repository. I think that UIs do more damage than good to software engineers.

That being said, I am fully aware that not everyone shares my views. Some like UIs and prefer pretty colors over black and white terminal screens. For those, I will guide you how to get a UI that will utilize Helm repositories and allow you to do some of the things we did through CLI by clicking buttons. We'll explore Monocular (https://github.com/helm/monocular).

Monocular is web-based UI for managing Kubernetes applications packaged as Helm Charts.

It allows us to search and...

What now?

We will continue using ChartMuseum throughout the rest of the book, and I will leave it to you to decide whether Monocular is useful or a waste of computing resources.

We could have set up a container registry, but we didn't. There are too many tools in the market ranging from free solutions like Docker Registry (https://docs.docker.com/registry/) all the way until enterprise products like Docker Trusted Registry (https://docs.docker.com/ee/dtr/) and JFrog' Artifactory (https://www.jfrog.com/confluence/display/RTF/Docker+Registry). The problem is that Docker Registry (free version) is very insecure.

It provides only a very basic authentication. Still, the price is right (it's free). On the other hand, you might opt for one of the commercial solutions and leverage the additional features they provide. Never the less, I felt that for our use-case it is...