Expose all env vars to deployment #393

New Issue

2023-01-26T09:05:32Z

decentral1se commented

2023-01-26 09:05:32 +00:00

Follows from coop-cloud/organising#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

decentral1se referenced this issue

2023-01-26 09:08:12 +00:00

Automatic patch/security updates for deployed apps #236

decentral1se commented

2023-01-26 09:14:32 +00:00

From coop-cloud/organising#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

moritz commented

2023-01-26 11:26:03 +00:00

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.

decentral1se commented

2023-01-26 11:41:23 +00:00

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

moritz referenced this issue from toolshed/abra

2023-01-31 10:25:47 +00:00

Expose all env vars to `app` container. #263

moritz referenced this issue from a commit

2023-01-31 14:13:45 +00:00

Expose all env vars to `app` container. (!263)

moritz closed this issue

2023-01-31 14:13:46 +00:00

~~p4u1 referenced this issue 2024-03-11 12:57:14 +00:00~~

Release abra 0.9.0-beta #573

Sign in to join this conversation.