Helm
Helm is a package and install manager that standardises and simplifies packaging and deployment of containerized applications with Kubernetes. Unlike Kustomize, which uses a patching approach, Helm uses templating to enable users to tailor the deployed manifests as required.
Exploring Helm
The principles of 'Helm' are as follows:
-
A package manager for Kubernetes with applications packaged as charts
-
Uses templates to enable applications to be configured per installation
-
Parameters for the chart are held in a
values.yamlfile and consumed by the templates
Exploring the Helm CLI
Similar to Kustomize from the previous lab, the helm CLI should have been installed as part of the lab
setup. Verify that it has been installed.
helm version --shortThis should display the version, it should look something like this.
v3.12.1+11.el8+g8cc4ba6Helm as a package manager can be used to install a Helm chart into a kubernetes cluster and can then manage the lifecycle of the application including upgrades and uninstalling the application. However Helm can also render the chart as pure yaml without installing the application in a cluster.
Argo CD follows a philosophy of managing manifests and as a result it interacts with Helm by having Helm templating the chart. It does not install the chart in a Kubernetes cluster. The lifecycle of a Helm chart in Argo CD is managed by updating the version of the chart Argo CD is using and having Argo CD render the new version of the chart.
As a result for the purpose of this workshop we will be focusing on the helm template
command rather than helm install.
Exploring Helm Charts
In this section we will explore the chart that we will be deploying into the cluster using GitOps.
This chart will be used to deploy the same application we did previously with Kustomize. We will work
with a chart in the
documentation/modules/ROOT/examples/bgd-helm-chart directory within the
repository you cloned.
cd ~/openshift-gitops-workshop/content/modules/ROOT/examples/bgd-helm-chartNext if you run the ls command you should see two files: Chart.yaml and values.yaml, as well
as a directory called templates. Let’s have a look at these in more detail.
cat ./chart.yamlapiVersion: v2
name: bgd
description: Blue-Green
type: application
version: 1.0.0
appVersion: 1.16.0This file is the chart definition which specifies name, version and other characteristics of the chart.
cat ./values.yamlreplicas: 1
color: yellow
image:
name: quay.io/rhdevelopers/bgd
tag: "1.0.0"
pullPolicy: IfNotPresentThe values.yaml file is the default set of values that will be used by the chart. When templating or installing the chart
you can provide your own values.yaml to override some or all of these defaults as needed for a specific use case.
Notice that since this is a yaml file parameters can be hierarchical which enables grouping related parameters together as shown
by the image section.
The templates/ directory is where template files reside. When Helm assesses a chart, it processes all files in the templates/ directory using the template rendering engine. The results of these templates are then gathered and forwarded to Kubernetes.You can learn more about templating here.
Helm Template
In this section, we will explore how to use the helm template command to generate Kubernetes manifests from a Helm chart. This command is a fundamental tool for understanding how Helm charts work and for visualising the resources they create.
Step 1: Run the Helm template Command
Execute the following command to render the chart template from your local directory and display the output on the screen:
helm template bgd ~/openshift-gitops-workshop/content/modules/ROOT/examples/bgd-helm-chartStep 2: View the Output
After running the command, you will see the output of the helm template command, which represents the generated Kubernetes manifest files. Below is an example of what you can expect to see:
You will see the output of the helm template:
apiVersion: v1
kind: Service
metadata:
labels:
app: bgd
name: bgd
spec:
ports:
- port: 8080
protocol: TCP
targetPort: 8080
selector:
app: bgd
---
# Source: bgd/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: bgd
name: bgd
spec:
replicas: 1
selector:
matchLabels:
app: bgd
strategy: {}
template:
metadata:
labels:
app: bgd
spec:
containers:
- image: quay.io/rhdevelopers/bgd:1.0.0
imagePullPolicy: IfNotPresent
name: bgd
env:
- name: COLOR
value: yellow
resources: {}
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
securityContext:
runAsNonRoot: true
seccompProfile:
type: RuntimeDefault
---
# Source: bgd/templates/route.yaml
apiVersion: route.openshift.io/v1
kind: Route
metadata:
labels:
app: bgd
name: bgd
spec:
port:
targetPort: 8080
to:
kind: Service
name: bgd
weight: 100Using Helm charts to deploy applications in Argo CD
In this section, we will utilise Helm charts to deploy applications within Argo CD. Helm charts provide a convenient way to manage and deploy Kubernetes applications. We will first examine the configuration file for an Argo CD Application that deploys a Helm chart for the BGD app. This file contains essential configuration details such as the destination, source, project, and sync policy.
Step 1: View the Argo CD Application Configuration
To view the YAML configuration file for the Argo CD Application, execute the following command:
cat ~/openshift-gitops-workshop/content/modules/ROOT/examples/bgd-app-helm.yamlYou should see the following output:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: bgd-helm
spec:
destination:
namespace: $USER-bgdh
server: 'https://kubernetes.default.svc'
source:
path: documentation/modules/ROOT/examples/bgd-helm-chart
repoURL: 'https://github.com/OpenShiftDemos/openshift-gitops-workshop'
targetRevision: master
sources: []
project: default
syncPolicy:
automated:
prune: true
selfHeal: trueThis YAML configuration defines an Argo CD Application named "bgd-helm" that deploys a Helm chart from a specific Git repository to the "USER_PLACEHOLDER-bgdh" namespace.
Step 2: Deploy/Observe the Argo CD Application
Apply the configuration in the file to create the Argo CD Application in the namespace USER_PLACEHOLDER-argocd. This application will deploy the Helm chart for the BGD app:
sed 's/$USER/USER_PLACEHOLDER/' ~/openshift-gitops-workshop/content/modules/ROOT/examples/bgd-app-helm.yaml | oc apply -n USER_PLACEHOLDER-argocd -f -In the ArgoCD interface you should see the successful deployment of the "bgd-helm" application.
Now click on the "bgd-helm" application. We will explore its deployment. You can tell by the icon that it’s deployed via a Helm chart from a Git repository. Although you could deploy it through a Helm repository, we’re using a Git repository for this demonstration.
Access the application details by clicking on the "App Details" option.
Next, click on "Parameters." You will notice that there is no separate values file as the application is deployed directly from the Helm chart. However, it has automatically retrieved the following values:
If you view the route of your application you should be able to see the animated balls are now yellow!
You can see the link by using this command:
oc get route bgd-helm -n USER_PLACEHOLDER-bgdh -o jsonpath='{"http://"}{.spec.host}{"\n"}'
Custom values files
In this section we explore the use of custom values files with Helm charts. These allow you to tailor deployments to your specific needs. Custom values files offer the flexibility to override default settings without modifying the chart directly.
Step 1: Explore the Custom Values Configuration
Begin by examining a YAML file named "bgd-app-helm-custom.yaml." This file closely resembles the previous configuration but introduces a critical difference: it references a custom values file stored in the same Git repository as the Helm chart.
cat ~/openshift-gitops-workshop/content/modules/ROOT/examples/bgd-app-helm-custom.yamlYou will notice a section in this YAML file that defines the name and path of the custom values file responsible for adjusting the Helm chart’s default settings:
helm:
valueFiles:
- custom_values_1/values.yamlThis configuration specifies how Helm accesses and uses the custom values file to modify the Helm chart’s behaviour.
Step 2: Explore the Custom Values File
Examine the custom values file that is being referenced:
cat ~/openshift-gitops-workshop/content/modules/ROOT/examples/bgd-helm-chart/custom_values_1/values.yamlYou should see that it transforms the color of the animated balls from yellow to green, among other settings:
replicas: 1
color: green
image:
name: quay.io/rhdevelopers/bgd
tag: "1.0.0"
pullPolicy: IfNotPresentStep 3: Apply the Custom Values
Now, apply the custom values file to the initial application using Argo CD:
sed 's/$USER/USER_PLACEHOLDER/' ~/openshift-gitops-workshop/content/modules/ROOT/examples/bgd-app-helm-custom.yaml | oc apply -n USER_PLACEHOLDER-argocd -f -Step 4: Verify the Changes
Return to ArgoCD and click on "App Details," then navigate to the "Parameters" section, where you previously made changes. You’ll notice that the custom value file has been successfully added, and it has updated the values to display the animated balls in green.
Using ArgoCD to deploy a Helm chart with custom values files offers the advantage of tailoring and overriding the chart’s default settings, all without needing to alter the chart directly. This flexibility enables you to deploy the chart with different configurations to suit various environments or specific use cases.
Argo CD Application with Parameter Values
In this section, we’ll explore a YAML file where parameter values are embedded directly within the Application, eliminating the need for separate values files.
Step 1: Examine the Parameterised Configuration
Begin by examining the YAML file named "bgd-app-helm-para.yaml." This file, similar to the previous configurations, defines an Argo CD Application for deploying a Helm chart. However, a notable difference is the inclusion of all desired parameter values directly within the YAML file:
cat ~/openshift-gitops-workshop/content/modules/ROOT/examples/bgd-app-helm-para.yamlapiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: bgd-helm
spec:
destination:
namespace: $USER-bgdh
server: 'https://kubernetes.default.svc'
source:
path: documentation/modules/ROOT/examples/bgd-helm-chart
repoURL: 'https://github.com/OpenShiftDemos/openshift-gitops-workshop'
targetRevision: master
helm:
parameters:
- name: color
value: purple
- name: image.name
value: quay.io/rhdevelopers/bgd
- name: image.pullPolicy
value: IfNotPresent
- name: image.tag
value: 1.0.0
- name: replicas
value: '1'
sources: []
project: default
syncPolicy:
automated:
prune: true
selfHeal: trueIn the 'parameters' section of the YAML, you will notice that we have included all the desired values, such as the color, image name, image pull policy, image tag, and the number of replicas.
This approach allows us to apply these settings directly to Argo CD without relying on external values files. For this example we’ve changed the color to purple.
Step 2: Apply the Parameterised Configuration
Apply this parameterised configuration to Argo CD:
sed 's/$USER/USER_PLACEHOLDER/' ~/openshift-gitops-workshop/content/modules/ROOT/examples/bgd-app-helm-para.yaml | oc apply -n USER_PLACEHOLDER-argocd -f -Return to the ArgoCD interface and navigate to the 'App Details' section. Click on 'Parameters.' You will notice that the custom values file, which was present in the previous example, has been successfully removed from the ArgoCD Application.
Deploying a Helm chart through ArgoCD with integrated parameters allows you to customise default settings without modifying the chart itself or relying on external values files. This centralises configuration management across different environments.
Step 3: Confirm the Application
Access the route again, and you should now see the application in purple. Use the following command to view the application:
oc get route bgd-helm -n USER_PLACEHOLDER-bgdh -o jsonpath='{"http://"}{.spec.host}{"\n"}'
Conclusion: Helm on ArgoCD
In this module we learned how to deploy Helm charts using Argo CD and we looked at the different ways in Argo CD to pass parameters to the Helm chart. A brief summary of the Pros and Cons of the approaches we examined can be summarised as follows:
Custom Values File - Pros |
Built-in Parameters - Pros |
Customise Configurations:Create a separate values.yaml file to tailor configurations for different environments. Override default values in the chart’s values.yaml file with your specific settings. |
Environment-specific YAML: Manage YAML configurations for each environment using branches or tags. |
Rapid Modification: External values files provide an advantage over managing multiple Helm charts with individual values. Facilitates quick modification of multiple values through a single file change. |
No reliance on external values files makes local testing and debugging with |
Custom Values File - Cons |
Built-in Parameters - Cons |
Manual Updates: Requires manual updates to the values file, deviating from the default Helm charts behaviour. |
Customisation Limitations: Limited customisation options due to YAML file constraints. |
Potential for errors or inconsistencies if the values file and chart configurations do not align. |
Necessitates a separate chart for each environment, potentially leading to redundancy. |
You can read more about the patterns for deploying Helm charts with Argo CD here.
In conclusion, this module introduced Helm as a Kubernetes package manager with templating capabilities. We explored its usage in ArgoCD, focusing on rendering Helm charts as pure YAML and customising deployments with custom values and parameter values for flexible configuration management. This approach streamlines the deployment process and enables customised configurations without altering the Helm chart directly.