Expose all env vars to deployment #393

Closed
opened 2023-01-26 09:05:32 +00:00 by decentral1se · 3 comments
Owner

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?

Follows from https://git.coopcloud.tech/coop-cloud/organising/issues/236#issuecomment-15390 and will help `kadabra` run updates without having to have a copy of the local workstation env files. Does anyone have any concerns?
decentral1se added the
enhancement
label 2023-01-26 09:05:32 +00:00
Author
Owner

From #236 (comment)

It is still an open design question, how to retrieve all necessary env variables?
There are some env vars that are typically not passed to the container and only used for variable substitution in the compose file. Like COMPOSE_FILE and all the SECRET_VERSIONs.

The simplest way would be to pass all the env vars to at least one container.
I don't see any problem with it because the env vars shouldn't contain any sensible data. All sensible data should be stored in secrets.

Is there a docker compose syntax to pass all env variables to a service?

Another idea is to pass env vars as label. Either by manually specifying the non container variables as label, but this would be error prone and produce more work to maintain a recipe.

Or automatically by simply passing all env variables inside one label like coop-cloud.${STACK_NAME}.env='COMPOSE_FILE=...'.

Instead of passing all env vars it would be enough to only pass non container env vars, that are prefixed with ABRA_.

But this is a new .env convention, that requires to rewrite every .env file.

@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 the ServiceConfig which you could override somewhere.

Those are my initial thoughts!

From https://git.coopcloud.tech/coop-cloud/organising/issues/236#issuecomment-15390 > It is still an open design question, how to retrieve all necessary env variables? > There are some env vars that are typically not passed to the container and only used for variable substitution in the compose file. Like COMPOSE_FILE and all the SECRET_VERSIONs. > > The simplest way would be to pass all the env vars to at least one container. > I don't see any problem with it because the env vars shouldn't contain any sensible data. All sensible data should be stored in secrets. > > Is there a docker compose syntax to pass all env variables to a service? > > Another idea is to pass env vars as label. Either by manually specifying the non container variables as label, but this would be error prone and produce more work to maintain a recipe. > > Or automatically by simply passing all env variables inside one label like coop-cloud.${STACK_NAME}.env='COMPOSE_FILE=...'. > > Instead of passing all env vars it would be enough to only pass non container env vars, that are prefixed with ABRA_. > > But this is a new .env convention, that requires to rewrite every .env file. @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 the `ServiceConfig` which you could override somewhere. Those are my initial thoughts!
decentral1se changed title from Expose all env vars to deployment app to Expose all env vars to deployment 2023-01-26 09:52:24 +00:00
Member

Exposing 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.

Exposing all env variables to the app container: https://git.coopcloud.tech/moritz/abra/commit/da46996e6bfbe59d49473ee603a306c289741838 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.
Author
Owner

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...

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...
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/organising#393
No description provided.