New CLI command: flux template

[richardmcsong]

Would anyone be interested in a template command? I actually already have this created in my fork, and am actively using this, but I wasn't sure if there was any interest upstream.

Spec

$ flux template --help
The template command renders Flux resources (HelmRelease, Kustomization) into their
final Kubernetes manifests locally, similar to how 'helm template' works for Helm charts
or 'kustomize build' for Kustomize overlays.

This command interprets Flux resources through source-controller, helm-controller, and
kustomize-controller logic to render out the final manifests to stdout.

The command never connects to the cluster. All resources (HelmRepository, GitRepository,
ConfigMaps, Secrets for valuesFrom) must be provided in the manifest file.

The command automatically detects the resource type from the manifest and renders it
appropriately. If the file contains multiple HelmRelease or Kustomization resources,
all of them will be rendered.

For Kustomization resources that reference a GitRepository source, the git repository
will be cloned to a temporary directory and used as the source path.

When --recursive is enabled, the command will continue to render any Flux resources
(HelmRelease, Kustomization) found in the rendered output until no more Flux resources
remain. This is useful for nested deployments where a Kustomization might produce
HelmReleases or other Kustomizations.

Usage:
  flux template [flags]

Examples:
  # Template a resource
  flux template -f ./manifest.yaml

  # Recursively render nested Flux resources
  flux template -f ./manifest.yaml --recursive

Use case

I work in a regulated, airgapped company, which means before flux can hit the ground running, I need to bootstrap the cluster with a bunch of controllers and tooling. However, on day 2, I also want flux to manage these same bootstrapped controllers and tooling. This created a problem for me: I had to write a bunch of kustomize/helm commands before i can use flux, then I have to duplicate those same definitions in the flux CRD form. I didn't want drift to exist between the two forms. There were two options I could choose:

1. create the kustomization/helm values, and then generate the flux definition from those files, or
2. create the flux definition, and then template them into the raw resources to act as "flux before flux is installed".

Hence, I created the flux template command; the -r is especially useful to template those nested resources out into raw manifests. The code is on main in my fork: http://github.com/richardmsong/flux2

[stefanprodan]

Did you looked into https://github.com/allenporter/flux-local it should have similar capabilities.

PS. We plan to have a plugin system for the Flux CLI similar to how kubectl & helm plugins work. This template command would be a good candidate for a plugin.

[richardmcsong]

I did take a look at flux-local before I headed down this path. Couple of things that shaped my decision:

1. The main one being that it's not written in golang; I would've wanted to use as many of the flux golang packages as possible to make sure it stays as close to how the flux system sees it. That being said, I noticed a couple of the packages i needed were hidden inside of internal/, which meant I couldn't just import it in my code.
2. I was worried that my intended use case would clash with the design of flux-local. Specifically, I intended on passing in some raw manifest to the flux template command, whereas flux-local build requires the hr|ks subcommand. That being said, any input is welcome; @allenporter we can compare notes if you want!

How can I help in the plugin system conversation? Happy to refactor this into a plugin when the time comes!

[stefanprodan]

We'll kick off a proposal about a plugin system after Flux 2.8 release which is scheduled for end of this month. Happy to have you on our public dev meeting and discuss about it.

[allenporter]

1. yes, original flux-local was in go, but i soon realized it would be quite difficult to depend on internal packages as you did. Instead, its uses the spec defined by the actual public APIs, and implements them. Maybe the clash I would say is that if you're working in an airgapped environment then I would also probably be uneasy depending on a project built for using flux in a homelab.
2. I'm not sure what you mean exactly but flux-local build ks uses flux build underneath. flux-local build hr uses help template underneath.

On the broader topic: very much welcome obsoleting/deleting flux-local some day if a plugin system makes it no longer needed.

[stefanprodan]

Here is the RFC for the Flux CLI plugin system #5795