Ruby,Unicorn和环境变量 [英] Ruby, Unicorn, and environment variables

查看:126
本文介绍了Ruby,Unicorn和环境变量的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在与Heroku一起玩耍时,我发现他们使用环境变量进行服务器本地配置的方法非常出色.现在,在设置自己的应用程序服务器时,我发现自己想知道要复制的难度有多大.

While playing with Heroku, I found their approach of using environment variables for server-local configuration brilliant. Now, while setting up an application server of my own, I find myself wondering how hard that would be to replicate.

我正在部署Unicorn和Nginx的sinatra应用程序.我知道nginx不喜欢与环境一起玩,所以出门了.我可能可以将vars放在unicorn配置文件中的某个位置,但是由于该代码受应用程序其余部分的版本控制,因此有点违反了将配置放在服务器环境中的目的.就我而言,没有理由不将我特定于应用程序的配置文件与该应用程序的其余部分保存在一起.

I'm deploying a sinatra application, riding Unicorn and Nginx. I know nginx doesn't like to play with the environment, so that one's out. I can probably put the vars somewhere in the unicorn config file, but since that's under version control with the rest of the app, it sort of defeats the purpose of having the configuration sit in the server environment. There is no reason not to keep my app-specific configuration files together with the rest of the app, as far as I'm concerned.

第三个也是最后一个(据我所知)是将它们设置在生成的外壳中.那是我迷路的地方.我知道登录外壳程序和非登录外壳程序使用不同的rc文件,并且我不确定用sudo -u http stuff调用某些内容是否会生成登录外壳程序.我做了一些功课,问谷歌和人,但我仍然不确定如何处理它.也许我只是愚蠢……无论如何,如果有人可以对整个Shell环境交易有所了解,我将非常感激.

The third, and last (to my knowledge) option, is setting them in the spawning shell. That's where I got lost. I know that login and non-login shells use different rc files, and I'm not sure whether calling something with sudo -u http stuff is or not spawning a login shell. I did some homework, and asked google and man, but I'm still not entirely sure on how to approach it. Maybe I'm just being dumb... either way, I'd really appreciate it if someone could shed some light on the whole shell environment deal.

推荐答案

我认为您的第三种可能性是正确的.您所缺少的是包装脚本的概念,该脚本的唯一功能是设置环境,然后使用所需的任何选项来调用主程序.

I think your third possibility is on the right track. What you're missing is the idea of a wrapper script, whose only function is to set the environment and then call the main program with whatever options are required.

要制作一个可用作控制脚本的包装器脚本(如果prodEnv使用DB = ProdDB等),还有另外一个片断可以简化此问题. Bash/ksh都支持一种称为源文件的功能.外壳程序提供的此操作可打开文件并执行文件中的内容,就像在主脚本中内联一样.类似于C语言和其他语言中的#include.

To make a wrapper script that can function as a control script (if prodEnv use DB=ProdDB, etc), there is one more piece that simplifies this problem. Bash/ksh both support a feature called sourcing files. This an operation that the shell provides, to open a file and execute what is in the file, just as if it was in-lined in the main script. Like #include in C and other languages.

ksh和bash将自动获取/etc/profile/var/etc/profile.local(有时)和$HOME/.profile.还有其他文件名也可以使用,但是在这种情况下,您需要创建自己的env文件并显式加载它.

ksh and bash will automatically source /etc/profile, /var/etc/profile.local (sometimes), $HOME/.profile. There are other filenames that will also get picked up, but in this case, you'll need to make your own env file and the explicitly load it.

在我们讨论包装脚本时,要管理环境的设置方式,您需要在包装脚本中进行采购.

As we're talking about wrapper-scripts, and you want to manage how your environment gets set up, you'll want to do the sourcing inside the wrapper script.

如何获取环境文件?

envFile=/path/to/my/envFile  
. $envFile

其中的envFile中将填充类似的语句

where envFile will be filled with statements like

dbServer=DevDBServer
webServer=QAWebServer
....

您可能会发现您需要导出这些变量才能使其可见

you may discover that you need to export these variable for them to be visble

export dbServer webServer

支持备用分配/导出

export dbServer=DevDBServer
export webServer=QAWebServer

根据不同环境的不完全相同,可以让包装器脚本找出要加载的环境文件.

Depending on how non-identical your different environments are, you can have your wrapper script figure out which environment file to 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 your program
myProgram -v -f inFile -o outFile ......

随着您在数据处理环境中开发越来越多的脚本,可以始终在顶部始终source您的envFile.最终更改服务器的物理位置(或名称)时,只有一个地方需要更改.

As you develop more and more scripts in your data processing environment, you can alway source your envFile at the top. When you eventually change the physical location of a server (or it's name), then you have only one place that you need to make the change.

IHTH

这篇关于Ruby,Unicorn和环境变量的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆