Refactor .env
management
#36
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Should be possible to replace a per-project templated
.env
file with an inheritance-based model.References
assigned to @Jafner
marked this issue as related to #34
Here's what I'm thinking:
.env
file:homelab.env
,host.env
, andproject.env
.homelab.env
with variables that are relevant and correct for all hosts and applications. Examples:TZ=America/Los_Angeles
,ADMIN_EMAIL=joey@jafner.net
, PUID/PGID, and SMTP configuration variables.host.env
with variables that are relevant and correct for all applications on that host. Examples:DOCKER_DATA
/DOCKER_CONFIG
and media directories.project.env
with variables that are specific to an application or project.Then, for each compose file, we define:
We'll roll this out for jafner.tools first.
Wish I had a dev env.
Actually, that's stupid. jafner.tools is supposed to be more reliable.
We'll build out the
.env
files, then recreate projects to use the new convention one at a time.I think the proper order is:
I believe this will create proper inheritance.
We will be able to test this by inspecting resulting container env vars with:
docker inspect --format='{{range .Config.Env}}{{println .}}{{end}}'
mentioned in commit
f152d23a79
mentioned in commit
6943756b1c
mentioned in commit
178335afc5
mentioned in commit
33b63a05d4
In preparation for #32, let's split out sensitive/secret env vars into their own secrets.env at the project level.
mentioned in commit
4b37285b8e
mentioned in commit
74df7d409e
mentioned in commit
c33c89e430
mentioned in commit
bf6ff38a63
mentioned in commit
da154beae5
mentioned in commit
55aea52473
mentioned in commit
0db2d341b0
mentioned in commit
4578384c1f
mentioned in commit
d3b3386c0d
mentioned in commit
491e079c9a
mentioned in commit
2ee6dfd884
mentioned in commit
a5bfb89aff
mentioned in commit
345edae285
mentioned in commit
0520696a1d
mentioned in commit
69079e848f
mentioned in commit
62ebf57f47
mentioned in commit
b99f2b6c60
mentioned in commit
2a780957bf
mentioned in commit
0004eb3603
mentioned in commit
d0dd8fc621
mentioned in commit
724a2a6932
mentioned in commit
2d670a59e0
Updated all current services to use the following:
<project_name>.env
.<service_name>.env
.<project/service_name>_secrets.env
file.This system is intuitive, safe, and ensures all used env vars are easy to find, even without checking the running container. It is also easy to maintain.
Re-opening with a logic error.
Env variables declared in files referenced by the "env_file:" compose key only pass information to the shell. While these variables are passed into the container's shell, they are not utilized if referenced in the compose file itself. See the result of
docker-compose config
for calibre-web below:Ultimately, this means we'll need to handle volume variables differently from traditional env vars.
I can think of a few ways to do this:
.env
file.I'm inclined toward the latter.
mentioned in commit
306bd8d132
All volume vars are now stored in the project's
.env
file, which is not passed into the container. It is only used in the compose files themselves.This is done. This solution has been tested and working for 3 weeks.