3 ms·

Thanks for sharing, I will try it and give you feedback. What I am doing for my env clusters is to have a versioned production yaml that acts as a source of tr

Thanks for sharing, I will try it and give you feedback. What I am doing for my env clusters is to have a versioned production yaml that acts as a source of truth, then if I need an env (regions, customer, dev, prod, feature, etc..) I take that source of truth, apply a transformation (usually a node script or bash... depending on the kubernetes entity) and then apply the resulting transformed yaml. Basically is: versioned production => transform => new env definitions Do you have any recommendation/high level thoughts on how to integrate or substitute Tanka in this approach? Which are the downfalls that you see with this approach? Thanks.

shorez 7y ago
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 https://tanka.dev/tutorial/overview
- vicjicama 7y ago
  Thank you, I saw the example on the repository prom-grafana, I think that this example is for focus on the stand alone functionality of Tanka. Do you know if there is an example or open source cluster using Tanka that I can try on minikube or a test cluster? it would be really helpful to see how is the workflow to move from feature to feature, how are the envs when there is a bug, how do you replace the volume info from the cloud provider to minikube and all the considerations of the patched envs

shorez 7y ago

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 https://tanka.dev/tutorial/overview

vicjicama 7y ago
Thank you, I saw the example on the repository prom-grafana, I think that this example is for focus on the stand alone functionality of Tanka. Do you know if there is an example or open source cluster using Tanka that I can try on minikube or a test cluster? it would be really helpful to see how is the workflow to move from feature to feature, how are the envs when there is a bug, how do you replace the volume info from the cloud provider to minikube and all the considerations of the patched envs