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.
As we promised in our previous blog Prometheus as Scale – Part 1 that in our next blog we will be writing about the implementation part of Cortex with Prometheus, so here we are with our promise. But before going to the implementation part, we would suggest you guys go through our first blog to know the need for it.
Previously we talked that Prometheus is becoming a go-to option for people who want to implement event-based monitoring and alerting. The implementation and management of Prometheus are quite easy. But when we have a large infrastructure to monitor or the infrastructure has started to grow you require to scale monitoring solution as well.
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.
HIPAA stands for Health Insurance Portability and Accountability Act. This act of 1996 is a United States federal statute enactment. It is a series of regulatory standards that outline the lawful use and disclosure of protected health information (PHI). HIPAA compliance is regulated by the Department of Health and Human Services (HHS) and enforced by the Office for Civil Rights (OCR).
But what this ACT has to do with DevOps..? Is it related to the Corona Virus..?
No, not at all..! Let me explain to you how I landed here.