* Unicorn, environment variables, start and reload
@ 2015-04-23 9:05 Jérémy Lecour
2015-04-23 9:29 ` Eric Wong
0 siblings, 1 reply; 2+ messages in thread
From: Jérémy Lecour @ 2015-04-23 9:05 UTC (permalink / raw)
To: unicorn-public
Hi,
For some time I've been using Unicorn to serve Rails applications.
I've been increasingly relying on environment variables to set various
password and configuration bits outside of the application's code.
For that I've been using the "dotenv" gem that load a `.env` file into
the ENV hash. It's great and really useful in development mode, but
it's not a best practice to use it in production. Here is what Brandon
Keepers (maintainer of Dotenv) says about this :
> One of the reasons I don't advocate for using dotenv in production is because it loads the environment variables within the ruby process, which makes it very difficult to track which variables were previously set and which were loaded by dotenv. If you set these variables in the environment of your server (/etc/environment, /etc/profile, etc) then unicorn reloading will just work.
So I was wondering what would be the correct way to have environment
variables available in the Ruby process, up-to-date when the Unicorn
process is started and reloaded too (with USR2).
And there is also the case of various shell initializations
(login/non-login, interactive/non-interactive) and supervisors like
Monit that strip the environment to a minumum before executing the
start/stop commands.
I understand that I can do something like this on start :
$ source ~/my/app/.env && unicorn [...]
But what about the reload situation ?
Thanks for the help.
--
Jérémy Lecour :
http://jeremy.wordpress.com - http://twitter.com/jlecour
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: Unicorn, environment variables, start and reload
2015-04-23 9:05 Unicorn, environment variables, start and reload Jérémy Lecour
@ 2015-04-23 9:29 ` Eric Wong
0 siblings, 0 replies; 2+ messages in thread
From: Eric Wong @ 2015-04-23 9:29 UTC (permalink / raw)
To: Jérémy Lecour; +Cc: unicorn-public
Jérémy Lecour <jeremy.lecour@gmail.com> wrote:
> Hi,
>
> For some time I've been using Unicorn to serve Rails applications.
>
> I've been increasingly relying on environment variables to set various
> password and configuration bits outside of the application's code.
>
> For that I've been using the "dotenv" gem that load a `.env` file into
> the ENV hash. It's great and really useful in development mode, but
> it's not a best practice to use it in production. Here is what Brandon
> Keepers (maintainer of Dotenv) says about this :
>
> > One of the reasons I don't advocate for using dotenv in production is because it loads the environment variables within the ruby process, which makes it very difficult to track which variables were previously set and which were loaded by dotenv. If you set these variables in the environment of your server (/etc/environment, /etc/profile, etc) then unicorn reloading will just work.
Right, and some of these envs might not work unless they're set before
Ruby VM initialization. By the time the process can run Ruby code, it's
too late to setup most malloc behavior in any program or GC tuning for
Ruby.
I think most of the MRI-specific RUBY_* vars and most enviroment
variables used for any malloc tuning will fall into this group.
> So I was wondering what would be the correct way to have environment
> variables available in the Ruby process, up-to-date when the Unicorn
> process is started and reloaded too (with USR2).
>
> And there is also the case of various shell initializations
> (login/non-login, interactive/non-interactive) and supervisors like
> Monit that strip the environment to a minumum before executing the
> start/stop commands.
I set them in an init script (or whatever startup script/system I use).
I might also use "env -i" to clobber any existing environment if
I'm feeling really thorough, but usually I don't.
Most versions of Linux allow checking the environment by inspecting
/proc/$PID/environ (tr '\0' '\n' </proc/$PID/environ to convert
null-terminated to newlines). This may not reflect changes done inside
the process, though, so maybe have a private endpoint dump the contents
of ENV.
> I understand that I can do something like this on start :
>
> $ source ~/my/app/.env && unicorn [...]
>
> But what about the reload situation ?
You can change the ENV (or run any other Ruby) in the config file, but
most might not take effect until a new process is spawned (same with
dotenv). This means you may need USR2 for it to take effect.
I definitely keep ENV changes in the Ruby config file synched with
what's in the init script (and both in version control).
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2015-04-23 9:29 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-23 9:05 Unicorn, environment variables, start and reload Jérémy Lecour
2015-04-23 9:29 ` Eric Wong
Code repositories for project(s) associated with this public inbox
https://yhbt.net/unicorn.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).