[q3k]

Highly recommend trying Jsonnet (via https://github.com/bitnami/kubecfg and https://github.com/bitnami-labs/kube-libsonnet) as an alternative. It makes writing Kubernetes manifests much more expressive and integrates better with Git/VCS based workflows. Another language like Dhall or CUE might also work, but I'm not aware of a kubecfg equivalent for them.

Jsonnet in general is a pretty damn good configuration language, not only for Kubernetes. And much more powerful than HCL.

[threentaway]

If you like those, I'd take a look at Grafana's Tanka [0]. It also uses jsonnet but has some additional features such as showing a diff of your changes before you apply, easy vendored libraries using jsonnet-bundler, and the concept of "environments" which prevents you from accidentally applying changes to the wrong namespace/cluster.

[0] https://github.com/grafana/tanka

[q3k]

I looked at it, I don't like it for the same reason as I dislike many other tools in this space: it imposes its own directory structure, abstraction (environments) and workflow. I'm a fan of the kubecfg-style approach, where it lets you use whatever sort of structure makes sense for you and your project.

It's a 'framework' vs 'library' thing, but in the devops context.

[dilyevsky]

I worked on this at previous gig - https://github.com/cruise-automation/isopod

Same use-case but uses Starlark dsl instead of jsonnet

[kraig]

Funny, I thought jsonnet was an even worse experience than templating yaml

[p_l]

The problem with templating YAML is that you're templating text, in a very sensitive to whitespace syntax. By definition, Jsonnet avoids that because it operates on the data structure, not on their stringified representation.

[q3k]

My experience with jsonnet varied: there's good jsonnet code, and there's bad one, too. Just like with any programming language, you have to apply good software engineering practices. Text templated YAML, however, is terrible by design.

[AlphaSite]

Ive found the whole k14s eco system is pretty great to (ytt + kbld + kapp).

[q3k]

ytt is even more templating-yaml-with-yaml, so it all ends up being a bargain bin Helm. There's no reason to do this over just serializing plain structures into YAML/JSON/...

[AlphaSite]

It avoids the whole set of issues you get with templating yaml with helm since its structure aware.

Also you can actually write pure code libraries in starlark (basically a subset of Python)

[q3k]

I'm aware, but I just don't understand the point of it. How is it in any way better than a purpose-specific configuration language like Dhall/CUE/Jsonnet? What's the point of having it look like YAML at all?