Support env var interpolation in compose apps "installed via YAML"

Problem/Justification
Electric Eel’s “Install via yaml” interface only supports a single, limited use case for compose that does not allow any env variable interpolation. This requires the user to follow the anti-pattern of hard-coding everything about the software deployment specification into a single file with all interpolations made.

Background:

  • The environment: section in the yaml only gets set in the resulting container, and cannot be used for interpolation in the yaml.
  • Same holds for env_file:

Impact
This is extra work for the user, since most software projects supporting container orchestration use modern, basic, techniques for template reuse, which minimizes changes required in source control systems and makes a single template applicable to any situation.

More importantly, this limitation means users are doing much manual work, highly prone to the kinds of errors that templating automations were created (long ago) to reduce/eliminate.

All of this forces users to take a huge step backwards in using a tool they’re already very familiar with (compose).

User Story
There is a new textbox interface alongside the existing one for compose yaml for specifying the contents of a standard .env file, already supported by docker compose. Its contents are dumped into an .env file, analogous to, and alongside the compose.yaml in the underlying custom app directory.

When the underlying docker compose up/down commands are run in this custom app directory, it uses both of these generated files by default, since their names follow the compose spec.

This very simple feature implementation would get us 90% of the way there. All that remains is DRY optimization (like that discussed here), so that users have a way to share common env vars across their deployments and don’t have to copy/paste the same vars more than once.

This would be achieved with a new interface, accessible via a new “Global Env” or “Shared Env” button in the existing “install via yaml” interface, for specifying environment variables that will be exported and available to ALL custom app “install via yaml” processes. The underlying implementation for this would:

  1. dump the text into a shared.env file at a static path <compose-app-root> at the root of the compose apps dir tree.
  2. this file gets sourced unconditionally in the environment of the underlying docker compose calls, e.g. . <compose-app-root>/shared.env && docker compose ...

Speaking of “suitable UI”, i should mention that it took me quite a while to find this much-hyped compose yaml interface. I propose that as the above UI changes are made, we move the “install via yaml” feature out from under the … menu into the main “Custom App” interface, or, if it needs to be separated in the front end, let’s have two more clearly labeled buttons at the same level: Custom App and Compose App.

All of this would make the custom compose app interface feel like a first class citizen in TrueNAS, and IMO finally justify all the hype there’s been about the change from k8s to compose.

Thanks for your consideration.

This smaller ask would probably be better suited by breaking it out into its own feature request for voting/consideration.

Ps. don’t forget to vote for your own suggestion.

This, in turn, would be easier if users had more votes.
With few votes, typically quite a wait before a decision is made and the votes are released, we have to be cautious what we vote for and what we propose.

1 Like

I would suggest going farther than this relatively small change. Sorry if this sounds harsh, but the custom yml feature feels entirely half-assed and appears to have been added on as an afterthought, and the entire thing should be reworked instead of wasting time on the custom app thing (the one where you don’t touch YaML code and try to input stuff in a form).

Just look at the Dockge app, and copy what it does for the most part. It’s pretty good (though missing some features), but it’s annoying being a separate app, plus it doesn’t tell you per-container CPU/network activity the way the TN built-in apps do. There should be an option to just have a real custom yaml app; when you click on it in the app interface, it shows you the yml file in one pane, the env file in another pane, gives you a way to set a custom icon and set up a button for the web UI, and also shows you a shell window (always-on, without having to click on an icon as it is now) showing the current log for that container.