darnahsan
Mutating Application env with put_env in containers, good or bad?
I have this slack bot app with an api to check for stats. As its containerised with docker. I was using env file via docker-compose. The app was using System.get_env to fetch values every time which obviously doesn’t sounds good to make a system level call for every incoming request. So I decided to put them in config file and as module level constants but for both the values are not available at runtime as they are set via docker-compose and are only available once the container is running.
One approach would be to embed those values in the Dockerfile or pass them along the build phase but that is same as embedding it in, which I don’t prefer. This missing values also causes issues with libraries like sentry where it depends on environment variables.
One way I solved it is upon application starting I call put_all_env and set the values from System.get_env and then use Application,.fetch_env!
so what I would like to know is if that is ok to do or are there any other practices for containers to have compile time and runtime values available for releases.
Marked As Solved
darnahsan
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.
Also Liked
axelson
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.
engineeringdept
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.
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Courses that'll move you from confusion to "Aha, now I get it!"
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Real-time error tracking, performance insights, and observability for devs.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
Courses that'll move you from confusion to "Aha, now I get it!"