#ruby #shell #nginx #environment #unicorn
#ruby #оболочка #nginx #Окружающая среда #unicorn
Вопрос:
Играя с Heroku, я нашел их подход к использованию переменных окружения для локальной конфигурации сервера блестящим. Теперь, настраивая собственный сервер приложений, я задаюсь вопросом, насколько сложно было бы это воспроизвести.
Я развертываю приложение sinatra, использующее Unicorn и Nginx. Я знаю, что nginx не любит играть со средой, так что этот вариант исключен. Вероятно, я могу поместить переменные где-нибудь в конфигурационном файле unicorn, но поскольку это находится под контролем версий вместе с остальной частью приложения, это как бы противоречит цели размещения конфигурации в серверной среде. Насколько я понимаю, нет причин не хранить файлы конфигурации для конкретного приложения вместе с остальной частью приложения.
Третий и последний (насколько мне известно) вариант — это установка их в порождающей оболочке. Вот где я заблудился. Я знаю, что оболочки login и non-login используют разные rc-файлы, и я не уверен, вызывает ли вызов чего-либо с sudo -u http stuff или нет оболочку login. Я сделал кое-какую домашнюю работу и спросил Google и man, но я все еще не совсем уверен, как к этому подойти. Может быть, я просто туплю … в любом случае, я был бы очень признателен, если бы кто-нибудь мог пролить некоторый свет на всю ситуацию с оболочкой.
Комментарии:
1. Способ, которым я это делаю, — поместить эти переменные в файл .bashrc, таким образом, когда я подключаюсь к серверу по ssh, я получаю эти переменные, установленные напрямую, без использования скрипта-оболочки, и они безопасны, потому что только человек, который может войти на сервер, может получить к ним доступ. Сценарий-оболочка полезен, если вы хотите развернуть свое приложение на нескольких серверах и задать множество переменных.
Ответ №1:
Я думаю, что ваша третья возможность на правильном пути. Чего вам не хватает, так это идеи скрипта-оболочки, единственной функцией которого является настройка среды, а затем вызов основной программы с любыми требуемыми параметрами.
Чтобы создать скрипт-оболочку, который может функционировать как сценарий управления (если prodEnv использует DB = ProdDB и т.д.), Есть еще одна часть, которая упрощает эту проблему. Оба Bash / ksh поддерживают функцию, называемую sourcing files. Это операция, которую предоставляет оболочка, чтобы открыть файл и выполнить то, что находится в файле, точно так же, как если бы это было встроено в основной скрипт. Как #include в C и других языках.
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 вверху. Когда вы в конечном итоге меняете физическое местоположение сервера (или его имя), у вас остается только одно место, которое вам нужно для внесения изменений.
Я
Ответ №2:
Также пара драгоценных камней, связанных с этим. figaro, который работает как с heroku, так и без него. Figaro использует файл yaml (в конфигурации и git игнорируется) для отслеживания переменных. Другим вариантом является dotenv, который считывает переменные из .env файла. А также другая статья со всеми этими опциями.
Ответ №3:
Чтобы создать интерактивную оболочку (также известную как login shell), вам нужно вызвать sudo следующим образом:
sudo -i -u <user> <command>
Также вы можете использовать -E для сохранения среды. Это позволит передавать некоторые переменные для вашей текущей среды в команду, вызываемую с помощью sudo.
Ответ №4:
Я решил аналогичную проблему, явно указав Unicorn прочитать файл переменных как часть запуска в его init.d скрипте. Сначала я создал файл в каталоге над корнем приложения под названием variables . В этом скрипте я вызываю export все мои переменные окружения, например, export VAR=value . Затем я определил переменную GET_VARS=source /path/to/variables в /etc/init.d/unicorn файле. Наконец, я изменил параметр «Пуск», чтобы читать, su - $USER -c "$GET_VARS amp;amp; $CMD" где $CMD — команда запуска, а $USER — пользователь приложения. Таким образом, переменные, определенные в файле, экспортируются в оболочку пользователя приложения Unicorn при запуске. Обратите внимание, что я использовал скрипт init.d, почти идентичный тому, что приведен в этой статье.