3 ms·
The Prometheus Operator and Thanos projects only officially provide jsonnet libraries and example implementations, rather than Helm charts (which are provided b
by bdsa 4y ago
The Prometheus Operator and Thanos projects only officially provide jsonnet libraries and example implementations, rather than Helm charts (which are provided by the community, but I detest Helm charts anyway) so I've picked up Jsonnet in the last few weeks to build our new monitoring stack and I'm really impressed.
It's a massive learning curve but it has become really powerful and flexible.
I started trying to use Tanka but found the mental model a bit strange and struggled passing parameters into environments, so I tried Kapitan instead and that has been much more productive.
- brancz 4y agoOriginal creator of both of those here. I recommend just generating things out straight with the `jsonnet -m` command, and then doing `kubectl diff` on a PR and apply on merge. Scaled huge amount of infra this way and it’s easily understandable and extensible. To clean up the diff a bit I recommend using: https://github.com/sh0rez/kubectl-neat-diff https://github.com/sh0rez/kubectl-neat-diff Hope it’s helpful!
- bdsa 4y agoI have to admit I'm a little starstruck to see your username replying to me. Thanks for all the effort and expertise you bring to bear on observability! We're using exactly that diff-on-PR/apply-on-merge approach, checking the generated manifests in for easier reviews, but I found just using jsonnet -m made it difficult to DRY things out (e.g. set some URL values differently per environment) so I'd be curious to hear how you approach that? Would you wrap the customised kube-thanos/prometheus-operator "calls" in another library?