8 min read

Deploying Helm-Based ACM Applications

In this post, I am going to show how a Helm-based application is deployed in ACM (Advanced Cluster Management).  This application will be mysql.

First, Mysql will be deployed by specifying the Helm repo and chart. This method is based off a tar.gz (tgz) file which is contained on a webserver (see https://helm.sh/docs/topics/chart_repository/).  Within that tgz file are default deployment settings (values.yaml) that will get applied.

Secondly,  I will make a modification to the default deployment settings (values.yaml) to show how a Helm-chart that doesn't use default settings is deployed.  In contrast to the first method, this is deployed via Github.

The default deployment of Mysql will show the Application/Subscription (AppSub) model which is the default in ACM.  For the second example, an ApplicationSet will be used which is based off of Openshift Gitops/ArgoCD.  

In the end, you will see how the AppSub model and ApplicationSet models differ.  Also, you will be prepared to deploy Helm-based apps via ACM that can have deployment settings other than the default ones.

Here are the contents of this article:

A.  Installing Openshift Gitops on Hub Cluster
B.  Integrating Openshift Gitops with ACM
C.  Explanation of Mysql Helm Repo
D.  Deploying AppSub Version of Mysql (default deployment settings)
E.  Deploying Openshift Gitops/ArgoCD Version of Mysql (non-default settings)

The accompanying GitHub Repo is here

GitHub - kcalliga/helm-mysql
Contribute to kcalliga/helm-mysql development by creating an account on GitHub.
GitHubkcalliga

Installing Openshift Gitops Operator on Hub Cluster

  1. In the Openshift Web Console of Hub, go to Operators --> OperatorHub
  2. Search for GitOps and click on the "Red Hat Openshift GitOps" which is provided by Red Hat

3.  Click on "Install"

4.  On the next page, choose latest (1.7.2 as of this writing) and click on Install.

Integrating Openshift Gitops with ACM


These steps will use the default Openshift Gitops ArgoCD implementation.  There is another step involved if you'd like to use another instance of GitopsCluster.  See the following document for that information and anything else related to this.

Section 1.6.8 of the following doc

Chapter 1. Managing applications Red Hat Advanced Cluster Management for Kubernetes 2.7 | Red Hat Customer Portal
Access Red Hat’s knowledge, guidance, and support through your subscription.
Red Hat Customer Portal

My setup has 3 clusters.  There is a hub cluster and a spoke1/spoke2 cluster.

The accompanying YAML definitions based on my setup are in the acmgitops folder of the repo.

The stuff on my repo was mostly taken from the examples at https://github.com/stolostron/multicloud-integrations/tree/main/examples/openshift-gitops

Be sure that all of your clusters have a label called "vendor: openshift" before doing these steps.  This should happen by default.

  1. Create a ManagedClusterSet called all-openshift-clusters.  This will define the OCP clusters that applications can be deployed to using Openshift Gitops/ArgoCD via applicationset YAML definition. 
# Creates a ManagedClusterSet resource
---
apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSet
metadata:
  name: all-openshift-clusters
spec:
  clusterSelector:
    labelSelector: 
      matchLabels:
        vendor: OpenShift
    selectorType: LabelSelector
managedclusterset.yaml
oc apply -f managedclusterset.yaml

2.  Create a ManagedClusterSetBinding which will allow the default instance of Openshift Gitops to manage any cluster that matches the all-openshift-clusters ManagedClusterSet.

# Creates a ManagedClusterSetBinding to the openshift-gitops project
---
apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSetBinding
metadata:
  name: all-openshift-clusters
  namespace: openshift-gitops
spec:
  clusterSet: all-openshift-clusters
managedclustersetbinding.yaml
oc apply -f managedclustersetbinding.yaml

3.  Create a placement which allows you to preselect an already existing placement when creating an ApplicationSet from the ACM GUI.

---
apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: all-openshift-clusters
  namespace: openshift-gitops
spec:
  predicates:
  - requiredClusterSelector:
      labelSelector:
        matchExpressions:
        - key: vendor
          operator: "In"
          values:
          - OpenShift
placement.yaml
oc apply -f placement.yaml

Explanation of Mysql Helm Repo


It is not my intention to do a deep-dive of Helm in this article, but I provide a high-level overview of what is happening as it pertains to this article.  The default documentation at helm.sh is very helpful.

A Helm Chart is based off of a tar.gz file (tgz).  The example contents in the full subdirectory show an example of this.

In the templates subdirectory are templatized YAML definitions files of the objects that will be created on the cluster as a result of this application being deployed in ACM.

These templates use settings defined in the values.yaml file.

The first application (appsub) deployment that we do will be based on the default settings that are contained in the values.yaml (referenced above)

The default setting that will be used in my examples are the resource.request memory setting.

Settings Used from values.yaml

As I mentioned previously, a Helm repo (IE: webserver) needs to be used to house a subdirectory (the chart) which contains an index.yaml file and the tgz file that was shown previously (mysql-1.6.9.tgz)

More information on how the repo is setup is shown here

The Chart Repository Guide
How to create and work with Helm chart repositories.
Helm

Deploying AppSub Version of Mysql


The AppSub example of deploying the Mysql Helm chart will use the main repo (as is) which includes the default settings.  As was mentioned previously, the settings that will be changed later relate to the resource.requests memory setting.  The default is 256Mi of memory.

  1. Create a helm-mysql project/namespace on the hub cluster.
  2. In ACM GUI, go to Applications --> Create Application --> Subscription (also called AppSub)

2.  Define the following:

Name: helm-mysql
Namespace: helm-mysql
Repository Type: Helm
URL: https://charts.helm.sh/stable
Chart Name: mysql
Package Alias: mysql
Package Version: 1.6.9

Deploy only to local cluster.  This will be easier if your environment only has the local (hub) cluster.  Since local-cluster is a member of the ManagedClusterSet we created earlier, it will work.

Creating AppSub Version of Mysql Helm Chart

3.  Once the application is deployed, you will see a summary screen and also the option to go to the "topology" tab.

4.  Here is a view of the resulting topology screen.  Everything is showing green (all the way to the deployment of the pod).

Topology of AppSub Version of Mysql Helm Chart

5.  Click on the "pod" object.

In the resulting window, there is a screen that lets you view details such as name of the pod, the ability to view YAML definition of pod, and to look at the logs of the pod.

Details View of AppSub Version of Mysql Helm Chart

6.  Click on the YAML tab.

Look for resources on the mysql container and see that they are the default values from the tgz file on main helm.sh Repo site.

Default Mysql Settings

7. Let's clean-up .  Go back to main Applications menu and search for "helm-mysql".  Click the 3 dots on the right-side of screen and choose "Delete Application".  Check the box to remove all application resources.

Deploying ApplicationSet Version of Mysql


This version of the Mysql application will be different in a few ways.  

First, I am going to point to a Git repo instead of the base Helm repo.  This Git repo only contains 2 files.  A Chart.yaml which defines the dependency (repo URL, chart name, and version).  Secondly, a values.yaml file which defines only the delta between the values.yaml as contained in the tgz file and how we want to deploy here.  

These two files are contained in the mysql subdirectory

Dependencies Section of Chart.yaml
Values File

This values file will set the mysql container to only use 128 Mi of memory (as opposed to the 256Mi defined in the Helm repo/tgz file).

All other settings based off of the default helm repo/tgz will apply.

  1. In ACM GUI, go to Applications --> Create Application --> ApplicationSet
Creating ApplicationSet

2.  Define the following:

ApplicationSet Name: helm-mysql
Argo Server: openshift-gitops
Requeue Time: 180 (Default)
Repository Type: Git
URL: https://github.com/kcalliga/helm-mysql
Revision Name: main
Path: mysql
Destination-Remote Namespace: helm-mysql

Accept the defaults for sync policy

First Screen of ApplicationSet
Second Screen of ApplicationSet
Third Screen of ApplicationSet

Deploy only to local cluster.  This will be easier if your environment only has the local (hub) cluster.  Since local-cluster is a member of the ManagedClusterSet we created earlier, it will work.

Select New Placement --> ClusterSet (Openshift)
Label Expressions: local-cluster equals true

Hit Submit on the Summary Screen.

3.  View the resulting Topology in ACM and wait for everything to show "Green"

Topology View of ApplicationSet

4.  Let's now look at the ArgoCD view of this same information.

Find the route of the openshift-gitops instance and open it up in your web browser.

It will be something like this:

https://openshift-gitops-server-openshift-gitops.apps.<clustername>.<basedomain>

5.  On the front-screen of Openshift Gitops/ArgoCD you should see the helm-mysql app.

Openshift Gitops View of Mysql ApplicationSet

6.  Click on it to view resulting objects.

ApplicationSet Objects in Openshift Gitops/ArgoCD

7.  Click on the "Pod".  In the top screen there is high-level summary information including events and logs.

Top Screen of Pod

In the bottom screen is the live YAML of the running pod.  If we search this output for the resource.requests memory, we will see that is using the 128Mi value which was defined in the Git repo (not using the default Helm.sh repo value)

Openshift Gitops has a lot of other neat features too like seeing a DIFF between what should be deployed (via Git) versus what is curranty live.

There are many other features of Openshift Gitops as well:

See the following page for more information

https://docs.openshift.com/container-platform/4.11/cicd/gitops/understanding-openshift-gitops.html

I hope you found this article informative.  Thanks for reading.




Keith Calligan