Mutating Application env with put_env in containers, good or bad?

It sounds like you’re probably looking for the releases functionality that was added in Elixir 1.9. Here’s a good guide about setting up a Docker container that builds using mix release, where the runtime config is set from environment variables.

Thanks for the reply , my app is already a multistage docker build using docker-compose to run it. From the article it seems it relies on the vars to be passed while bringing up the container. Maybe thats the way to go by which I might have to make peace with but then again one could have many such variables for the config making it error prone to start up your application or the command complex enough to remember.

for my 2nd part of the question is mutating Application env acceptable ? is it bad or just a choice ?

Sorry, I think I misunderstood the question.

I usually have a config/rel/runtime.exs file, which sets the application config from the system’s environment variables. e.g.:

config :app, :component, api_key: System.fetch_env!("API_KEY")

Then I make as many calls to Application.fetch_env! as I need to from the runtime code - they’re cheap enough.

I wouldn’t mutate the Application environment further at runtime. I think of it as layers: System Environment → Application Environment → Runtime code, with each layer reading the layer outside it, but never writing to it.

That means accepting that your docker run command might reference a lot of environment variables. I’d prefer to keep everything explicit, so I’d tend to solve that through other means, perhaps a bash script, depending on your environment.

Are you actually running into concrete performance problems with this? I wouldn’t really expect you to unless you’re calling that in a very tight loop.

not really for my current use case but considering it is called quite frequently I wouldn’t do it in ruby, new to elixir so trying to understand its impact for high volume apps. Does it have any additional overhead compared to Application.fetch_env. the bot can get enough request to simulate a high traffic app and I haven’t seen any impact with reading multiple values from System yet

so list down whats missing or happening while using docker-compose
I have the config sentrey set via env variable

config :sentry,
  dsn: System.get_env("SENTRY_DSN"),
  included_environments: [:prod, :dev],
  environment_name: Mix.env()

The value is set via env_file option in the docker-compose file.

after doing a build the
docker-compose build
values are available inside the container when I run it
docker-compose up

docker exec -it ultronex_bot sh

I can see the value for $SENTRY_DSN and is successfully set by Application.put_all_env at runtime.

but the sys.config which is in the build failed to fetch the values while building a release which means its not available to the build process

{sentry,[{dsn,nil},{included_environments,[prod,dev]},{environment_name,prod}]}

Seems this could be due to use of docker-compose wher its env_file only sets values inside the container and not in build process and using the docker command with command line vars is the way to build with runtime dependencies. If that is the case then how to do a build with docker-compose with runtime configs or maybe I got wrong docker-compose settings

what I understand the env variables set via env_file can only be available after container runs, and to do a elixir release the build would require ARGS being set that then are set as ENV in the build phase to be available as runtime variables for the release to use

docker_environment_build_args_overview%20(1)1494×545 105 KB

I think I have for runtime variables figured out for docker-compose. need to define the env variables on the build machine and add values via args to docker-compose and then refer to them in the Dockerfile as ARG which are then available to the build process.

thanks for your insights helped me put things in better order as newbie to elixir