We faced quite a few challenges thus far. The good news is that we managed to solve most of them. The bad news is that, in some cases, our solutions felt sub-optimum (politically correct way to say horrible).

We spent a bit of time trying to define Jenkins resources while we were in the Chapter 1, Deploying Stateful Applications at Scale. That was a good exercise that can be characterized as a learning experience, but there's still some work in front of us to make it a truly useful definition. The primary issue with our Jenkins definition is that it is still not automated. We can spin up a master, but we still have to go through the setup wizard manually. Once we're done with the setup, we'd need to install some plugins, and we'd need to change its configuration. Before we go down that road, we might want to explore whether others already did that work for us. If we'd look for, let's say, a Java library that would help us solve a particular problem with our application, we'd probably look for a Maven repository. Maybe there is something similar for Kubernetes applications. Perhaps there is a community-maintained repository with installation solutions for commonly used tools. We'll make it our mission to find such a place.

Another problem we faced was customization of our YAML files. As a minimum, we'll need to specify different image tag every time we deploy a release. In the Chapter 3, Defining Continuous Deployment, we had to use sed to modify definitions before sending them through kubectl to Kube API. While that worked, I'm sure that you'll agree that commands like sed -e "s@:latest@:1.7@g" are not very intuitive. They look and feel awkward.

To make things more complicated, image tags are rarely the only things that change from one deployment to another. We might need to change domains or paths of our Ingress controllers to accommodate the needs of having our applications deployed to different environments (for example, staging and production). The same can be said for the number of replicas and many other things that define what we want to install. Using concatenated sed command can quickly become complicated, and it is not very user-friendly. Sure, we could modify YAML every time we, for example, make a new release. We could also create different definitions for each environment we're planning to use. But, we won't do that. That would only result in duplication and maintenance nightmare. We already have two YAML files for the go-demo-3 application (one for testing and the other for production). If we continue down that route, we might end up with ten, twenty, or even more variations of the same definitions. We might also be forced to change it with every commit of our code so that the tag is always up to date. That road is not the one we'll take. It leads towards a cliff. What we need is a templating mechanism that will allow us to modify definitions before sending them to Kube API.

The last issue we'll try to solve in this chapter is the need to describe our applications and the possible changes others might apply to them before installing them inside a cluster. Truth be told, that is already possible. Anyone can read our YAML files to deduce what constitutes the application. Anyone could take one of our YAML files and modify it to suit their own needs. In some cases that might be challenging even for someone experienced with Kubernetes. However, our primary concern is related to those who are not Kubernetes ninjas. We cannot expect everyone in our organization to spend a year learning Kubernetes only so that they can deploy applications. On the other hand, we do want to provide that ability to everyone. We want to empower everyone. When faced with the need for everyone to use Kubernetes and the fact that not everyone will be a Kubernetes expert, it becomes apparent that we need a more descriptive, easier to customize, and more user-friendly way to discover and deploy applications.

We'll try to tackle those and a few other issues in this chapter. We'll try to find a place where community contributes with definitions of commonly used applications (for example, Jenkins). We'll seek for a templating mechanism that will allow us to customize our applications before installing them. Finally, we'll try to find a way to better document our definitions. We'll try to make it so simple that even those who don't know Kubernetes can safely deploy applications to a cluster. What we need is a Kubernetes equivalent of package managers like apt, yum, apk, Homebrew (https://brew.sh/), or Chocolatey (https://chocolatey.org/), combined with the ability to document our packages in a way that anyone can use them.

I'll save you from searching for a solution and reveal it right away. We'll explore Helm (https://helm.sh/) as the missing piece that will make our deployments customizable and user-friendly.

If we are lucky, it might even turn out to be the solution that will save us from reinventing the wheel with commonly used applications.

Before we proceed, we'll need a cluster. It's time to get our hands dirty.