Support Helm-style templating

[KnVerey]

• {env}.yaml with most values app maintainers will change parameterized
• partials
• probably not ERB (cloudplatform team did prototypes of this in both ERB and Golang)

[KnVerey]

A few notes:

• We will probably stick with ERB after all @camilo still feels quite strongly about this. How about Liquid? Camilo has reluctantly stated that he doesn't have any good arguments against it. 😛
• We need to re-survey the state of the community tooling and opinion on this before implementing anything. Relevant:
  • Whitebox COTS application management (need to join sig-apps google group for access)
  • Templates design proposal (notably argues against partials)
  • Rust prototype based on that proposal
  • PodTemplate may eventually become independently usable: issue1, issue2

cc @xldenis

[errordeveloper]

Have you seen my kubegen project? Lately, I've been playing around with some ideas around a macro syntax that would be native to YAML/JSON (somewhat alike CloudFormation), happy to chat more. I feel like plain text templating engines make the whole problem much more complex at times, and don't really guarantee valid output.

[KnVerey]

Hi @errordeveloper! I did check out your project at some point and it looks pretty cool. 😄 I've also got my eye on the ksonnet project's solution to this problem. Shopify is still using regular yamls for the time being, but we're actively exploring other options. As far as kubernetes-deploy is concerned, I'm currently thinking we'll either expect users to generate regular k8s defs with the tool of their choice before invoking it or at most add some sort of preprocessing plug-ins hooks. Making it super opinionated about a proprietary template format seems like the wrong way to go.

[skaes]

The main pain point for us are cronjobs. One of our teams has 20 of them. Just writing them down is an ordeal. Keeping them consistent after changes, for example in env variables, is a nightmare. I would love to have partials to solve this problem.

[skaes]

I have submitted a PR for a rather simple partials implementation which would nonetheless fulfill our needs. See #207

[KnVerey]

After giving this further thought, this is what I think we should do:

• extract our existing renderer into a separate class, and additionally expose it via a separate command (per Allow template rendering from the command line #228)
• add partial support to the renderer (per support partials #207)
• accept fully rendered templates from $stdin as an alternative to a template directory (like the -f option to kubectl apply)
• When we hit v1.0 (Version 1.0 requirements tracker #229), disable ERB rendering in the deploy command by default (either add a flag to trigger it or require piping the output of the rendering command)

This gem's purpose is to be a deploy tool, not a templating engine. Basic ERB rendering is great for convenience, and we should keep it available in some form. However, there are many better community tools available for k8s templating, and our focus should be on cross-compatibility with those.