Expose all env vars to deployment #393
Labels
No Label
abra
abra-gandi
awaiting-feedback
backups
bug
build
ci/cd
community organising
contributing
coopcloud.tech
democracy
design
documentation
duplicate
enhancement
finance
funding
good first issue
help wanted
installer
kadabra
performance
proposal
question
recipes.coopcloud.tech
security
test
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/organising#393
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
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?
Follows from #236 (comment) and will help
kadabra
run updates without having to have a copy of the local workstation env files. Does anyone have any concerns?From #236 (comment)
@moritz
So, afaiu the app is loaded from the filesystem and then the env vars are passed as
app.Env
into the underlying docker lib compose loading functions. I'm not sure we inject env vars into the running container programmatically atm, this could be new?My guess would be that you can programmatically stuff them into the
environment: ...
stanza and they'll then become available in the container. You could do this for each app service, seems fine?This seems to be available after the compose configs are merged and returned up the stack. The
Environment
seems to be available in theServiceConfig
which you could override somewhere.Those are my initial thoughts!
Expose all env vars to deployment appto Expose all env vars to deploymentExposing all env variables to the app container:
da46996e6b
I'm not sure if it's better and maybe less error prone to pass them inside a label?
But at the moment I don't see any issues with the current approach.
That's wonderful 👏
I guess the issue with putting the env vars on the label is that most operators won't expect it? Env vars are usually to be found in the container run-time environment (e.g. when you run
env
in the shell). Unless we're saying that only internal tooling will look for these labels, then I can understand doing potentially both at the same time?It seems we need to poll the community to see if people are using their env files to pass secret values iiuc /cc @mayel and potentially others may be doing this. And I wouldn't blame anyone because loading a new secret into the recipe involves a bit of busy work in the recipe config...
p4u1 referenced this issue2024-03-11 12:57:14 +00:00