Reputation: 19723
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.
Upvotes: 5
Views: 657
Reputation: 34216
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.
Upvotes: 2
Reputation: 639
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'] %>
Upvotes: 4