Question

在我的Elastic Beanstalk中 - 容器选项。 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确实存在。那么为什么Passenger仍然在关注生产环境，何时应该关注分期。

Answer 1

This thread on AWS似乎暗示RACK_ENV只能设置为“开发”或“生产”之一。

有趣的是，在我自己的测试中，当将Elastic Beanstalk环境配置为RACK_ENV=staging时，迁移将针对database.yml中定义的staging数据库运行，但Passenger仍尝试连接到{ {1}}数据库。

我们提出的解决方案是在应用程序下设置两个不同的“环境”，每个环境都有自己的RDS数据库。然后在database.yml中，我们使用ENV参数在运行时连接到正确的数据库：

production

Answer 2

在您的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。如果你这样做会破裂。

为什么Passenger正在寻找临时环境？

2 个答案: