Why DevOps Rides on Immutable Infrastructure? The acceptance of “immutable infrastructure” has emerged as a viable way to improve DevOps processes and culture. By introducing standardisation in application deployment and management, the immutable infrastructure helps, among other things, to foster a better collaborative environment among developers, operations, and other stakeholders.
Let’s discuss a bit about Immutable Infra and the benefits which it brings to the table. Once we have a better understanding of it, we’ll really start to see the use case in our Deployments Model.
Our Team hosted a Workshop on Prometheus which was very insightful and made absolute sense in terms of the Principles and the application part. The audience strength was pretty amazing, besides this, we also received many queries from the people who couldn’t join because of the Virtual Meet Limit. So, we shared the recording and the slides on social platforms. Here we try to share a glimpse of the workshop while keeping the same essence.
It was like any other day working on micro-services project, running on Docker environment. In general, we’ve had worked on making our Image Builds more efficient, secure, and faster following basic aspects that significantly affect building and working with Docker.
Understanding Docker layers and structuring the Dockerfile to maximize their efficiency.
Reducing the weight of the Docker image, by being specific about our Base Image Tags which comes up with minimal packages.
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.