Add support for templating in configs

[robholland]

What changed?

Support for text/template was added to the config loading system. Sprig is used for some useful templating functions, as used by dockerize and helm.

Why?

This avoids the need to use dockerize to render config templates when deploying in containers. Without the need to write the intermediate config to disk, the image can be immutable. Any volumes used to copy over an alternative template can be read-only also, enabling more secure deployment.

How did you test it?

Built a FROM scratch image using the updated temporal-server binary and confirmed that it would work when deployed using (slightly adjusted) version of our helm charts.

Potential risks

There is a very slim chance that some configuration files might accidentally have some text that looks like go template, which the code would now try and interpret. This seems very unlikely.

Documentation

Documentation should be updated to explain this new feature, but given it's so close to the standard deployment setup with dockerize, this doesn't need to block release of the feature imho.

Is hotfix candidate?

No

[robholland]

If preferred to avoid the slight risk we can add a flag that enables templating.

[robholland]

I misremembered during our call. Our kubernetes (including Helm) installs also need this functionality, its required to make use of passwords stored in kubernetes secrets.

[dnr]

If preferred to avoid the slight risk we can add a flag that enables templating.

Another simple approach would be to look for a string like enable-builtin-templating in the first 100 chars of the file (it would be in a comment).

I think server configs might need an overhaul though, ideally we wouldn't require multiple files and can simplify some of the structure.

What multiple files do you mean? Only one static config file is required. Dynamic config requires a second file only if you want to change anything from defaults, but it would be simple to add a "static dynamic config" section in the static config file if you wanted to override some things but not actually have them be dynamic.

[bergundy]

What multiple files do you mean? Only one static config file is required. Dynamic config requires a second file only if you want to change anything from defaults, but it would be simple to add a "static dynamic config" section in the static config file if you wanted to override some things but not actually have them be dynamic.

Yeah, it's less about requiring multiple files but that multiple files are supported and there's a concept of an environment that's not ideal to expose in the interface IMHO. It would have been nice to also support dynamic configs in the same file though. My main concern is experience in the dev server and we've deliberately decided not to support server configs because they don't have good DX today.

[dnr]

Yeah, it's less about requiring multiple files but that multiple files are supported and there's a concept of an environment that's not ideal to expose in the interface IMHO. It would have been nice to also support dynamic configs in the same file though. My main concern is experience in the dev server and we've deliberately decided not to support server configs because they don't have good DX today.

Oh, yeah, the environment stuff should go, agreed.

Supporting embedding dynamic config in the static config file would be like 20 lines of code. It would be a pretty easy change to even make it dynamic too. Is there a proposal for what the specific UX should be? I can whip up something but maybe it's better to design it first.

[bergundy]

Yeah, it's less about requiring multiple files but that multiple files are supported and there's a concept of an environment that's not ideal to expose in the interface IMHO. It would have been nice to also support dynamic configs in the same file though. My main concern is experience in the dev server and we've deliberately decided not to support server configs because they don't have good DX today.

Oh, yeah, the environment stuff should go, agreed.

Supporting embedding dynamic config in the static config file would be like 20 lines of code. It would be a pretty easy change to even make it dynamic too. Is there a proposal for what the specific UX should be? I can whip up something but maybe it's better to design it first.

Off the top of my head, to improve DX, we need to accept a single file, drop the directory and environment concept and allow embedding dynamic config in this single file. We'd better design this though before making changes, this will require some thought to be done in a non disruptive way.

[bergundy]

@dnr https://github.com/temporalio/temporal/issues/6561

[robholland]

I've added a comment that enables the templating, and a tdbg command to render the template (as YAML and Config{}) for debugging.

[github-actions[bot]]

This PR was marked as stale. Please update or close it.

[dnr]

Potential risks

There is a very slim chance that some configuration files might accidentally have some text that looks like go template, which the code would now try and interpret. This seems very unlikely.

This is no longer a concern, right?