Ksonnet: Simplify working with Kubernetes configurations
blog.heptio.comThis links to a blog post that is mostly marketing fluff and quotes from fawning CTOs. Useful documentation and examples are here: http://ksonnet.heptio.com
Also look at http://ksonnet.io that redirects to the github org for now. We will work on a community page to host there soon.
BCL is infamous inside google for being a very powerful footgun; jsonnet is a nice reboot of the idea, with a much saner semantics
I thought I was done with BCl/GCL when I left Google. But I guess there is no escape from it. BCL has really weird late binding behavior, very little tooling support.
Can I use ksonnet without knowing what the generated YAML looks like? If I still have to fully understand the underlying YAML formats, then using ksonnet just increases the cognitive load.
I think a parallel is say you decide to use TypeScript since it is all the rage;. But when you try to learn it, most docs says if you do this in TypeScript, this really happens in JS. Now, you need to know both TS & JS to do your job. This is why I personally never found coffeescript etc simpler JS exciting.
The idea is that we can support both simultaneously: - people who want/need full expressiveness can do that, and - people who don't need that can happily use higher-level templates that someone else has put together.
Previous efforts at "simplifying" k8s make you choose between one or the other use-case. ksonnet is trying to provide something that can be more continuous along this spectrum. .. At least that's the hope.
For a while, BCL/GCL scoping rules were what my nightmares were made of.
Jsonnet simplifies scoping over bcl quite a bit. Specifically there is no up operator.
Glad someone put in the effort for this.
I wrote something that fills this econiche sometime last year in Ruby (https://github.com/matsuri-rb/matsuri). Same ideas: mixins, generation of Kubernetes resources, etc. For better or worse, it also adds the idea of combining all the deployment environments into a single workflow and command line interface.
The big difference? Ksonnet is better documented and promoted, lighter-weight, and now better supported within the community.
[OP here]
Another goal here is to have something that is easy to embed/repurpose. ruby is pretty heavyweight from that point of view.
While jsonnet is a C program right now (https://github.com/google/jsonnet) we are looking at picking up work on a go port so it is easier to integrate with the kubernetes universe.
Looking forward to seeing the go port!
can you point to some examples of this matsuri? I failed to figure out what it is from the link you pasted.
A nice thing about jsonnet is that is it's a native data templating language, you don't have to compose a structured data format with a textual template language and deal with things as trailing commas in json or indentation (!!!) in yaml.
It offers a sound model for extending and overriding values.
Another thing: it's a fully featured programming language, but it's purely functional so you are guaranteed that your templates won't have surprising side effects.
In this respect, the most similar alternative is the Nix functional language.
Sorry, I don't have much in the way of examples. I am not using a textual template language. Instead, you define Ruby hashes which is then converted into either json (for loading into Kubernetes) or yaml (for debugging). It takes advantage of method overrides and class/module inheritance to achieve that. Specifications themselves are written as untyped, lazy-evaluated functional style. (Ruby being Ruby, it is not really immutable)
I just created a small example with redis: https://gist.github.com/hosh/89099f6f14ca5101e22c55f8d7f9e65...
That doesn't show off all of the features in there. There is a Rails-like convention so that resource definitions are loaded and can be referenced within each other. There are additional hooks that lets you generate `kubectl` commands, so for example, on our team, I defined hooks that lets me shell into a running container, or go directly to the console. (Redis, MongoDB, PostgreSQL, Rails, Rabbitmq, etc. consoles)
So yeah, Matsuri is very heavy-weight compared to Ksonnet. It isn't just that it is Ruby (already heavy-weight). Feature-wise, it does a lot more. I'm not sure that is a good or a bad thing.
jsonnet is great. We've been using it at my company to generate our configurations for ElasticBeanstalk, Terraform, and other various auxiliary services.
We've been looking into moving towards Kubernetes. I'm looking forward to seeing if ksonnet can fit our needs.
you may use this tool for JSON Formatting and Validation.
I have been working on a UI based system for managing these configurations in a way that doesn't rely on any particular syntax but allows you to construct object graphs (that is what they all boil down to) directly: http://blog.crudzilla.com/2016/10/managing-configurations-wi...
I will be interested in feedback on how such an approach could be helpful in managing complex configurations.
This looks very interesting, but there's not much info there, I guess without being able to login.
I might regret this but you can login with: developer/developer
:) be nice!
Wow, that's a huge piece of work. Unfortunately, I don't have the time to dig in deeply enough to truly appreciate it.
feel free to poke around when you have time, it is a very powerful platform...happy to give a demo session to you or a team if you're interested at some point.
Thanks! It does look pretty powerful, and I hope you're getting some traction with it.
Is there a dockerhub image or linux binary available? Trying to figure out the context of best way to use this in a job. Currently have been using containerized https://github.com/andreasjansson/envtpl in my builds and been pretty happy with it.
It's "alpha", as the version signifies - but there's a linux/x86-64 binary of 'kubecfg' you can play with on https://github.com/ksonnet/kubecfg/releases
If anyone is looking for the same, I made a quick docker image here: https://github.com/moondev/ksonnet-docker
nit/rant: I think it would've been better if JsonNet was named differently, since there is "Json.Net" and googling for "JsonNet" find it (or looking at say ht.algolia.com).
It's not that critical to the project itself, just naming and discoverability.