5

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.

Christian Fazzini
  • 19,613
  • 21
  • 110
  • 215

2 Answers2

4

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'] %>
Richard Luck
  • 640
  • 7
  • 15
  • This method for database connections is also recommended practice from AWS of course for configurability but also to prevent your sensitive connection strings from being checked into source control. You can, of course, limit the holes in your RDS set up, but this is an extra precaution. – Michael Apr 02 '14 at 17:20
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.

AJcodez
  • 31,780
  • 20
  • 84
  • 118
  • 1
    This helped me to fix a long-standing issue where production.rb settings were being loaded into stage (versus staging.rb settings), despite RACK_ENV clearly returning 'staging' in the rails console. Thanks @AJcodez – Michael Apr 02 '14 at 17:17
  • Could you elaborate on this please? "In your beanstalk config set STAGING to true" I do not understand. – pingu Jun 07 '14 at 22:17
  • @pingu in your beanstalk config you can set environment variables. http://stackoverflow.com/questions/11211007/how-do-you-pass-custom-environment-variable-on-amazon-elastic-beanstalk-aws-ebs – AJcodez Jun 09 '14 at 20:21