Переменные среды или файлы конфигурации YAML

Question

Фон:
Шаг 1 -> У нас есть окно, которое запускает модульные и функциональные тесты приложения, выполняя его в тестовом режиме с определенной конфигурацией.
Шаг 2 -> После успешного выполнения шага 1 мы запускаем интеграционные тесты приложения, запуская его в тестовом режиме с другим набором конфигурации в другом окне.
Шаг 3 -> После успешного выполнения шага 2 мы запускаем тесты производительности приложения, запуская его в производственном режиме в окне тестирования производительности.
Шаг 4 -> После успешного выполнения шага 3 сборка считается стабильной, и поле UAT обновляется с помощью этой базы кода, а приложение запускается в рабочем режиме для проверки и обратной связи с клиентом. Шаг 5 -> С GO от клиента, производственная коробка обновляется с помощью базы кода.

Теперь из вышеперечисленных шагов мы видим, что на шагах 1 и 2 приложение работает в тестовом режиме и имеет другую конфигурацию. Аналогично обстоит дело с шагами 3,4 и 5.

Какая практика рекомендуется в таких ситуациях? У нас были файлы конфигурации YAML, но лично я чувствовал, что поддерживать множество файлов конфигурации не имеет смысла. И вот, я изменился с практики
"Файл конфигурации для среды"
до
"Файл конфигурации в режиме rails, вывод переменных в среду linux" .

Я на правильном пути? Разве мои действия не упрощают вещи?

Каковы плюсы и минусы этих двух подходов?

Answer 1

По моему опыту, переменные среды являются опцией конфигурации последней инстанции. Они, безусловно, имеют свое место, но приложения должны в первую очередь проверять некоторые другие более надежные и явно преднамеренные параметры конфигурации. Я настоятельно рекомендую загружать конфигурацию из файла YAML и использовать только переменную окружения в качестве запасного варианта. Всегда предполагайте, что ваша переменная окружения будет применяться ко всему общесистемному, и предположите, что она будет случайно сброшена или установлена ​​в неправильное значение в какой-то момент. т. е. ваше приложение не должно фиксировать seppuku, потому что для некоторого каталога конфигурации установлено значение /, и у него нет разрешений на него (или, что еще хуже, вы стираете диск, потому что приложение работало как root). Или, более вероятно, что-то вроде вашего RAILS_ENV было установлено на test, когда это должно было быть production, и никто не понял, и теперь пользователи записывают данные в неправильное место или на /dev/null из-за всех 500-х. .

Лично мне нравится отбрасывать logger.warn сообщений каждый раз, когда я возвращаюсь к переменной среды для значения конфигурации.

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

Answer 2

После тщательного тщательного поиска в Google, обсуждения с некоторыми людьми из Rails и мозгового штурма, я внес изменения в код, так что у меня есть "файл конфигурации для режима rails, выводящий конфигурации приложения в файл YML , которая в моем случае остается вне среды Rails "

Следуйте понятным фрагментам кода, чтобы понять, как я этого добиваюсь простым способом. Быстрое объяснение состоит в том, что фрагмент кода в файле environment.rb считывает файл YAML из системы, чтобы скопировать все пары ключ-значение в хеш Rails ENV. Этот хэш ENV доступен везде, пока / вкл / после загрузки приложения.

File: config/environment.rb
# Mechanism to load all application related configurations
$CONFIG_FILE = "/var/myapp/config/jsconfig.yml"
require 'yaml'
APP_CONFIG = YAML.load_file($CONFIG_FILE)
APP_CONFIG.each do |key, value|
  ENV[key] = value
end

#3rd Party Server's (that my application is using) Configurations here...
3RD_PARTY_SERVER_URL = ENV['3rd_party_webservice_endpoint_url']
3RD_PARTY_SERVER_CREDENTIALS = {:username => ENV['3rd_party_server_username'], :password=> ENV['3rd_party_server_password']}


File: /var/myapp/config/jsconfig.yml
3rd_party_webservice_endpoint_url: url
3rd_party_server_username: username
3rd_party_server_password: password
myapp_db_url: jdbc:oracle:thin:@localhost:1521:XE
myapp_db_username: kartz
myapp_db_password: rails_savvy


File: /var/myapp/config/database.yml
development:
  adapter: oracle_enhanced
  url: <%= ENV['myapp_db_url'] %>
  username: <%= ENV['myapp_db_username'] %>
  password: <%= ENV['myapp_db_password'] %>
  encoding: utf8

test:
  adapter: oracle_enhanced
  url: <%= ENV['myapp_db_url'] %>
  username: <%= ENV['myapp_db_username'] %>
  password: <%= ENV['myapp_db_password'] %>
  encoding: utf8

production:
  adapter: oracle_enhanced
  url: <%= ENV['myapp_db_url'] %>
  username: <%= ENV['myapp_db_username'] %>
  password: <%= ENV['myapp_db_password'] %>
  encoding: utf8

Более подробную информацию об этом можно найти в моем блоге: https://blog.codonomics.com/2011/02/externalizing-all-application-specific.html

Answer 3

В моей компании у нас действительно есть и то и другое.

У нас есть приложение Rails, которое может указывать на одну из множества различных установок другого программного обеспечения и использовать API из этой установки. Чтобы указать установку, необходимо установить около 5 переменных.

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

Итак, теперь у нас есть одна переменная среды, которую мы называем ENV_TOKEN, и у нас есть файлы yaml, которые содержат записи, соответствующие действительным переменным ENV_TOKEN, и код в config / initializer, который устанавливает ENV [ключ] = значение.

Итак, допустим, у меня есть переменные "FOO" и "BAR", которые я хочу установить в "one" и "two" соответственно. Я мог бы создать файл yaml, который содержит:

carolclarinet:
  FOO: one
  BAR: two

и тогда я установлю переменную окружения ENV_TOKEN на carolclarinet, а FOO и BAR - на один и два.

Я понятия не имею, если это лучший способ сделать это, но это работает для нас.

ETA: обратите внимание, что это только для разработки и тестирования, установщик нашего программного обеспечения заботится о настройке всего этого, чтобы наши клиенты никогда не меняли переменные среды.