One of the things we need to do is elastically scale the number of tasks (basically pods in tekton) that comprise our test suite run. This might be based on cluster utilization or whether it's the master branch. Since we have a single threaded test suite, we hoist parallelism up to the k8s level by breaking apart the tests into partitions each run by its own pod. For this we just render processed and parameterized erb to yaml. Eventually we'll dispense with yaml altogether and programmatically construct resources using a k8s REST api client.
We haven't moved into CD with any of this tooling yet.
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
We build an api and a cli util for these things.
The api takes care of providing sane deployment manifests based on data from a service registry, which is populated using the cli.
Cli can be run non-interactive for use in pipeline and other automations.
The cli and api basically do any config and deplyment related tasks in concert with service discovery (which at this time is consul).
Edit, rant: For automations json just owns yaml in all the ways!
This yaml templating business should stop! I think it’s silly tbh. :)
Our base k8s setup consisted of roughly 40k lines of yaml. Yaml is awesome for 10 lines of user input configuration, not 100, let alone 40k machine printed stuff. What happened here in this brave new DevOps world?!
1. A way to templatize YAML (though it could be used with Tanka too - the render command is split from the deploy command for this reason)
2. Monitors the rollout of resources - it's possible to detect successful and failed deployments more easily.
3. A way to run one-off commands during deployment.
4. Uses kubectl under the hood so easy to add to any workflow.
Net net - I definitely think it could elegantly replace a bunch of bash scripts that do kubectl things.
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?)