Reconfiguring, upgrading and making custom changes to stacks
Reconfiguring a stack
When you run
stack configure and configure components on the UI, the configuration options are stored in a file
When next time you run
stack configure the configuration options are read from
stack.yaml and you can reconfigure your settings.
As you can see, the
stack.yaml file contains the full configuration of your stack, and you should version it in your stack repository.
Always re-generate after you reconfigured
stack.yaml is Gimlet Stack's own format, therefore for your configuration changes to be effective on the cluster,
make sure to run
stack generate every time you make changes to the
stack.yaml file. Be that changes through the UI or manually.
Once you ran
stack generate and made a git commit and pushed, you should see the changes on your cluster.
Stack version is locked
stack.yaml has a reference to the stack template, under the
stack.repository field it points to a git repository where the stack files are maintained.
By default, it is locked to a particular version, therefore every time you run
stack generate it works with the same stack version and generates Kubernetes resources accordingly.
stack update --check displays the new versions that can be applied to your stack, while
stack update will update
stack.yaml to the latest stack version number:
$ stack update
⏳ Stack version is updating to v0.3.0...
✔️ Config updated.
⚠️ Run `stack generate` to render resources with the updated stack.
📚 Change log:
• Cert Manager - Just a bugfix release
• Grafana to 8.0.1 🎉
• Plenty of goodies, see for yourself: [https://grafana.com/docs/grafana
• Ingress Nginx from 0.44 to 0.47
• Updates NGINX to version v1.20.1
• Loki - just keeping track of the latest release - nothing major in this
• Upgrading node-exporters and kube-state-metrics to the latest
• Sealed Secrets to 0.16.0 - nothing major in this one
Important that you have to run
stack generate to generate the updated Kubernetes manifests, as
stack update only updates the stack reference in
Make sure to
- inspect the change set
- resolve possible conflicts with custom changes
- push to git
You can automate stack upgrades by using automation provided by Gimlet Stack.
The implemented Github Action
- periodically checks for updates,
stack updateon new versions
- and opens a Pull Request with the new version
- it can also assign you as reviewer
See the action in an example workflow.
Making custom changes to a stack
Stack templates only go so far, and it is inevitable that you want to amend the generated manifests in slight ways.
stack generate takes your custom changes into account and keeps them even after a configuration change, or an upgrade.
In case your custom change is conflicting with the generated content, you have to do a content merge, that should be familiar from git.
Custom changes that conflicts
The bellow output was from a stack that was upgraded from
0.3.0 and having a custom change on top of
operator manually upgraded the version to
Since stack version
0.3.0 also updates the ingress-nginx version, now the operator has to make a judgment call whether to keep
the manually updated version or roll with generated changes.
<<<<<<<<< Your custom settings
>>>>>>>>> From stack generate
Many editors have conflict resolution tooling. With a click of a button, the operator can accept the changes coming
From stack generate.