Docker powered templates about kapp-controller HOT 6 CLOSED

Seems like there is no simple implementation sadly. I'll step back for now and get more familiar with kapp and ytt, maybe get back to this issue later. Feel free to close the issue

from kapp-controller.

ive stayed away from introducing this for now, but curious to hear your use case: what templaters are you using?

main reason why i avoided this so far, is that there is no "easy" way to implement this without either (a) preloading these into kapp-controller as separate containers and running a little daemon alongside or (b) using a separate pod to perform processing (which also could be considered to be done in multiple way: persistent pod per app, persistent pod for specific templating, etc.)

from kapp-controller.

another nuance is how this might play in with CLI version of this controller: #2, since this introduces docker daemon dependency.

from kapp-controller.

My use case

I'm currently using helm and helm-operator, but want to migrate to kapp because of go templating limitations.

I want to implement my own template engine with such features:

1. Programming language instead of templating language
2. Ability to use helm charts inside (as pure functions, without features like lookup)

With kapp it's easy to integrate custom templating, but with kapp-controller I'm limited to template engines implemented in controller itself.

Implementation

I think the most direct approach for implemetation is kubernetes batch jobs. Every time templates or values have changed, job should run, kubernetes manifests should be taken from its stdout and deployed via kapp.

Templating is supposed to be side-effect free, so it should be performed only if templates or values have changed. I don't know if kapp-controller is already working this way

CLI

What is the purpose of having kappctrl cli? I can see three reasons:

1. Deploying from yaml files with kapp-controller CR. Not sure if it's required because it already can be done with kubectl apply -f

2. Deploying without yaml files based on cli arguments. This is how knative cli works. Might be useful and plays well with any configuration because cli in that case just creates CR from command line arguments and then kubectl apply -f them.

3. Deploying from yaml files with kapp-controller CR but without kapp-contoller installed in cluster. I beleave it isn't a goal of kapp-controller, but it it is, batch job can still run in cluster

from kapp-controller.

I want to implement my own template engine with such features...

👍

What is the purpose of having kappctrl cli? I can see three reasons:

yup, point 3 is why we want to have a CLI:

Deploying from yaml files with kapp-controller CR but without kapp-contoller installed in cluster. I beleave it isn't a goal of kapp-controller, but it it is, batch job can still run in cluster

especially during development stages of App CR user may want to be referencing local directory as source, using functionality to tail logs inline, build images with kbld, etc. App CR ultimately represent a common workflow for getting app from source/config -> cluster, so we would want to unlock this workflow for local development as well, and having App CR be consistent with what gets sent to the cluster (eventually) is a nice bonus.

I think the most direct approach for implemetation is kubernetes batch jobs ... kubernetes manifests should be taken from its stdout and deployed via kapp.

that's definitely an option, though it rasise questions how to securely pass the output. we cannot rely on stdout of the container executing since output will/may contain sensitive data (like Secrets) and will be captured by typical logging solutions within a cluster.

that leaves us with needing to "intercept" output from the templating engine and pass that back into kapp in a more secure way. that could be achieved by having a statically built binary that gets copied over into templating container and wraps templating invocation. 🤔

from kapp-controller.

closing for now. feel free to reopen. we'll most likely reference to this discussion at a later point.

from kapp-controller.