It is simpler than other tools, because you can get started without even touching jsonnet or python or anything else, when using our generators.
It does more than all the other tools combined, as it replaces helm+helmfile+gitcrypt or kustomize.
It's universal, so you can use it on non-kubernetes situations where other tools leave you high and dry.
With the new generator library, you can have 1 template and use it to configure many services. Check our examples at https://github.com/kapicorp/kapitan-reference
We have just released: * https://github.com/kapicorp/kapitan-reference a repo with examples for quick-start. It includes our generator as explained in https://medium.com/kapitan-blog/keep-your-ship-together-with.... * https://github.com/kapicorp/tesoro a secret "webhook controller" to seamlessly handle Kapitan secrets in your cluster. Better than sealed-secrets because there is no need to convert secrets and it supports KMS like google and aws together.
Get started with our blog: https://medium.com/kapitan-blog or join our kubernetes slack on #kapitan
When I started with kubernetes I converted my small Docker compose files to kubernetes files. Later I rewrote everything in helm charts. Now it's almost more YAML and golang templates lines than business logic lines in my applications.
I'm considering to go back to Docker compose files. It's simple, readable, and easy to maintain.
Jsonnet in general is a pretty damn good configuration language, not only for Kubernetes. And much more powerful than HCL.
It's a 'framework' vs 'library' thing, but in the devops context.
Same use-case but uses Starlark dsl instead of jsonnet
Also you can actually write pure code libraries in starlark (basically a subset of Python)
But I hate the UX of kubernetes. Compose was beautiful.
I have hope - since compose files have become an independent specification. https://www.docker.com/blog/announcing-the-compose-specifica...
Kubernetes distro built around the compose file specification would be a unicorn.
It is simpler than other tools, because you can get started without even touching jsonnet or python or anything else, when using our generators. It does more than all the other tools combined, as it replaces helm+helmfile+gitcrypt or kustomize. It’s universal, so you can use it on non-kubernetes situations where other tools leave you high and dry.
With the new generator library, you can have 1 template and use it to configure many services. Check our examples at https://github.com/kapicorp/kapitan-reference
We have just released: * https://github.com/kapicorp/kapitan-reference a repo with examples for quick-start. It includes our generator as explained in https://medium.com/kapitan-blog/keep-your-ship-together-with...
* https://github.com/kapicorp/tesoro a secret “webhook controller” to seamlessly handle Kapitan secrets in your cluster. Better than sealed-secrets because there is no need to convert secrets and it supports KMS like google and aws together. Get started with our blog: https://medium.com/kapitan-blog or join our kubernetes slack on #kapitan
- a deployment - a service - an ingress - a config map (or several) - a secret (or several)
It's even worse for stateful applications.
And each of the resource definitions is 60% boilerplate, 35% application-specific and 5% release- or environment-specific.
Helm would probably be a nice and neat tool if it had stopped at maintaining a simple map of variable names to values. But since applications need things like "if the user said SQLite, add a pvc, a configmap and a secret and refer to them in the ss, if she said Postgres, go pull another chart, deploy it with these parameters, then add this configmap and this secret and refer to them in the ss", Helm is an overcomplicated mess.
Or people have to keep inventing half baked things.
How do you make helm chart deployment declarative? `helm install` is not declarative (in my understanding `kubectl apply` is declarative and `kubectl create` is not. Let me know if my understanding of declarative is wrong). Thanks.
If you want to have complete control of what you're pushing to the API, use Helm as an starting point instead, run `helm template` and save the YAML output to some file, publish it using `kubectl` or some other rollout tool. I recommend using `kapp` [1] for rollouts.
Kinda loses the benefit of Helm hooks, but if one is using Spinnaker, there are other ways to do the same thing hooks can do.