kostya / eye

Process monitoring tool. Inspired from Bluepill and God.
MIT License
1.19k stars 86 forks source link

Environment variables question #124

Closed duhast closed 9 years ago

duhast commented 9 years ago

Hello @kostya! I have a problem passing env vars to the daemon. Can you please help?

I have system-wide Ruby 2.2.1 installed on my server and I want to make a system-wide eye installaion.

Eye is launched from an upstart job by loading a generic config:

Eye.config do
  logger '/var/log/eye/eye.log'
end

Also I have some global (as turned out, not so global) env vars declared in /etc/environment like:

RAILS_ENV=staging
SOME_API_KEY=blahblah

And I want eye daemon to use these vars. First problem is that upstart cannot source /etc/environment for some reason:

start on runlevel [2345]
stop on runlevel [016]
expect fork
kill timeout 60
setuid deploy
env HOME=/home/deploy
respawn
console log
script
  . /etc/environment
  exec /usr/local/bin/eye load /home/deploy/init.eye
  exec for f in /etc/eye/*.eye; do /usr/local/bin/eye load $f; done
end script

pre-stop script
  /usr/local/bin/eye quit --stop_all 
end script

I've tried various approaches to achieve the goal, but none of them succeeded. In any case, when eye is launched by upstart the ENV contains only few vars (i'm checking by loading an eye config with a single raise ENV.inspect line):

{
"UPSTART_INSTANCE"=>"", 
"HOME"=>"/home/deploy", 
"UPSTART_JOB"=>"eye", 
"TERM"=>"linux", 
"PATH"=>"/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin", "PWD"=>"/"
}

But when I quit eye daemon launched by upstart and re-load same config (which also starts the deamon from an SSH session), everything is fine:

{
"SOME_API_KEY"=>"blahblah",
"SHELL"=>"/bin/bash",
"TERM"=>"xterm-256color",
"SSH_TTY"=>"/dev/pts/0",
"RAILS_ENV"=>"staging"
...
"MONGODB_URL"=>"mongodb://localhost:27017/mydb"
}

So my question is do you have an idea how to set global environment variables for a system-wide eye installation backed by upstart in the way they will be accessible by all configs loaded later?

kostya commented 9 years ago

i write about using env variables here https://github.com/kostya/eye/wiki/Using-ENV-variables-in-config

i think your generic config can be like this:

Eye.config do
  logger '/var/log/eye/eye.log'
end

Eye.application '__default__' do
  load_env "/etc/environment"
end

application __default__ just add options for every applications. load_env loads environment from dotenv file.

then load some application:

Eye.application :some do
  # here you would have already
  # env 'RAILS_ENV' => 'staging', 'SOME_API_KEY' => 'blahblah'
end

btw not need to write exec for f in /etc/eye/*.eye; do /usr/local/bin/eye load $f; done just write /usr/local/bin/eye load /etc/eye/

duhast commented 9 years ago

Cool, that's exactly what i need!

But it look like env is not persisted after the load_env call:

deploy@staging-test5:/var/www/app_staging/current$ cat /var/log/eye/eye.log | grep load_env
01.04.2015 19:26:14 INFO  -- [<Eye::Dsl::ApplicationOpts>] load_env from '/etc/environment'
deploy@staging-test5:/var/www/app_staging/current$ eye xinfo -c
---
:settings:
  :logger:
  - "/var/log/eye/eye.log"
:applications: {}

Any suggestions?

kostya commented 9 years ago

oh, seems __default__ is works only in per one load, as temporary data, which is may be bad. And i think need to store it to the config.

this should work:

eye load /home/deploy/init.eye /etc/eye/

or right now, until i fix it, you can do it in every app:

Eye.application :some do
  load_env "/etc/environment"
end
duhast commented 9 years ago

Ok, and is there a way to access data loaded by load_env from inside the config? I'm using a custom notificator which needs an API key declared in env vars.

kostya commented 9 years ago

no, need little to refactor it :) https://github.com/kostya/eye/blob/master/lib/eye/dsl/opts.rb#L184

until that you can use this gem https://github.com/bkeepers/dotenv

duhast commented 9 years ago

It looks like dotenv doesn't suits well for my purpose, so I'll put a костыль :blush: until you'll have the __default__ application settings fixed.

Thanks for your help!

duhast commented 9 years ago

Hi @kostya! Any update on this?

duhast commented 9 years ago

Thanks!