Ruby, Unicorn и переменные окружения - PullRequest
Новая
       20

Ruby, Unicorn и переменные окружения

11 голосов
/ 30 апреля 2011

Играя с Heroku, я обнаружил, что их подход к использованию переменных среды для локальной конфигурации сервера блестящий.Теперь, когда я настраиваю собственный сервер приложений, я задаюсь вопросом, как трудно это будет реплицировать.

Я развертываю приложение sinatra, использую Unicorn и Nginx.Я знаю, что nginx не любит играть с окружающим миром, так что вы не можете.Я, вероятно, могу поместить vars где-нибудь в конфигурационном файле единорога, но, поскольку он находится под контролем версий с остальной частью приложения, он как бы не справляется с необходимостью настройки в серверной среде.Насколько мне известно, нет причин не хранить файлы конфигурации моего приложения вместе с остальной частью приложения.

Третий и последний (насколько мне известно) параметр - это их настройка.в нерестовой раковине.Вот где я заблудился.Я знаю, что в оболочках входа и не входа в систему используются разные rc-файлы, и я не уверен, является ли вызов чего-то с sudo -u http stuff порождением оболочки входа в систему.Я сделал некоторую домашнюю работу и спросил Google и человека, но я все еще не совсем уверен, как подойти к нему.Может быть, я просто тупой ... в любом случае, я был бы очень признателен, если бы кто-то смог пролить свет на всю сделку с оболочкой.

Ответы [ 4 ]

7 голосов
/ 13 мая 2011

Я думаю, что ваша третья возможность находится на правильном пути. Что вам не хватает, так это идея сценария-обертки, единственная функция которого - установить среду и затем вызвать основную программу с любыми необходимыми параметрами.

Чтобы создать скрипт-обертку, который может функционировать как скрипт управления (если prodEnv использует DB = ProdDB и т. Д.), Есть еще одна часть, которая упрощает эту проблему. Оба bash / ksh поддерживают функцию, называемую источником файлов. Это операция, которую обеспечивает оболочка, чтобы открыть файл и выполнить то, что находится в файле, так же, как если бы оно было встроено в основной скрипт. Как и #include в Си и других языках.

ksh и bash автоматически получат /etc/profile, /var/etc/profile.local (иногда), $HOME/.profile. Существуют и другие имена файлов, которые также будут выбраны, но в этом случае вам нужно будет создать свой собственный файл env и явно загрузить его.

Поскольку мы говорим о сценариях-обёртках и вы хотите управлять настройкой среды, вам нужно будет выполнить поиск внутри сценария-обертки.

Как получить файл среды? 

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

где envFile будет заполнен такими операторами, как 

dbServer=DevDBServer
webServer=QAWebServer
....

вы можете обнаружить, что вам нужно экспортировать эти переменные, чтобы они были видимыми 

export dbServer webServer

Поддерживается альтернативное назначение / экспорт 

export dbServer=DevDBServer
export webServer=QAWebServer

В зависимости от того, насколько неидентичны ваши разные среды, ваш скрипт-оболочка может определить, какой файл среды загружать. 

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 вверху. Когда вы в конечном итоге меняете физическое местоположение сервера (или его имя), у вас есть только одно место, в котором вам нужно внести изменения.

IHTH

1 голос
/ 18 декабря 2013

Также пара драгоценных камней, занимающихся этим. figaro , который работает как с герою, так и без нее. Figaro использует файл yaml (в config и git игнорируется) для отслеживания переменных. Другой вариант - dotenv , который читает переменные из файла .env. А также еще одна статья со всеми их опциями.

0 голосов
/ 02 марта 2015

Я решил аналогичную проблему, явно указав Unicorn читать файл переменных как часть запуска в его сценарии init.d. Сначала я создал файл в каталоге над корнем приложения с именем variables. В этом сценарии я вызываю export для всех переменных среды, например, export VAR=value. Затем я определил переменную GET_VARS=source /path/to/variables в файле /etc/init.d/unicorn. Наконец, я изменил параметр запуска, чтобы прочитать su - $USER -c "$GET_VARS && $CMD", где $CMD - команда запуска, а $USER - пользователь приложения. Таким образом, переменные, определенные в файле, при запуске экспортируются в оболочку пользователя приложения Unicorn. Обратите внимание, что я использовал скрипт init.d, почти идентичный скрипту из этой статьи .

0 голосов
/ 16 мая 2011

Чтобы создать интерактивную оболочку (a.k.a. login shell), вам нужно вызвать sudo следующим образом: 

sudo -i -u <user> <command>

Также вы можете использовать -E для защиты окружающей среды. Это позволит перенести некоторые переменные для вашей текущей среды в команду, вызываемую с помощью sudo.

...