Helm is a package manager for Kubernetes. Helm uses a packaging format called graphics, which includes all the Kubernetes resources needed to deploy an application, such as deployments, services, input, and so on. Helm charts are very useful for installing applications and performing updates on a Kubernetes cluster.
In chapter 3 of my eBook Getting GitOps: A Practical Platform with OpenShift, Argo CD, and Tekton, I discuss the basics of creating and using Helm charts. I also delve into the use case of creating a post-installation and post-upgrade job.
However, that chapter provided a very basic example that focused only on what was needed to create and implement a Helm chart. This article will show you some more advanced techniques for creating a chart that can be installed more than once in the same namespace. It also shows how you could easily install a dependent database with your chart.
The source code for this example can be found in the GitHub repository that accompanies my book.
The
Use Case: How to Install
a Dependent Database with a Helm Chart
Chapter 1 of my book describes the Quarkus-based persona service, a simple REST API service that reads and writes personal data to and from a PostgreSQL database. A Helm chart packages this service and must provide all the dependencies necessary to install it correctly. As discussed in that chapter, you have three options for achieving that goal:
Use the
- corresponding OpenShift template to install
- Postgres CrunchyData operator (or any other operator-defined
- Install a dependent Helm chart, such as the Bitnami PostgreSQL chart, with
the required PostgreSQL database Use the
PostgreSQL database extension) for the database
your chart
However, regardless of which path you take, you also need to make sure that your chart can be installed multiple times in each namespace. So let’s tackle that task first.
Make the chart installable multiple times in the same namespace The most important step in making the
chart installable multiple times in the same namespace
is to use generated names for all manifest files. Therefore, you need an object named Release with the following properties
: Name: The name of the version Namespace: Where to install the chart Hotfix: The revision number for this release (starts at 1 at installation, and each update increments it by one) IsInstall: true if it is an IsUpgrade installation process: true if it is an
upgrade process If you want to ensure that the graph installation will not conflict with any other installation in the same namespace, do the following
: apiVersion: v1 type: ConfigMap metadata: name: {{ .Release.Name }}-config labels: app.kubernetes.io/part-of: {{ .Release.Name }}-chart data: APP_GREETING: |- {{ . Values.config.greeting | default “yes, it’s openshift time” }}
This creates a ConfigMap with the version name, followed by a hyphen, followed by config. Of course, you must now make sure that the implementation is reading ConfigMap accordingly
: – image: “{{ . Values.deployment.image }}:{{ . Values.deployment.version }}” envFrom: – configMapRef: name: {{ .Release.Name }}-config […]
If you are updating all other manifest files in the Helm’s templates folder, you can install the chart multiple times.
$ helm install person-service1 <path to graph> $ helm install person-service2 <path to graph> With
that task out of the way, we can now consider each of the three potential approaches described above in turn
. Install the database through an existing OpenShift template By far the easiest way to install a PostgreSQL database in an OpenShift namespace is by using
an OpenShift template
. We did it several times in my book. The call is simple:
$ oc new-app postgresql-persistent \ -p POSTGRESQL_USER=wanja \ -p POSTGRESQL_PASSWORD=wanja \ -p POSTGRESQL_DATABASE=wanjadb \ -p DATABASE_SERVICE_NAME=wanjaserver
But how could you automate this process? There is no way to execute this call from a Helm chart installation. (Well, you could do it using a pre-installation hook, but that would be pretty ugly.)
Fortunately, the OpenShift client has a function called a process that processes a template. The result of this call is a list of YAML objects that can then be installed on OpenShift.
$ oc process postgresql-persistent -n openshift -o yaml
If you’re piping the result into a new file, you’d get something like this
: apiVersion: v1 kind: List items: – apiVersion: v1 kind: Secret metadata: labels: template: postgresql-persistent-template name: postgresql stringData: database-name: sampledb database-password: KSurRUMyFI2fiVpx database-user: user0U4 – apiVersion: v1 kind: Service […]
If you are not satisfied with the default parameters for the user name, password, and database name, call the process function with the -p option PARAM=VALUE:
$ oc process postgresql-persistent -n openshift -o yaml \ -p POSTGRESQL_USER=wanja \ -p POSTGRESQL_PASSWORD=wanja \ -p POSTGRESQL_DATABASE=wanjadb \ -p DATABASE_SERVICE_NAME=wanjaserver
Place the resulting file in your chart’s templates folder, and it will be used to install the database. If you take a closer look at the file, you can see that you are using DATABASE_SERVICE_NAME as manifest names for your Service, Secret, and DeploymentConfig objects, which would make it impossible to install the resulting graphic more than once in any namespace.
If you are providing the string -p DATABASE_SERVICE_NAME=’pg-{{ .Release.Name }}’ instead of the fixed string wanjaserver, it will be used as the object name for these manifest files. However, if you try to install your Helm chart now, you will get some verification error messages. This is because the oc process generates some top-level state fields that the Helm parser does not understand, so you must delete them.
All you need to do now is connect your personal service deployment to the corresponding DB instance. Just add the following entries to the env section of your Deployment.yaml file: […] env
: – name: DB_host value: pg-{{ .Release.Name }}. {{ . Release.Namespace }}.svc – name: DB_dbname valueFrom: secretKeyRef: name: pg-{{ .Release.Name }} key: database-name – name: DB_user valueFrom: secretKeyRef: name: pg-{{ .Release.Name }} key: database-user – name: DB_password valueFrom: secretKeyRef: name: pg-{{ .Release.Name }} key: database-password […]
Your Helm chart is now ready to be packaged and installed:
$ helm package better-helm/with-templ $ helm upgrade -install ps1 person-service-templ-0.0.10.tgz
Unfortunately, one of the resulting manifest files is a DeploymentConfig, which would only work on Red Hat OpenShift. As a result, this graph cannot be installed on any other Kubernetes distribution. So let’s discuss other options.
Install
a Kubernetes operator with the graph
Another way to install a dependent database with the Helm chart is to search for a Kubernetes operator in OperatorHub. If your cluster already has an Operator Lifecycle Manager (OLM) installed (like all OpenShift clusters), all you need to do is create a subscription that describes your desire to install an operator.
For example, to install the CrunchyData community operator on OpenShift, you would need to create the following file
: apiVersion: operators.coreos.com/v1alpha1 type: Subscription metadata: Name: PostgreSQL-operator namespace: openshift-operators Spec: channel: v5 Name: postgresql source: community-operators sourceNamespace: openshift-marketplace
If you place this file in the crds folder of your Helm chart, Helm takes care of installing the operator before processing the chart template files. Note, however, that Helm will never uninstall custom resource definitions, so the operator will remain in the Kubernetes cluster.
If you place the following file in the chart templates folder, your PostgreSQL DB instance is ready to use
: apiVersion: postgres-operator.crunchydata.com/v1beta1 type: PostgresCluster metadata: name: {{ .Release.Name }}-db labels: app.kubernetes.io/part-of: {{ .Release.Name }}-chart spec: image: registry.developers.crunchydata.com/crunchydata/crunchy-postgres:centos8-13.5-0 postgresVersion: 13 instances: – name: instance1 dataVolumeClaimSpec: accessModes: – “ReadWriteOnce” resources: requests: storage: 1Gi backups: pgbackrest: image: registry.developers.crunchydata.com/crunchydata/crunchy-pgbackrest:centos8-2.36-0 repos: – name: repo1 volume: volumeClaimSpec: accessModes: – “ReadWriteOnce” resources: requests: storage: 1Gi
Of course, you now need to make sure that your personal service can connect to this PostgreSQL instance. Simply add a secretRef to the deployment file with the following content
: […] envFrom: – secretRef: name: {{ .Release.Name }}-db-pguser-{{ .Release.Name }}-db prefix: DB_ […]
This will map all the values from the PostgresCluster secret to your deployment with a DB_ prefix, which is exactly what you need.
Now your chart is ready to be
packaged and can be installed in any OpenShift namespace:
$ helm package with-crds $ helm install ps1 person-service-crd-0.0.10.tgz $ helm uninstall ps1
Install the database by adding
a subgraph dependency
The last option is to use a subgraph within your chart. For this scenario, Helm has a dependency management system that makes it easy for you, as a graphics developer, to use third-party graphics. The following example makes use of Bitnami’s PostgreSQL chart, which you can find on ArtifactHub.
To get started, you need to change the Chart.yaml file to add the external dependency. With the following lines, you can add the dependency to the Bitnami PostgreSQL database with version 11.1.3.
Dependencies: – Name: PostgreSQL Repository: https://charts.bitnami.com/bitnami Version: 11.1.3
If you want to define properties from your values.yaml file, you simply need to use the chart name as the first parameter in the tree; in this case, it’s PostgreSQL. You can then add all the necessary parameters under that key
: postgresql: auth: username: wanja […]
Next, you should take a look at the Bitnami chart documentation to understand how to use it in your target environment (OpenShift, in this case). Unfortunately, at the time of writing, the current documentation is a bit outdated, so you wouldn’t be able to install your chart without digging into the values.yaml file Bitnami provides to see what security settings you need to set to use it with OpenShift’s strong enterprise security.
To save you the trouble, I’ve put together this minimum list of settings you’d need to use
: PostgreSQL: auth: username: wanja password: wanja database: wanjadb primary: podSecurityContext: enabled: false fsGroup: “” containerSecurityContext: enabled: false runAsUser: “auto” readReplicas: podSecurityContext: enabled: false fsGroup: “” containerSecurityContext: enabled: false runAsUser: “auto” volumePermissions: enabled: false securityContext: runAsUser: “auto”
The final step is to make sure that the deployment can connect to this database
. […] env: – name: DB_user value: wanja – name: DB_password valueFrom: secretKeyRef: name: {{ .Release.Name }}-postgresql key: password – name: DB_dbname value: wanjadb – name: DB_host value: {{ .Release.Name }}-postgresql. {{ . Release.Namespace }}.svc […]
Now you need to package your chart. Because it depends on a third-party chart, you should use the -u option, which downloads dependencies into the charts folder of your Helm chart.
$ helm package -u better-helm/with-subchart $ helm install ps1 person-service-sub.0.0.11.tgz
Conclusion Using
Helm charts for your own projects is pretty easy, even if you need to make sure certain dependencies are installed as well. Thanks to Helm’s dependency management, you can easily use subgraphs with your graphs. And thanks to Helm’s flexibility, you can also use a (processed) template or quickly install a Kubernetes operator before proceeding.
See these articles for more information on
Helm: Deploying Helm graphics with
- Jenkins CI/CD on Red Hat OpenShift 4 Deploying
- Java application with Helm
a
And for a deeper look at the example explored here, check out my eBook, Getting GitOps: A Practical Platform with OpenShift, Argo CD and Tekton.
Last updated: January 5, 2023
