I’m new to Octopus and trying to setup release pipeline in Octopus for our Kubernetes application.
We use Helm and publish every new release of our application as Helm Chart into our own Helm repo.
So for example, we’ have MyApp Helm chart with version 1.0.0 published into Helm repo. And we create corresponding Octopus release for each version of the Helm chart. Hence we have Octopus release 1.0.0 created, pointing to MyApp chart version 1.0.0. Such release contains single Upgrade a Helm Chart step. So far so good.
I’m looking for recommendations / best practices on how to organize releasing of environment-specific and tenant-specific settings (stored as Helm values.yaml files).
Let’s say we have 3 environments: Dev, Test, and Prod. And we have N tenants in these environments (couple of mock tenants in Dev and Test, and hundreds of actual tenants in Prod).
We’d like to store environment/tenant specific values.yaml in a separate Git repo and update them as needed (e.g. enable/disable features, scale replicas, etc).
I know that Upgrade a Helm Chart step allows choosing values from “Files in Additional Packages” but these additional packages seem to be snapshotted at the release time.
So what would be the workflow if I want to edit some environment/tenant specific setting?
I can push updated values as new version of the settings-only package to Octopus built-in feed, but how do I re-deploy the same Helm chart (i.e. the same Octopus release 1.0.0) using newer version of the settings package?
PS. Side question - I wonder if Octopus support offer meetings to discuss such types of questions online?
With this feature, you can insert tenant-specific variables directly into the values.yaml file. This means you don’t need a separate file or package for each tenant, but can instead use a generic file for all tenants and insert the appropriate tenant/environment variable into the file at deploy time.
We sometimes do offer calls depending on the question or scenario. Some topics/issues are just easier to discuss over a screen share.
I hope that helps. Let us know if you have any follow-up questions.
Also, as far as I understood, if we use that feature then actual environment/tenant-specific settings will be stored in Octopus (as variables) rather than in our GitHub repo. Is that correct?
Ideally, we wanted to store them in GitHub and follow GitOps model.
My mistake, I didn’t realize the Helm Chart steps didn’t have the structured configuration variable feature.
But yes, that would require storing variable values in Octopus.
Based on the help text for Files in Additional Packages, it will run variable substitution within the files in the package. This is the #{VariableName} substitution syntax rather than the structured configuration syntax.
For an option that doesn’t require storing the values in Octopus, you’ll need to create a new package version for a change to the values.yaml file.
When you create a release in Octopus, you would choose a version for your Helm chart package and a version for your additional files package.
Then you would create a new release in Octopus, choosing the same version of the helm chart package and the new version of your additional values package.
So to summarize, an update to either the chart package or the values package would require creating a new Octopus release that has the appropriate versions selected.
