My 2020 prediction: k8 stacks are the new JS frameworks.
Tanka: Our way of deploying to Kubernetes
21–30 of 124 posts
Re: Tanka: Our way of deploying to Kubernetes
#22Very 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 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 :)
Re: Tanka: Our way of deploying to Kubernetes
#23This seems interesting, but would have liked to see dashboard and chart configs cleaned up. Grafana's json configs have the same issue. I have a dashboard for one project. The json is over 13k lines long. Less than 5% of that is unique.
Re: Tanka: Our way of deploying to Kubernetes
#24What are folks thoughts on CurLang these days? Anyone using it for serious configuration yet?
It’s designed by the BCL/GCL author as a replacement (Jsonnet is apparently a copy of BCL/GCL)
Re: Tanka: Our way of deploying to Kubernetes
#25I hear you like abstractions. I put some abstractions in your abstractions so you can have more abstractions.
Don't worry your VP of Engineering is a complete idiot.
Re: Tanka: Our way of deploying to Kubernetes
#26cue[0] might be another possible language for this problem
[0]: https://cuelang.org/
Re: Tanka: Our way of deploying to Kubernetes
#27My 2020 prediction: k8 stacks are the new JS frameworks.
kubernetes is the invasion of js devs to the server - wondering when all the neckbeards will wake up and start fighting back
Re: Tanka: Our way of deploying to Kubernetes
#28This looks pretty similar to qbec https://github.com/splunk/qbec
Re: Tanka: Our way of deploying to Kubernetes
#29We're in the process of evaluating tools to get away from 90% identical yaml files across environments and this seems like a good alternative to kustomize or helm.
Do you have a good pattern on how to use it with CI/CD for deployments? The biggest challenge we've had after writing deployments is getting it setup to work with something like Jenkins (right now we have a custom bash script that does a bunch kubectl things).
(PS any way this would help with static IPs on hosted Grafana.com Cloud to make access to firewalled datasources easier?)
Re: Tanka: Our way of deploying to Kubernetes
#30What 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…
I'm not sure how it would work with this, since I've never used it, but Dhall does have some kind of recursive merge operator that might work https://docs.dhall-lang.org/references/Built-in-types.html#i....
You might have to overload it somehow to make it work the way you're describing though.