Managing infrastructure components
On this page you can learn how to manage infrastructure components of an environment.
On the dashboard
Navigate to the environment you want to edit. Like in case of an environment called
deleteme, navigate to Environments > deleteme > Infrastructure components and locate the desired component to edit.
On the Config tab enable it and provide the necessary configuration.
Hit Save components and inspect the gitops commit Gimlet makes in your infrastructure configuration gitops repository.
You can monitor the components as they come up:
$ kubectl get pods -n infrastructure -w NAME READY STATUS RESTARTS AGE ingress-nginx-controller-66455d768d-v8pgh 1/1 Running 0 8s
On the command line
Reconfiguring infrastructure componentes
When you run
gimlet stack configure and configure components on the UI, the configuration options are stored in a file called
Next time you run
gimlet stack configure the configuration options are read from
stack.yaml and you can reconfigure your settings. 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's own format, therefore for your configuration changes to be effective on the cluster, make sure to run
gimlet stack generate every time you make changes to the
stack.yaml file. Be that changes through the UI or manually.
Once you ran
gimlet stack generate, make a git commit and push it. You should see the changes on your cluster.
stack.yaml points to the stack template in 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
gimlet stack generate it works with the same stack version and generates Kubernetes resources accordingly.
--- stack: repository: https://github.com/gimlet-io/gimlet-stack-reference.git?tag=v0.8.0 config: loki: enabled: true nginx: enabled: true host: laszlo.cloud
gimlet stack update --check displays the new versions that can be applied to your stack, while running
gimlet stack update will update
stack.yaml to the latest stack version number:
$ gimlet stack update ⏳ Stack version is updating to v0.3.0... ✔️ Config updated. ⚠️ Run `gimlet stack generate` to render resources with the updated stack. 📚 Change log: - v0.3.0 • Cert Manager - Just a bugfix release • Grafana to 8.0.1 🎉 • Plenty of goodies, see for yourself: [https://grafana.com/docs/grafana /latest/whatsnew/whats-new-in-v8-0/](https://grafana.com/docs/grafana/ latest/whatsnew/whats-new-in-v8-0/) • 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 one. • Prometheus • Upgrading node-exporters and kube-state-metrics to the latest • Sealed Secrets to 0.16.0 - nothing major in this one
Important that you run
gimlet stack generate to generate the updated Kubernetes manifests, as
gimlet stack update only updates the stack reference in
Make sure to
- inspect the changeset
- resolve possible conflicts with custom changes
- push to git
You can automate stack upgrades by using a Github Action maintained by Gimlet.
- periodically checks for updates,
gimlet 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.
gimlet 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 conflict
The bellow output was from a stack that was upgraded from
0.3.0 and having a custom change on top of
The cluster administrator manually upgraded the version to
3.27.0 to update to a newer version ealier than Gimlet supported it.
Since stack version
0.3.0 also updated the ingress-nginx version, now the cluster administrator has to make a judgment call whether to keep the manually updated version or roll with generated changes.
--- apiVersion: helm.toolkit.fluxcd.io/v2beta1 kind: HelmRelease metadata: name: ingress-nginx namespace: infrastructure spec: interval: 60m releaseName: ingress-nginx chart: spec: chart: ingress-nginx <<<<<<<<< Your custom settings version: 3.27.0 ========= version: 3.33.0 >>>>>>>>> From stack generate sourceRef: kind: HelmRepository name: ingress-nginx interval: 10m
Many code editors have conflict resolution tooling. With a click of a button, the cluster administrator can accept the changes coming
From stack generate.