Skip to content

Helm Deployment

To start an Helm deployment i.e. hello-world with release test in the namespace playground using adeploy, create the basic repository structure as follows:

mkdir hello-world && cd hello-world
mkdir -p namespaces/playground
touch defaults.yml namespaces/playground/test.yml

Default Variables

Add the Helm Chart repo, the Chart version and default variables to configure the Helm Chart:

defaults.yml
_chart:
  repo_url: https://helm.github.io/examples
  name: hello-world
  version: 0.1.0

The following includes defaults from the Chart's values.yml.

Tip

It is up to you whether to include the defaults as reference, overwrite them to define custom defaults or skip including the variables at all and use the upstream defaults.

defaults.yml
_chart:
  repo_url: https://helm.github.io/examples
  name: hello-world
  version: 0.1.0

# The following are default values from values.yaml of the Helm Chart,
# see https://github.com/helm/examples/blob/main/charts/hello-world/values.yaml.

replicaCount: 1

image:
  repository: nginx
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: ""

nameOverride: ""
fullnameOverride: ""

serviceAccount:
  # Specifies whether a service account should be created
  create: false
  # Annotations to add to the service account
  annotations: {}
  # The name of the service account to use.
  # If not set and create is true, a name is generated using the fullname template
  name: ""

service:
  type: ClusterIP
  port: 80

Namespace/Release Configuration

In the next step, the namespace and the release of the deployment must be defined by creating the namespace/release configuration in namespaces/<namespace>/<release>.yml.

For the namespace playground and release test the configuration look as follows:

namespaces/playground/test.yml
# These are the default values taken from values.yaml.
# You can use the namespace configuration to overwrite them for this namespace:

replicaCount: 1

image:
  repository: nginx
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: ""

nameOverride: ""
fullnameOverride: ""

serviceAccount:
  # Specifies whether a service account should be created
  create: true
  # Annotations to add to the service account
  annotations: {}
  # The name of the service account to use.
  # If not set and create is true, a name is generated using the fullname template
  name: ""

service:
  type: ClusterIP
  port: 80

Note that the namespace/release configuration will be rendered using Jinja. So you can use the variables from defaults.yml, Jinja native macros and filters and the Jinja macros, filters and functions provided by adeploy.

Render

After the Helm Chart configuration consisting of Default Variables and Namespace/Release Configuration has been created, the Helm deployment template can be rendered using adeploy:

adeploy -p helm render .
Example run ...

This will ...

  • download and extract the Helm Chart in build/helm/chars/hello-world
  • create a single Kubernetes manifest file in build/helm/playground/hello-world/test/manifest.yml
  • create the final Helm Chart configuration in build/helm/playground/hello-world/test/values.yml.

Tip

On each render command, the build directory will be generated from scratch. So it is recommended to exclude the build folder from Git.

Test

Using these files, the deployment can now be applied in dry-run using the server strategy. Meaning that the API resources are submitted using server-side requests but not persisted by the API. This can be done as follows:

adeploy -p helm test
Example run ...

As you can see in the example, adeploy will print out all resources that Helm is going to add to your k8s cluster. This gives you a way better control about what is going to be deployed if you run a helm install:

adeploy.Test Testing Helm deployment "playground/hello-world-test" ...
adeploy.Test ... Chart version 0.1.0, app version 1.16.0, last deployed 2024-02-21T12:24:03.762735593+01:00: Dry run complete, status pending-upgrade
adeploy.Test ... Testing raw manifests from "build/helm/playground/hello-world/test/manifest.yml" (may fail) ...
adeploy.Test ...... namespace: playground resource: serviceaccount, name: test-hello-world: configured
adeploy.Test ...... namespace: playground resource: service, name: test-hello-world: configured
adeploy.Test ...... namespace: playground resource: deployment.apps, name: test-hello-world: created
adeploy.Test Testing finished

Deploy

The rendered Helm deployment can be deployed to the cluster as follows:

adeploy -p helm deploy
Example run ...

Note

adeploy will not create namespaces for you, so you still need to manually create i.e. the playground namespace first.

Tip

adpeloy will store the destination cluster of your deployment in ~/.adeploy. If you accidentally have a wrong cluster enabled in your current context, adeploy will warn you accordingly before it continues.

Helm is internally invoked using helm uprade --install, so adeploy -p helm deploy will also cover Helm upgrades.

Have a look at the advanced topics like hooks about how to use adeploy for patching upstream Helm deployments.

Hava a look at the common topic for more adeploy features that can be used in both, Helm chart templates and Jinja deployment templates i.e. to manage labels, secrets, resource limits or to run automated deployment pipelines.