Helm variable substitution

Advice
1

Hi

I’ve been trying to get a helm value to resolve in single quotations when using the explicit key section. I’ve tried different pipes but with no luck, any advice on this would be greatly appreciated

The desired outcome
image

My current outcome
image

3

Hi @shaun.a.havelaar

As noted in this StackOverflow marked answer there is a few ways to achieve this with helm charts. You can either double-up the quotations, use a backslash to escape it, or try using a block scalar. The block scalar in particular does not need any extra escaping.

annotation: '''"ports": {"88":"sandbox-backendconfig"}}'''
annotation: "'\"ports\": {\"88\":\"sandbox-backendconfig\"}}'"
annotation: >-
  '"ports": {"88":"sandbox-backendconfig"}}'

I hope this helps. Let me know if any of these don’t work.

Kind Regards
Sean

5

Hi @sean.stanway

Thanks for the answer, with a simple case like this it would make sense to do it like that.

I’m finding very little documentation regarding more advanced variable substitution use cases, maybe I’m just not looking in the right places. I have a straightforward replacement that I need to do with a yaml sequence but I can’t get it to resolve correctly.

service:
  ports:
  - name: http
    port: 80
    targetPort: 8080
  - name: https
    port: 443
    targetPort: 8443

I just need to substitute the first sequence value, I thought it would be as simple as service.ports[0].targetPort = 8080

It would be very simple if this step had structured configuration variables but it’s unfortunately not in the helm upgrade step as of yet.

6

Hi @shaun.a.havelaar

Unfortunately with how the helm step works, the best way to sort this out would be to migrate your helm operations to a Run a Script step. We did have this raised once this week via our engineering team, so I’ll re-raised this to ask when we’re going to update the helm step to use the standard operations our other script does.

I would expect what you’ve put there in as an example would have worked from my previous experience, but I would gather this might not be how the step (or Helm) operates.

I did find one potential fix, which is to use a values file, but I’m not sure if this will suit your needs since it looks like you want it to resolve this value on deployment time.

As I mentioned above, I’ll re-raise this with our engineers and see if we can get the ball rolling on upgrading the helm step.

Kind Regards

1 Like
8

Thanks @sean.stanway I appreciate it. Just as a reference I added a temporary fix for this by just passing the --set as an additional argument. It’s not pretty but it works until I have a better solution.

Thanks for the help

1 Like
9

Hi @shaun.a.havelaar

Just updating you on what’s going on internally with this.

We’re bouncing the idea around in our engineering teams to have variable substitution for helm chart templates, and this has some good traction.

One of our engineers actually stated that we recently added this for Raw YAML steps, in relation to this GitHub issue. They have suggested that this might be good to use for the time being, and has the feature you desire. Could you let me know if it’s possible to switch to this template and if the variable substitution works for you in here?

Thanks!
Sean

10

Hi @sean.stanway

That is awesome news, it would undoubtedly be a valuable addition for anyone managing releases via helm charts.

I recently migrated from helm to using the Octopus Kubernetes steps for managing my microservice deployments, where it made sense to do so. However, I encountered two scenarios that I needed to solve (just going to put emphasis on some words that might help someone struggling with the same issue):

  1. Package and deploy microservices that are developed by our development teams as helm releases, with the ability to apply variable substitution in my values file would greatly benefit me. It would enable me to do templating for applications that are dependent on config maps. Initially, I managed my own helm templates, but moved to the Octopus Kubernetes steps because I have visibility and full control of the deployment process. It turned out to be a nice, clean solution:

    image
    image789×203 18.1 KB

  2. Configure and release helm charts provided by external providers, such as Emissary ingress, Elastic search, and DAPR. The benefits of using helm releases for third-party solutions far outweigh the drawbacks of providing additional arguments as a temporary solution for not having var substitution. I solved this by using Explicit key Values for simple, one-dimensional values and providing additional Arguments for more complex scenarios. Luckily the solution works, but would obviously be more manageable with variable substitution. My temporary solution:

    image
    image938×762 45 KB

Thank you for considering this feature request, and I look forward to seeing the progress in future releases.

2 Likes