Why is Passenger looking at the staging environment?

Question

In my Elastic Beanstalk - Container Options. RACK_ENV is set to staging.

In fact, if I SSH into the EC2 instance and do rails console in /var/app/current/ and then typing Rails.env it returns staging.

Reading http://www.modrails.com/documentation/Users guide Nginx.html#RackEnv

It says to set a RACK_ENV variable, since by default, the value is production.

You would assume everything would work, except in the Elastic Beanstalk logs, it says:

[ 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 database does not exist, but foobar_staging does. So why is Passenger still looking at the production environment, when it should be looking at staging.

Answer 1

This thread on AWS seems to imply that RACK_ENV can only be set to one of 'development' or 'production'.

Interestingly, in my own tests, when configuring the Elastic Beanstalk environment to RACK_ENV=staging, the migration will run against the staging database defined in database.yml, but Passenger still attempts to connect to the production database.

The solution we came up with is to set up two distinct "environments" under the app, each with their own RDS database. Then in database.yml we use the ENV parameters to connect to the proper database at run-time:

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

Answer 2

In your beanstalk config set STAGING to true.

Add a fix to the top of config/environment.rb if on rails, or at the top of your rack app.

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

# Load the Rails application.
...

Do not mess with PASSENGER_ENV or WSGI_ENV. It will break if you do.