I am trying to understand how to setup my Kuberentes deployments using Helm.
Here is my desired flow:
Team City builds the container, tags it with a version number and uploads it to a private container registry. (This part is working.)
A release is made in Octopus deploy. It can see tagged version number from the Container Registry and offers to use that version number.
A Helm chart release step is run. In that the Container Image and Tag (from the selected version) are available as variables to be passed in to the Helm chart (to override what ever is in the values.yaml file)
I can’t seem to find a way to do this. I have read a few docs that seem to indicate it is possible, but they are light on the details.
The key parts I am hung up on are:
How do I get Octopus deploy to set the release version to the latest version in the Private Repository when a new release is created (hopefully automatically created)?
How do I get an Octopus variable to the Container Tag that was selected (from the version number) so I can pass it into my helm chart?
Thanks for getting in touch! Good questions, and we’ll be happy to try to help in any way we can. Firstly I was hoping you could point me to the documentation you referred to - I’d like to have a closer look at that and hopefully we can expand and improve on it.
If I’m understanding correctly what you’re after, I think you can achieve this in the following ways.
To tie the container version and release version together, this could be done in your project’s settings. Under Release Versioning, select the radio option Use the version number from an included package, and select the step.
There are a number of system variables created and populated during the execution of a deployment. One of these might be useful and contain the required information.
Something that might be helpful are our debugging variables which you can use to print out a full list of every variable available during the deployment (and what they evaluate into on each step).
You can use any of these listed with the binding syntax, i.e. #{Variable}. (Make sure to disable these again after as they can negatively impact deployment performance.)
I hope this helps in your specific case. Please let me know if I’ve misunderstood anything about your setup, or if there’s anything else we can help with.
Octopus will find the latest version in the container registry by default, but with that option set as well it’ll use that same version automatically as the version for that release.
Thanks for following up! I think this makes more sense in my mind now (my apologies, and please correct me if I’m still mistaken in any way).
To get the container inside the Helm chart to change per deployment without changing the chart, you’d need to provide a template value as a replacement for a variable inside the chart. Unfortunately there’s no “additional packages” feature for the Helm step that you could use to define the container as a dependency, to be versioned and supply variables to. I think to do this it’d have to be one of the following options (both of which certainly less than ideal):
Update and re-version the chart with the updated version.
Another idea from my team might be to have a script before the Helm step that does nothing but allows you to define the container that can be versioned and used in the Helm step.
Is something like either of those options what you came across in your research?
I hope that helps, and please let me know what you think!
The step is named “Select image”, and the referenced package is named “selected-image”. This is my proof of concept, so the naming is not perfect.
Then I could reference the selected version like this:
