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:
- dump the text into a
shared.env
file at a static path<compose-app-root>
at the root of the compose apps dir tree. - 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.