Tanka & jsonnet-bundler also work really well with Prometheus monitoring mixins, meaning we bundle up and share almost all the internal monitoring that we use at Grafana Labs to monitor our massive Cortex, Loki, Metrictank and Kubernetes deploys.
Tanka: Our way of deploying to Kubernetes
11–20 of 124 posts
Re: Tanka: Our way of deploying to Kubernetes
#12What about something like https://github.com/dhall-lang/dhall-kubernetes ?
Interesting, this is similar to jsonnet. Does it support deep merging?
For example, in our case we do `default_deployment.libsonnet` to which we add arbitrary overrides like `default_deployment + dev` or `default_dep + us_central1_overrides` depending on the cluster. And in these case we don't need to pre-specify what can be overriden in the `default_deployment` which makes it really powerful (also can come bite you in the arse though).
Re: Tanka: Our way of deploying to Kubernetes
#13Very interesting. I've been reluctant to adopt Helm for Kubernetes resource management because of a gut feeling that it's a heavyweight solution for what seems broadly like a templating problem. With ksonnet having gone quiet[0] this looks like a promising initiative. I'd imagine that it'll need something like a package manager (or at least a curated list of common packages) in order to gain good adoption. [0] - http…
Take a look into kustomize
Re: Tanka: Our way of deploying to Kubernetes
#14Very interesting. I've been reluctant to adopt Helm for Kubernetes resource management because of a gut feeling that it's a heavyweight solution for what seems broadly like a templating problem. With ksonnet having gone quiet[0] this looks like a promising initiative. I'd imagine that it'll need something like a package manager (or at least a curated list of common packages) in order to gain good adoption. [0] - http…
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...
Re: Tanka: Our way of deploying to Kubernetes
#15The shortcomings for Helm are relatively spot on, but I feel like the ship has sailed for tools that aren't Helm based. The ecosystem partners (and thus, end users) have rallied around Helm charts as the defacto manifest format, so a tool that doesn't understand Helm charts will not see a lot of adoption. Are there any plans for Tanka to support importing existing Charts?
Re: Tanka: Our way of deploying to Kubernetes
#16I don't know why they have to invent something new, if you're just managing kubernetes manifests, kustomize already is good for this task and simple to start with.
Hey we've been using ksonnet since before kustomize existed and we've just rewritten it to be more flexible with much more focus.
Further we use jsonnet a lot (including generating dashboards) and in general found it much more powerful and useful compared to plain YAML. From a customary glance, I can't find if kustomize supports jsonnet.
Re: Tanka: Our way of deploying to Kubernetes
#17This article seems to have a major factual error. YAML does support “Repetition” with anchors. Am I missing something?
Anchors are fairly limited: - they are bound to a single file. This won’t help you when trying to maintain multiple similar sets of Config - anchors do not support patching. If you need to change a nested key, you can’t do so without it affecting all other nested keys as well
Anchors also don't work with a list of elements.
For instance, if we want to share steps in a YAML based CI config we can't if they are a list.
Re: Tanka: Our way of deploying to Kubernetes
#18Lua in helm3 seems interesting, but it's not prime time yet. That makes me explore other options because helm's limitation in reusable templates is painful. Jsonnet seems to be working for several companies as well as kustomize. I'm still looking for something simple to template my manifests for different environments.
Re: Tanka: Our way of deploying to Kubernetes
#19This make me super happy, jsonnet is something that should be used by default in Kubernetes.
Hope this project get a lot of traction!
Re: Tanka: Our way of deploying to Kubernetes
#20Very interesting. I've been reluctant to adopt Helm for Kubernetes resource management because of a gut feeling that it's a heavyweight solution for what seems broadly like a templating problem. With ksonnet having gone quiet[0] this looks like a promising initiative. I'd imagine that it'll need something like a package manager (or at least a curated list of common packages) in order to gain good adoption. [0] - http…
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.