Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Add config providers #8957
This PR adds config providers to Elixir releases (see #8612).
It is a large-ish PR broken in two parts:
I will explore the rationale for each part next. Note this is still WIP (docs and tests missing) but I have submitted it so we can get the CI running and open up for feedback.
|use Mix.Config||import Config|
We have also added the
Config.Provider module which outlines the behaviour to be implemented by config providers. It is simply two functions. The
Config.Reader module itself is a provider that reads a single configuration file.
Adding config provider support to releases
We have added config providers support to releases using a restart-once approach. This is different from
relx that boot the VM twice. Instead, we only boot the VM once and restart the Erlang system once it has been configured. The trick is to rewrite the sys.config during after running config providers.
Therefore, to use config providers, we need writable permissions somewhere (which can be customizable with
RELEASE_TMP). If you don't use providers, you don't need write permission. Also, since config providers run when only a small part of the VM is started, they need to explicitly start any application they may need.
By default there is a single config provider which checks for
config/releases.exs is present, it will be automatically copied to your release and executed at runtime, the first time your release boots.
Unfortunately the current approach doesn't work on Windows because Windows only allows one
I like this very much, except for one thing - caching of the provider results. I think it will be very surprising and error prone.
Let's imagine a situation where you deploy to heroku with the new releases and providers that reads from system env, and the
@josevalim I double checked, there are write permissions inside the application directory, so that isn't an actual problem.
Caching the initial config and then not overwriting it when the environment changes, as @michalmuskala mentioned, would be enough to prevent Heroku users from using releases though.
Pushed docs for configuration here: https://github.com/elixir-lang/elixir/pull/8957/files#diff-53c844525c23fd1a21c03113baf7e781R335
ggcampinho left a comment
Really nice :) I really like the idea, I'm still trying to wrap my head around this, but one concern that I have is providing the current configuration back to the providers. The configuration can have sensitive data and this could be exposed by some malicious code in some cases, I believe.
My suggestion would be to always merge the configs provided by the provider instead of giving the freedom to the user to do that, but maybe I'm not foreseeing some user case.
I am not really worried about this. A config provider is regular Elixir code and as such it has access to absolutely everything. if you are worried about a bad config provider, the current config is the least of your concerns. :)