2013-11-18 3 views
5

В моем эластичном бобовом стебле - варианты контейнера. RACK_ENV установлен в staging.Почему Пассажир смотрит на промежуточную среду?

В самом деле, если я SSH в экземпляр EC2 и сделать rails console в /var/app/current/, а затем ввести Rails.env возвращает staging.

Чтение http://www.modrails.com/documentation/Users руководства Nginx.html # RackEnv

Он говорит, чтобы установить RACK_ENV переменные, так как по умолчанию, значение production.

Вы бы предположить, все будет работать, за исключением бревен Elastic Beanstalk, он говорит:

[ 2013-11-18 14:28:26.4677 8061/7fb5fe01a700 Pool2/Implementation.cpp:1274 ]: [App 7428 stdout] PG::ConnectionBad (FATAL: database "foobar_production" does not exist 

foobar_production база данных не существует, но foobar_staging делает. Так почему Пассажир все еще смотрит на производственную среду, когда он должен смотреть на постановку.

ответ

4

This thread on AWS, по-видимому, подразумевает, что RACK_ENV может быть установлен только для одного из «развития» или «производства».

Интересно, что в своих тестах, при настройке среды Elastic Beanstalk к RACK_ENV=staging, миграция будет работать с базой данных staging, определенных в database.yml, но Пассажир все еще пытается подключиться к базе данных production.

Решение, с которым мы столкнулись, состоит в том, чтобы настроить две различные «среды» в приложении, каждая со своей собственной базой данных RDS. Тогда в database.yml мы используем параметры ENV для подключения к правильной базе данных во время выполнения:

production: 
    database: <%= ENV['RDS_DB_NAME'] %> 
    username: <%= ENV['RDS_USERNAME'] %> 
    password: <%= ENV['RDS_PASSWORD'] %> 
    host: <%= ENV['RDS_HOSTNAME'] %> 
    port: <%= ENV['RDS_PORT'] %> 
+0

Этот метод для соединений с базой данных также рекомендуется практиковать из AWS, конечно, для конфигурируемости, но также для предотвращения проверки чувствительных строк подключения в исходное управление. Конечно, вы можете ограничить отверстия в настройке RDS, но это дополнительная мера предосторожности. – Michael

1

В вашем Beanstalk конфигурации установить STAGING в true.

Добавить исправление в начало config/environment.rb, если на рельсах или в верхней части стойки.

# Fix the environment 
if ENV['STAGING'] 
    %w(RACK_ENV RAILS_ENV).each do |key| 
    ENV[key] = 'staging' 
    end 
end 

# Load the Rails application. 
... 

Не связывайтесь с PASSENGER_ENV или WSGI_ENV. Это сломается, если вы это сделаете.

+1

Это помогло мне устранить давнюю проблему, когда параметры production.rb загружались в сцену (по сравнению с настройками staging.rb), несмотря на то, что RACK_ENV явно возвращал «этап» в консоли rails. Thanks @AJcodez – Michael

+0

Не могли бы вы подробнее остановиться на этом? «В вашей конфигурации beanstalk установите STAGING в true». Я не понимаю. – pingu

+0

@pingu в вашей конфигурации beanstalk вы можете установить переменные среды. http://stackoverflow.com/questions/11211007/how-do-you-pass-custom-environment-variable-on-amazon-elastic-beanstalk-aws-ebs – AJcodez

Смежные вопросы