This is the first of many posts highlighting GitOps topics that we’ll be exploring. Within this post, we will discover Helm, a tool used for Kubernetes package management, that also provides templating. Helm provides utilities that assist Kubernetes application deployment.
In order to better understand how Helm charts are mapped to Kubernetes manifests, we’ll elaborate more details below and how to use Helm with and without GitOps.
What is Kubernetes?
Kubernetes is an orchestrator for containers that allows you to automate scheduling, deployments, networking, scaling, and health monitoring for the containers.
Kubernetes was desired because we increased the utilization of the following:
This was difficult to handle with scripts and self-made tools and caused the need for orchestration technology like Kubernetes. It provides features like scalability, disaster restoration, and less downtime.
What is Helm?
Helm is a package supervisor for Kubernetes. It’s a handy way for packaging collections of YAML files with a Helm chart for the Kubernetes application and allowing distribution with a Helm repository.
Maintaining Kubernetes manifests is time-consuming and tedious and this is why Helm is helpful!
Helm Charts are deployable units for Kubernetes applications. These charts are a collection of files inside a directory. This directory is the name of the Helm chart and consists of a self-descriptor file, YAML file, and 1 or more Kubernetes manifests. Helm charts are typically written in the Go template language. Charts are created as such files, describing a related set of Kubernetes sources. Here’s an example of a Helm chart directory and it’s format:
This particular directory contains a Chart.yaml file and this is where the global variables, versions, and descriptions are stored. Then, the templates directory is what contains the YAML files for Kubernetes, otherwise known as the Kubernetes manifests.
Files such as the deployment, service, and ingress files contain variables from the values.yaml file when the chart is deployed. The _helpers.tpl incorporates helpful functions for variable calculations.
You can then share the Helm chart to increase easy reusability for others to use. Sharing is done by storing the chart to a Helm repository. This repository can then be shared with others to deploy the application with the chart.
Helm helps a chart repository service that can be used to store the Helm charts. You can use any web server host or source code host for the Helm repository.
The repository has an index.yaml file that contains metadata about the package, including the Chart.yaml file. The index will contain information about each Helm chart in the chart repository. Then the server can serve your index and charts or the packages can be stored in the repository for shareable entry.
Each install or upgrade will create a Helm release. A Helm release is a operating instance of your Helm chart operating inside a Kubernetes cluster or a namespace. It’s essentially an instance of a versioned, templated chart. It’s also possible to have multiple releases of the same chart in a single cluster or namespace since the chart is self-contained. You can also roll back a Helm release to a previous version in case there are any failures.
Assuming you’re a developer with an existing cluster, perhaps you’d like to share your Helm application with an external vendor. Let’s recap the Helm workflow and release process:
- To share an application with others, you need to create a Helm chart. The chart is a package that contains templates for a set of sources necessary for the application. The template uses variables utilized to the Values.yaml file when the manifest is created and describes how to configure the sources.
- The Helm charts are then hosted inside a repository that can then be downloaded or accessed from a server. This chart will contain all the necessary resource definitions desired for the developer to run an application.
- Now that you have entry to the cluster, you can add new features or bug fixes to the application and update the Helm chart. Helm offers useful tools to handle your releases. You can upgrade the chart and create a new deployment. In Helm a deployed instance of your application is referred to as the release.
- You can now deploy your packaged application to the cluster.
Within this workflow we identified how Helm packages files and deploys them to a cluster. So, how do you apply GitOps to the workflow above? Let’s discover this below…
What is GitOps?
GitOps is a paradigm that incorporates best practices utilized to the application development workflow all the way to the operating infrastructure of a system.
Some benefits of GitOps are:
- Deploying faster and more often
- Easier and quicker error handling and restoration
- Self documenting deployments
- Increased developer productiveness and an enhanced experience for teams
- Greater visibility on the lifecycle of developed features
These benefits make it simpler to handle the applications and allow teams to deliver quality software faster.
GitOps depends on Git as the single source of truth for declarative configuration and lively reconciliation. By adopting the GitOps methodology it provides transparency between the application configuration deployed in a cluster and the 1 residing in Git.
A GitOps tool that follows this approach of a Git-based workflow is Argo CD. It’s a continuous delivery tool for Kubernetes that is essentially a GitOps controller that does 2-way synchronization. Argo continuously monitors operating applications and compares the live state against the desired state in Git and applies it to the cluster. In addition, it also monitors the container registry for new images and updates the workload definitions based on the deployment policies.
We will mention Argo CD again in this post and can assume that it’s already been installed and implemented inside our workflow!
GitOps works with all of your existing tools
Now that you have a fine understanding of what Helm is and it’s capabilities, perhaps you’ve considered applying GitOps to your existing or prospective applications.
Let’s discover the various approaches of how to use GitOps with or without Helm:
- Using only Helm (without GitOps)
- Using GitOps (without Helm)
- Using Helm with GitOps
If you’d like to discover these different approaches from a code-base perspective, here is an example project that you should check out on GitHub that digs deeper into how you can:
- Install an application with Helm and deploy regionally
- Install an application with Argo CD and deploy regionally both inside the UI and command line
If not, then we’ll be sure to highlight these approaches below!
Approach #1: Using only Helm without GitOps
If you want to use Helm but your organization isn’t quite ready to implement the GitOps workflow, that’s perfectly fine. Helm was created before the GitOps methodology came to fruition, but can nonetheless work with GitOps (as we will see in the latter point).
The workflow allows you to search through Helm repositories for charts and install them to clusters, creating releases. This process enables execution of application deployments on a cluster. The maintenance of YAML manifests for Kubernetes objects is nonetheless the same as before. Helm releases are what retains track of the version history of each chart installation and change and nonetheless allows rolling back to the previous cluster version. When installing a chart it creates a release of the new package and it’s the Helm release that deploys the Helm application.
When using Helm there are some powerful instructions you will find useful, please see below.
To install a new package:
helm install <release_name> <name_of_chart_you_want_to_install>
To view currently deployed releases:
To view revision numbers for a particular release:
helm history <release_name>
To learn more details about these instructions and how to use them, reference the example project in GitHub.
Approach #2: Using GitOps without Helm
If you’re bought on the thought of GitOps, there are alternative tools that can be used if you’re unable to use Helm or choose not to.
You can use ArgoCD on its own. It is pretty flexible and can work with other templating solutions or even plain manifests. Another templating tool that can be used instead of Helm is Kustomize. This tool is constructed into
kubectl and is native to Kubernetes. It allows you to customise Kubernetes configurations using only the Kubernetes API resource files.
Now, let’s discover our third approach about how to implement GitOps using Helm and Argo CD…
Approach #3: Using Helm with GitOps
Now that you’ve seen how GitOps can be utilized without Helm, let’s discover how you can use it with Helm.
First, the Helm chart and any application changes should be dedicated in Git prior to being utilized to the cluster. Meaning all of your workload definitions in a YAML format, the Helm charts, and any other Kubernetes custom sources that define the cluster’s desired state should be dedicated to the repo. This way rollbacks and logs are accessible and the state of manufacturing can be restored easily.
Within Argo CD you can connect the Git repository using HTTPS and add the URL immediately. This then allows you to enable auto-synchronization to routinely synchronize the cluster to the desired state in the Git repository. Once synced successfully, the application status is recognized as Healthy. Otherwise, if the application is OutOfSync, you can rollback or view the release history to resolve the issue.
Here’s an example of a Healthy application in the Argo CD UI.
When the application is operating you can view its resource components, logs, events, and the health status.
For fine measure, here’s a visible of the Argo CD UI exemplifying an OutOfSync application when the live state deviates from the goal state.
If your application had an error or was OutOfSync like the example above, you could execute the argo history command that allows you to view the application deployment history:
argocd app history <argocd_app_name>
Then, if you need to rollback the deployment you can do so by executing this command:
argocd app rollback <argocd_app_name> <history_id>
Essentially, these instructions leverage a faster and more secure deployment, by enabling the monitoring from the Git repository. It also allows you to track the lively Kubernetes sources and events.
Therefore, using source control like this is what classifies this application deployment as GitOps!
Something necessary to note is that Argo CD provides native support for Helm, meaning you can immediately connect a packaged Helm chart and Argo CD will monitor it for new versions. When this takes place the Helm chart will no longer function as a Helm chart and instead, is rendered with the Helm template when Argo is installed, using the Argo CD application manifest.
Argo CD then deploys and monitors the application components until both states are identical. The application is no longer a Helm application and is now recognized as an Argo app and can only operate by Argo CD. Hence if you execute the helm list command, you should no longer be able to view your helm release because the Helm metadata no longer exists.
Here’s an example of the command output. As you can see, the Argo CD application is NOT detected as a Helm application.
Helm is a powerful tool that is used often with Kubernetes deployments and provides monitoring for each release. This helps ensure reliable and quick deployments for development teams.
So, if you’re completely new to Helm, I suggest referring to our documentation to learn more about it, here:
We’ll discuss additional tools in our next post that can help you and your team proceed implementing a GitOps process to your development and infrastructure systems.