This repository has been archived by the owner. It is now read-only.

Provide means of configuring release via environment variables #90

Closed
bitwalker opened this Issue Jan 2, 2015 · 20 comments

Comments

@bitwalker
Owner

bitwalker commented Jan 2, 2015

See original motivation here.

Just to follow up here with notes from the conversation @josevalim and I had in IRC this morning:

  • I'll add support for a new experimental config section system_env, which will contain app-specific configuration values which will be pulled from the system environment at boot time.
  • If a user has System.get_env calls in config.exs, but no system_env section, a warning will be generated notifying them that any runtime configuration which depends on the system environment should be moved to that section.
  • At boot time, the system_env section will be evaluated, and the environment values will be applied to the appropriate configuration settings via the -application flag when booting the VM.

An example of what the system_env section would look like in config.exs:

config :sasl,
  errlog_type: :error
config :phoenix,
  port: 8000

system_env: [
  phoenix: [ port: "PORT" ]
]

In this example, phoenix: port would be 8000, unless the PORT environment variable is defined, which takes precedence. In this way you can emulate the System.get_env("PORT") || Application.get_env(:phoenix, :port) behavior.

Thoughts everyone?

@guilleiguaran

This comment has been minimized.

Show comment
Hide comment
@guilleiguaran

guilleiguaran Jan 4, 2015

Contributor

👍 looks great for me

Contributor

guilleiguaran commented Jan 4, 2015

👍 looks great for me

@tsloughter

This comment has been minimized.

Show comment
Hide comment
@tsloughter

tsloughter May 8, 2015

Note that the start scripts that relx generates will replace os vars in sys.config and vm.args if the env variable RELX_REPLACE_OS_VARS is set when run.

Note that the start scripts that relx generates will replace os vars in sys.config and vm.args if the env variable RELX_REPLACE_OS_VARS is set when run.

@felipesere

This comment has been minimized.

Show comment
Hide comment
@felipesere

felipesere Aug 11, 2015

Any update on this? I need to use the environment variables for Docker.
Let me know if there is anything I can do to help.

Any update on this? I need to use the environment variables for Docker.
Let me know if there is anything I can do to help.

@edgurgel

This comment has been minimized.

Show comment
Hide comment
@edgurgel

edgurgel Aug 11, 2015

I'm using docker passing the .conf file as a volume

docker run -v /var/myapp.conf:/app/releases/1.0.0/myapp.conf

This way you can easily override the configuration file.

I'm using docker passing the .conf file as a volume

docker run -v /var/myapp.conf:/app/releases/1.0.0/myapp.conf

This way you can easily override the configuration file.

@felipesere

This comment has been minimized.

Show comment
Hide comment
@felipesere

felipesere Sep 18, 2015

@tsloughter can you explain how RELX_REPLACE_OS_VARS can be used here? I went through the code but I did not quite understand what to put where to allow it to be replaced...

Edit: Scratch that, I found out how to use it and its awesome.
Things that should be configured at runtime with ENV vars need to be replaced with "${VARIABLE_NAME}" and then make sure at boot time the option RELX_REPLACE_OS_VARS is set to true and you are good to go.

@tsloughter can you explain how RELX_REPLACE_OS_VARS can be used here? I went through the code but I did not quite understand what to put where to allow it to be replaced...

Edit: Scratch that, I found out how to use it and its awesome.
Things that should be configured at runtime with ENV vars need to be replaced with "${VARIABLE_NAME}" and then make sure at boot time the option RELX_REPLACE_OS_VARS is set to true and you are good to go.

@tsloughter

This comment has been minimized.

Show comment
Hide comment
@tsloughter

tsloughter Sep 18, 2015

It is part of the extended_start_script. It'll replace vars in sys.config and vm.args of the form ${VARIABLE}.

It is part of the extended_start_script. It'll replace vars in sys.config and vm.args of the form ${VARIABLE}.

@xtagon

This comment has been minimized.

Show comment
Hide comment
@xtagon

xtagon Sep 19, 2015

Since this method makes you declare it as [port: "PORT"] instead of as a custom expression (e.g. System.get_env("PORT")), how do we handle the case where one might wish to cast the ENV variable? All ENV variables are strings but some app configurations might want to parse them as integers, or lists of strings, etc.

xtagon commented Sep 19, 2015

Since this method makes you declare it as [port: "PORT"] instead of as a custom expression (e.g. System.get_env("PORT")), how do we handle the case where one might wish to cast the ENV variable? All ENV variables are strings but some app configurations might want to parse them as integers, or lists of strings, etc.

@artburkart

This comment has been minimized.

Show comment
Hide comment
@artburkart

artburkart Sep 28, 2015

@edgurgel - would your solution work in production?

@edgurgel - would your solution work in production?

@edgurgel

This comment has been minimized.

Show comment
Hide comment
@edgurgel

edgurgel Sep 28, 2015

@artburkart, yes it does! It's simply mounting the file where the configuration is and where exrm will read it.

@artburkart, yes it does! It's simply mounting the file where the configuration is and where exrm will read it.

@shadabahmed

This comment has been minimized.

Show comment
Hide comment
@shadabahmed

shadabahmed Jan 22, 2016

I was looking for exactly the same thing. 👍 Will wait for the release 😄

I was looking for exactly the same thing. 👍 Will wait for the release 😄

@emilsoman

This comment has been minimized.

Show comment
Hide comment
@emilsoman

emilsoman Feb 9, 2016

@xtagon What I would do is, make everything strings , so that all configuration happens using strings - whether they are in environment variables or in the config file. I would add a wrapper module that parses these strings into appropriate types.

@xtagon What I would do is, make everything strings , so that all configuration happens using strings - whether they are in environment variables or in the config file. I would add a wrapper module that parses these strings into appropriate types.

@emilsoman

This comment has been minimized.

Show comment
Hide comment
@emilsoman

emilsoman Feb 9, 2016

@bitwalker I like your idea 👍 . Have you been able to add support for this yet ?

@bitwalker I like your idea 👍 . Have you been able to add support for this yet ?

@bitwalker

This comment has been minimized.

Show comment
Hide comment
@bitwalker

bitwalker Feb 18, 2016

Owner

Just an update for those watching, I haven't had a chance to tackle this yet, but I'm planning on doing so before releasing 1.0 proper.

Owner

bitwalker commented Feb 18, 2016

Just an update for those watching, I haven't had a chance to tackle this yet, but I'm planning on doing so before releasing 1.0 proper.

@emilsoman

This comment has been minimized.

Show comment
Hide comment
@emilsoman

emilsoman Feb 19, 2016

Thanks for the update

On 19 February 2016 at 01:37, Paul Schoenfelder notifications@github.com
wrote:

Just an update for those watching, I haven't had a chance to tackle this
yet, but I'm planning on doing so before releasing 1.0 proper.


Reply to this email directly or view it on GitHub
#90 (comment).

Thanks for the update

On 19 February 2016 at 01:37, Paul Schoenfelder notifications@github.com
wrote:

Just an update for those watching, I haven't had a chance to tackle this
yet, but I'm planning on doing so before releasing 1.0 proper.


Reply to this email directly or view it on GitHub
#90 (comment).

@edevil

This comment has been minimized.

Show comment
Hide comment
@edevil

edevil Mar 1, 2016

Was this included? It is not in the changelog.

edevil commented Mar 1, 2016

Was this included? It is not in the changelog.

@bitwalker

This comment has been minimized.

Show comment
Hide comment
@bitwalker

bitwalker Mar 1, 2016

Owner

@edevil No it wasn't, I needed to bump the version to 1.0 before making any further changes, because I couldn't justify calling further releases "release candidates" for 1.0.

Owner

bitwalker commented Mar 1, 2016

@edevil No it wasn't, I needed to bump the version to 1.0 before making any further changes, because I couldn't justify calling further releases "release candidates" for 1.0.

@werbitzky

This comment has been minimized.

Show comment
Hide comment

+1!! :)

@tslater

This comment has been minimized.

Show comment
Hide comment

tslater commented May 7, 2016

+1

@BryanJBryce

This comment has been minimized.

Show comment
Hide comment

+1

@denisw

This comment has been minimized.

Show comment
Hide comment
@denisw

denisw Mar 28, 2018

Any progress on this? I know that there are workarounds, but having a direct solution for boot-time environment variables would remove one roadblock for creating cobfigurable Docker images.

denisw commented Mar 28, 2018

Any progress on this? I know that there are workarounds, but having a direct solution for boot-time environment variables would remove one roadblock for creating cobfigurable Docker images.

@bitwalker bitwalker closed this Apr 6, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.