Advanced guides
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 stack.yaml
.
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.
Updating components
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
Updating
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 stack.yaml
.
Make sure to
- inspect the changeset
- resolve possible conflicts with custom changes
- push to git
Automatic updates
You can automate stack upgrades by using a Github Action maintained by Gimlet.
It
- periodically checks for updates,
- runs
gimlet stack update
on 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.2.0
to 0.3.0
and having a custom change on top of 0.2.0
.
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
.