Helm is one of the important tools for managing resources for Kubernetes. When we talk about large-scale helm manageability, there is a requirement for another tool through which we can manage helm deployments. There can be multiple options through which we can manage Helm but Ansible gives more flexibility to manage Helm deployments. Not only flexibility, but Ansible consists of many features and core Kubernetes modules through which we can manage Helm deployments.
Having a large variety of Kubernetes core modules, Ansible is not only for Helm deployments but also helps to manage Kubernetes and can be used to manipulate other kinds of commands.
This Blog is not about the basics of helm & Ansible management but about one of the important features which is the validate & dry-run option in Ansible for Helm deployments.
Helm is a stalwart element in the Kubernetes ecosystem. It is a package manager for Kubernetes that helps in application deployment by packaging all resources that are needed for a seamless Kubernetes deployment. Here, we talk about what are helm charts and what benefits they offer.
Helm Charts in Kubernetes
A Helm chart is a collection of YAML template files that are organized into a specific directory structure. Helm Charts are similar to DEB and RPM files. Since they are text-based, helm charts are versionable and simple to maintain using SCM tools.
Bonjour! So we’ve had our minikube cluster up and running and tried setting up MySQL application onto our cluster using publicly available Helm Charts in our previous blog. In case, you haven’t, I suggest you go through the link before reading this blog.
This guide walks us through the process of creating our first-ever chart, explaining what goes inside these packages and the tools we use to develop them. By the end of it we should have an understanding of the advantages of using and creating our Helm Charts to deliver our own applications to the K8s cluster.
Hello everyone! If you are reading this blog, I assume that you have already gone through the first part of my blog. In case, you haven’t, I suggest you to go through the link before reading this blog.
Let’s recall the concept of the first part of this series with some simple principles :
D.R.Y(Don’t Repeat Yourself): Not to repeat the same process of writing and maintaining Kubernetes resources repeatedly for even the simplest of deployments.
Focus on what, not how: Helm is a package manager for Kubernetes that allows developers and operators to more easily, package, configure, and deploy applications and services onto the Kubernetes clusters.
In this part, we will be starting with Helm and will give a kick start so that by the end of this article we will be able to search & use publicly available Helm Charts of various software or application dependencies and install them on our K8s cluster.
Helm Chart Repository: A repository is a place where packaged charts of an application can be collected and shared.
Helm Charts: Helm packages are called charts. It contains all the resource definitions that are necessary to run an application, tool, or service inside a K8s cluster.
Helm Release: A Helm release is an instance of a chart running in a K8s cluster.
Additionally, after adding repo in our local system, we update the repo to get the latest information about charts from the respective chart repositories. And we can list out the repositories added to our system using $ helm repo list as shown above.
Removing added repositories in our system is as easy as adding them.
$ helm repo remove stable.
Once the repository has been added, Helm provides search functionality which gives the ability to search for Helm charts in the various places they can be stored including the Helm Hub and repositories. Here, we will be installing MySQL from the publicly available Helm Chart of the repo which has been added.
$ helm search repo stable
$ helm search repo mysql
As we all know, Helm saves us from writing all K8s resources for a package as it already comes with versioned, pre-configured application resources that can be deployed as one unit. But to see what all resources and environment values are configured for the application, we can check using :
$ helm template stable/mysql
$ helm show values stable/mysql
Now we are all set to install MySQL onto K8’s cluster and take a quick walk-through about Helm Release. To install a new package we use helm install command. At its simplest, it takes two arguments: A release name that we pick and the name of the chart that we want to install.
$ helm install mysqlapp stable/mysql
Additionally, to check the release of all the installed packages use $ helm ls as shown below.
The point of focus is on the Revision of the Release i.e; 1 as shown above. Here, we used the default configuration of the MySQL chart. Needless to say, we’d want to customize the chart with our preferred configuration most of the time and bring a new version of the application release. To achieve this, we simply use $ helm upgrade command. Here we are updating some default environment values of MySQL with our required ones.
To check user-provided values and the upgrade of our release, we can use $ helm get values mysqlapp and $ helm ls commands respectively. Also, here we see the revision value has been changed to 2 as shown above which will keep on incrementing with every upgrade.
And when it is time to uninstall a release from the cluster, we use the helm uninstall command:
$ helm uninstall mysqlapp
Finally, we can say that we are comfortable to get started with Helm and to install our first release using publicly available Helm Charts in our K8s cluster. At this point, we’d like to recommend our readers to install a couple of applications using these public Helm Charts and share their experience in the comment section.
Are you tired of writing and maintaining K8s YAML manifests for all the required Kubernetes object? Or do you feel drowsy for even the simplest of deployments by writing at least 3 YAML manifests with duplicated and hardcoded values?
So don’t worry. Here we are to make your time productive and simplifying the process.