Ответ 1
Вы можете использовать dotenv gem, который загружает файл .env в качестве переменных окружения. Вы можете сгенерировать файл .env для разных сред и не обязательно должны быть проверены в вашем репозитории.
Я пытался настроить систему, похожую на heroku, где я буду хранить секретные ключи в переменных окружения, а затем получить к ним доступ из моего приложения rails следующим образом:
secret = ENV['EMAIL_PASSWORD']
Я знаю, что heroku позволяет вам делать heroku config:add EMAIL_PASSWORD=secret
, и я хотел сделать что-то подобное для моего собственного ящика ubuntu, использующего nginx и Passenger.
Должен ли я добавлять эти переменные как export
в .bashrc
или .bash_login
, чтобы при перезагрузке системы эти переменные автоматически устанавливались?
Я не уверен, когда каждый из этих файлов читается.
Вы можете использовать dotenv gem, который загружает файл .env в качестве переменных окружения. Вы можете сгенерировать файл .env для разных сред и не обязательно должны быть проверены в вашем репозитории.
Имейте в виду, что nginx может не работать в той же среде, что и вы, и обычно (произносится как "Apache" ) мы добавляем env-vars в конфигурационный файл сервера через SetEnv. Тем не менее, nginx не имеет такой функции... и не нуждается в ней, я полагаю.
sudo -E /usr/local/sbin/nginx
При запуске nginx для того, чтобы он знал ваши собственные env vars пользователя.
Или, проверьте команду env
(см. здесь):
env EMAIL_PASSWORD=secret
Чтобы ответить на ваш вопрос, да, вы должны использовать операторы export
в конфигурационных файлах оболочки.
(это, вероятно, слишком много, но, возможно, это будет полезно)
Некоторые вещи, которые нужно иметь в виду:
Переменные среды несколько общедоступны и могут быть замечены другими процессами так же легко, как добавлена опция команды ps(1)
(например, ps e $$
в bash) или смотрите /proc/*/environ
, хотя оба ограничены в по крайней мере, для одного и того же пользователя (или root) на современных системах. Не полагайтесь на их секретность, если у вас есть еще один довольно простой вариант.
~/.bashrc
- это неправильное место для переменных среды, поскольку они могут быть вычислены один раз при входе в систему ~/.bash_login
, ~/.bash_profile или ~/.profile
, в зависимости от вашего использования, и передаются во все потоковые оболочки. Напротив, действия ~/.bashrc
, как правило, пересчитываются при каждом вызове оболочки (если явно не отключено).
Ввод bash кода в ~/.profile
может путать другие оболочки sh-descendent и инструменты без оболочки, которые пытаются прочитать этот файл, поэтому наличие bash -специфического ~/.bash_login
или -_profile содержит bash -специфические вещи и используя . ~/.profile
для более общих вещей (LESS, EDITOR, VISUAL, LC_COLLATE, LS_COLORS и т.д.), дружелюбнее к другим инструментам.
Переменные окружения в ~/.profile
должны находиться в старой форме оболочки Bourne (VAR=value ; export VAR
). В Linux это обычно не критично, хотя в других Unixen это может быть большой проблемой, когда старая версия "sh" пытается их прочитать.
Некоторые сеансы X будут читать только ~/.profile
, а не ~/.bash_login
или другие, упомянутые выше. Некоторые будут искать файл ~/.xsession
, который должен быть изменен, чтобы иметь . $HOME/.profile
, если он уже не так.
Общесистемные настройки будут помещаться вместо чего-то вроде /etc/profile.d/similar-to-heroku.sh
. Обратите внимание, что ".sh" присутствует только после того, как файл будет использоваться с ".". или "source" - сценарии оболочки никогда не должны иметь расширений с именами команд в любой форме Unix/Linux.
Большинство переменных окружения перегружаются, когда один sudo
используется для root, как указывает ybakos. Подобные проблемы появляются в crontabs, на рабочих местах и т.д. Когда возникают сомнения, добавление env | sort > /tmp/envvars
или тому подобное подозреваемого script может действительно помочь в отладке.
Помните, что в некоторых дистрибутивах сценарии запуска оболочки так искажены, что они фактически игнорируют порядок, указанный на странице руководства bash (1). Каждый раз, когда вы обнаруживаете, что пользователь по умолчанию ~/.profile
по умолчанию для $BASH или $BASH_VERSION, вы можете быть в одной из этих, um..., "интересных" окружений и, возможно, придется прочитать их, чтобы выяснить, где элемент управления (они должны использовать bash -специфический ~/.bash_profile
или ~/.bash_login
, который включает в себя более общий ~/.profile
по ссылке, таким образом позволяя исполняемому файлу bash выполнять работу вместо того, чтобы писать $BASH проверяет код оболочки).
~/.bash_profile
(или ~/.bash_login
), безусловно, может включать . ~/.bashrc
, но переменные окружения относятся к ~/.bash_profile
(если bash -специфический) или ~/.profile
, включенным в него (если вы используя этот механизм и у меня есть envvars для всего остального), как говорит DeWitt, просто не забудьте поставить . ~/.bashrc
ПОСЛЕ .bash_profile . ~/.profile
и другие переменные среды, чтобы как логин, так и все другие вызовы ~/.bashrc
могли полагайтесь на уже установленные envvars. Пример ~/.bash_profile
:
# .bash_profile
[ -r ~/.profile ] && . ~/.profile # envvars
[ -r ~/.bashrc ] && . ~/.bashrc # functions, per-tty settings, etc.
#---eof
[ -r ... ] && ...
работает в любом потоке оболочки Bourne и не вызывает ошибок/прерываний, если отсутствует .profile(у меня лично есть настройка ~/.profile.d/*.sh
, но это остается полностью необязательным упражнением).
Обратите внимание, что bash только считывает первый файл этих трех, который он находит:
~/.bash_profile
~/.bash_login
~/.profile
... поэтому, если у вас есть это, использование двух других полностью контролируется пользователем, с точки зрения bash.
Это описано в nginx. Он удаляет все переменные среды кроме TZ
при запуске рабочих. Если вы хотите добавить переменную окружения, добавьте следующее в top конфигурации nginx:
# The top of the configuration usually has things like:
user user-name;
pid pid-file-name;
# Add to this:
env VAR1=value1;
env VAR2=value2;
# OR simply add:
env VAR1;
# To inherit the VAR1 from whatever you set in bash
Нормальный export
или что-либо, что вы делаете в bash, не гарантирует получение переданного nginx из-за того, как написаны сценарии инициализации (мы не знаем, используете ли они sudo с чистым окружающей среды и т.д.). Поэтому я предпочел бы разместить их в самом файле конфигурации nginx, а не в зависимости от оболочки, чтобы сделать это.
Изменить: Исправить ссылку
У меня есть папка script в /usr/local/bin
, которая устанавливает некоторые env vars, а затем выполняет Ruby. Я определяю путь к Ruby в моем (Apache, а не Nginx) файле conf этому файлу в /usr/local/bin
.
Пример:
#!/bin/sh
# setup env vars here
export FOO=bar
export PATH_TO_FOO=/bar/bin
export PATH=$PATH:PATH_TO_FOO
# and execute Ruby with any arguments passed to this script
exec "/usr/bin/ruby" "[email protected]"
Вы должны прочитать этот ответ на другой вопрос, это поможет:
Я поместил их в свою конфигурацию nginx, в частности, в определение сервера для приложения, используя команду passenger_env_var
:
server { server_name www.foo.com; root /webapps/foo/public; passenger_enabled on; passenger_env_var DATABASE_USERNAME foo_db; passenger_env_var DATABASE_PASSWORD secret; passenger_env_var SECRET_KEY_BASE the_secret_keybase; }
Это работает для меня. Для получения дополнительной информации см. Phusion-пассажир docs.
EDITED:
Хорошо жаль, что я прочитал его слишком быстро, вы можете проверить, как сохранить переменные ENV здесь:
https://help.ubuntu.com/community/EnvironmentVariables
http://www.cyberciti.biz/faq/set-environment-variable-linux/
Если вы используете Nginx как сервер на локальном компьютере, вы можете определить свою переменную env в файле конфигурации nginx.
location / {
...
fastcgi_param EMAIL_PASSWORD secret; #EMAIL_PASSWORD = secret
...
}
Я использую rbenv в качестве менеджера версий. Хорошим решением для хранения переменных среды для проекта была установка плагина rbenv-vars и помещение их в файл .rbenv-vars
.
Вот полезный пост:
Развертывание переменных ENV приложения с помощью Rbenv, Passenger и Capistrano
Для тех, кто сражается с использованием RVM. Убедитесь, что файл настроек по умолчанию включает файлы вашего пользователя .bashrc и .profile.
file: $rvm_path/environments/default
чтобы найти путь, выполните следующую команду:
ls -lah `whereis rvm`/environments/default
добавьте эти две строки перед первой строкой в этом файле:
source $HOME/.bashrc
source $HOME/.profile
В случае, если у кого-то был такой же вопрос, как у меня, вот небольшая записка о разных файлах .bash*
: http://www.joshstaiger.org/archives/2005/07/bash_profile_vs.html
Вкратце:
По большей части:
.bash_profile
считывается при входе в компьютер и .bashrc
считывается при запуске нового терминала. Для Mac OSX .bash_profile
читается каждое окно терминала, которое вы запускаете.
Итак, рекомендуемая процедура заключается в источнике .bashrc
от .bash_profile
, поэтому все переменные устанавливаются при входе в компьютер. Просто добавьте это в .bash_profile
:
if [ -f ~/.bashrc ]; then
source ~/.bashrc
fi
Вам нужно добавить строки экспорта в файл .profile в вашей домашней папке...
Переменные окружения устанавливаются при входе в систему...