Grafana Labs employee here. We've been using jsonnet-bundler as a package manager on top of our Tanka configs. As for some common packages, we open source most of ours[1]. We also provide Tanka-compatible configs for Loki[2].

[1]: https://github.com/grafana/jsonnet-libs

[2]: https://github.com/grafana/loki/tree/master/production/ksonn...

Thanks a lot! I'll give these a try soon and provide any feedback via github.

Take a look into kustomize

https://github.com/kubernetes-sigs/kustomize

Thanks! I had briefly used kustomize in the past, and it looks really useful for creating alternative dev/staging/production environments from a common base.

In the end I decided that I'd collapse all environments down to behave identically, which is simpler, but does add a few constraints for development in particular.

Will take another browse through while considering options for upcoming infrastructure :)

The problem for us monitoring / observability people with kustomize is its limitation to be purely templating for Kubernetes. However we also want to template a lot of things like for example Prometheus configuration. Jsonnet can bridge that gap between the two worlds and in the end generate a ConfigMap YAML file that includes another YAML file Prometheus, as an example.

I tried to use kustomize recently but could not figure out how to write Job/CronJob properly. I wanted to use the configGenerator/secretGenerator, with prod/stage/dev.

I'd also recommended taking a look at using Terraform[1] to manage Kubernetes resources instead of yaml files and kubectl.

[1] https://www.terraform.io/docs/providers/kubernetes/guides/ge...

I agree. Terraform and it's providers are unbelievably powerful for deployments. Being able to create any sort of resource and passing that information onto your kubernetes service to use is really great.

An example would be creating a dynamically names S3 bucket and passing it onto your service to use/manage. The same goes with anything needing credentials. Very powerful.

I usually just deploy "GKE clusters, node pools, AWS route 53, S3 buckets, etc" in terraform. Then take the terraform output and convert it to command line options that I pass to helm when deploying a kubernetes cluster.

I'd be very tempted to just use terraform. But helm, with our forked charts, extensive values.yaml files, etc. has permiated the deployment.

So... rather than try to break up the helm beast; I leave it and keep the separation of concerns (infrastructure vs k8s) as described at the beginning. It works pretty well to be honest is rarely the source of problems.

Something that really helped me convert our helm charts to terraform was this little tool that convert yaml to terraform HCL. I would just render out the helm template and convert it.

Note: It uses the kubernetes terrform provider and only support those objects

https://github.com/sl1pm4t/k2tf/