shorez

But only as long as it stays in a single file :(. And it does not have support for arrays as well

You are welcome! Feel free to reach out via Slack if you have more questions: https://grafana.slack.com on the #tanka channel

Glad to hear that :D

Well, Helm did templating.

Tanka does generating, because it seems to be more robust, as the tool understands the output (instead of string substituting a fragile syntax)

See the docs on more details about generating: https://tanka.dev/tutorial/k-lib

Delete: No, we need to add that command. For now, use `tk show --dangerous-allow-redirect | kubectl delete -f -`.

Diff: Use `tk diff`. It shows the differences between the local Jsonnet and the cluster. `tk apply` makes them reality afterwards.

Regarding Jsonnet:

1. Documentation is bad. We know that and work on improving that. Some resources that might help:

- https://tanka.dev/jsonnet/overview: Our own docs include some notes about Jsonnet in general for newcomers

- https://jsonnet.org/learning/tutorial.html: Taking the time to read this entire page opens eyes. Annoying and time consuming, I know but worth it.

Regarding Ksonnet and Kubecfg:

1. Ksonnet was magical. Tanka hopes to be Ksonnet without the magic. We got rid of all of those concepts, parameter merging and whatnot. You have Jsonnet and Tanka, a tool that pushes Jsonnet to Kubernetes. That's it. (ok, you also get a lot of handy features like CLI completion, diff and other things to make your dev experience better)

2. Kubecfg is similar, but has a smaller scope. It evaluates Jsonnet and pipes this to kubectl (basically). At the time we started Tanka, kubecfg was by the way part of the deprecated Ksonnet project, so we assumed it dead as well. Luckily it's not, as it is a very cool project, that inspired Tanka a lot.

Tanka after all aims to be like the `go` command: The one command you need to manage your entire complex kubernetes clusters. Also, Tanka is not strictly limited to a single language. For now we focus on Jsonnet, but more may come in the future

Downfalls of a bash based approach: You need to maintain it. And bash is hard to debug, especially when the house is on fire (production outage, etc)

Integrating should be quite straigthforward. Install Tanka, create a new project (tk init), copy your source of truth YAML (without transformations) somewhere under lib/ (for example lib/foo).

Then go to lib/foo/foo, and import each of those yaml files:

   {
     foo: {
       deployment: import "./deployment.yaml",
       service: import "./service.yaml",
     }
   }

In environments/default/main.jsonnet:

  (import "foo/foo.jsonnet") + {
    // patch environment specific things here
    // https://tanka.dev/tutorial/environments#patching
  }

Then use `tk show` to verify it works.

Furthermore, follow the tutorial to get an in depth understanding of Tanka: https://tanka.dev/tutorial/overview

So, let me share what we do internally at Grafana Labs:

General:

1. We run everything on Kubernetes

2. We configure it using Tanka, keep all Jsonnet in git

3. Changes are done using PullRequest

---

Grafana (the software) related:

1. We use provisioning: https://grafana.com/docs/grafana/latest/administration/provi.... This means dashboards are kept in .json files on the filesystem and loaded on startup

2. Those dashboard json files are ConfigMaps

3. Those ConfigMaps are created using Tanka

4. The content of those ConfigMaps is created using grafonnet-lib

This means, our dashboards are source-controlled! A change to a dashboard is reviewed, merged and automatically deployed (ConfigMap is changed, Grafana restarted, picks that up and done!)

---

Caveats:

- Edit dashboard in Grafana won't work anymore

- You need to mess with files - BUT this might change in the future, Jsonnet might become integrated to Grafana. Stay tuned :D

Exactly like YAML does.

With Tanka you would usually use the functions provided by `k.libsonnet` to generate your manifests.

For CRD's, there are no helpers available, so you either just write the plain manifest as a Jsonnet object (JSON syntax), as YAML and `import` it (gives you an object as well) or even better write some helper functions yourself, publish them as a library on GitHub and make future users happy :D

Hi, you won't have much contact with JSON at all.

While Jsonnet is technically a superset, all you will see during use is most probably function calls and imports.

You won't have to actually write the Kubernetes objects anymore, they are generated using helper functions, just like real programming languages would do.

Oh, too bad :(

The site is hosted on Netlify and seems to be working for most other people.

Maybe reset your browser cache, check your network or try on your phone using cellular data instead?

If the issue persists, I'll take a closer look :D

Kubernetes is very good at keeping track of state and maintaining it. You "just" tell it the state you want and it makes sure it becomes reality (this is the whole point of k8s actually). Terraform is doing the same thing, just for imperative (instead of declarative) APIs (like public clouds, etc).

The issue with Kubernetes is more expressing the state. Kube uses YAML, which quickly becomes verbose and hard to maintain. More on our blogpost: https://grafana.com/blog/2020/01/09/introducing-tanka-our-wa...

Tanka is trying to solve this issue by providing a more powerful language that overcomes these limitations hopefully.

You could use Tanka and Jsonnet to improve this for Grafana dashboards: https://github.com/grafana/grafonnet-lib.

Would that work for you?

On the same track as well! CUE looks exciting and we might very much implement add it to Tanka when it proves to be useful.

We have chosen Jsonnet because it already had an ecosystem and served us well, but Tanka is open to other languages as well

(Tanka dev here)

Nobody can neglect the power of helm charts (because so many already exist), so I think Tanka will add support soon.

Even though we are focused on Jsonnet right now, this does not necessarily need to stay that way forever.

Grafana for example is popular because it supports multiple datasources, Tanka should probably do as well (e.g. Jsonnet, CUE, Helm, whatever results in JSON)

(Tanka dev here)

I think this highly depends on your deployment process .. do you want full continuous deployment (CI deploying to the cluster)? In this case you could continue to use for example Jenkins to run `tk apply <environment>` on each merged PR.

Another option would be to use an in-cluster CD agent (for example https://fluxcd.io/), which uses Tanka to generate the yaml and applies it. Flux can be used with Tanka, needs some setup though: https://docs.fluxcd.io/en/1.17.0/references/fluxyaml-config-.... I guess we could simplify this in the future.

Feel free to reach out to me on Slack http://slack.raintank.io/ in the #tanka channel :D

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