while playing heroku, found approach of using environment variables server-local configuration brilliant. now, while setting application server of own, find myself wondering how hard replicate.
i'm deploying sinatra application, riding unicorn , nginx. know nginx doesn't play environment, one's out. can put vars somewhere in unicorn config file, since that's under version control rest of app, sort of defeats purpose of having configuration sit in server environment. there no reason not keep app-specific configuration files rest of app, far i'm concerned.
the third, , last (to knowledge) option, setting them in spawning shell. that's got lost. know login , non-login shells use different rc files, , i'm not sure whether calling sudo -u http stuff or not spawning login shell. did homework, , asked google , man, i'm still not entirely sure on how approach it. maybe i'm being dumb... either way, i'd appreciate if shed light on whole shell environment deal.
i think third possibility on right track. you're missing idea of wrapper script, function set environment , call main program whatever options required.
to make wrapper script can function control script (if prodenv use db=proddb, etc), there 1 more piece simplifies problem. bash/ksh both support feature called sourcing files. operation shell provides, open file , execute in file, if in-lined in main script. #include in c , other languages.
ksh , bash automatically source /etc/profile, /var/etc/profile.local (sometimes), $home/.profile. there other filenames picked up, in case, you'll need make own env file , explicitly load it.
as we're talking wrapper-scripts, , want manage how environment gets set up, you'll want sourcing inside wrapper script.
how source environment file?
envfile=/path/to/my/envfile . $envfile where envfile filled statements like
dbserver=devdbserver webserver=qawebserver .... you may discover need export these variable them visble
export dbserver webserver an alternate assignment/export supported
export dbserver=devdbserver export webserver=qawebserver depending on how non-identical different environments are, can have wrapper script figure out environment file load.
case $( /bin/hostame ) in prodservername ) envfile=/path/2/prod/envfile ;; qasevername ) envfile=/path/2/qa/envfile ;; devsevername ) envfile=/path/2/dev/envfile ;; esac . ${envfile} #now call program myprogram -v -f infile -o outfile ...... as develop more , more scripts in data processing environment, can alway source envfile @ top. when change physical location of server (or it's name), have 1 place need make change.
ihth
Comments
Post a Comment