No way to set RAILS_ENV other than 'production' #34
Comments
@ajgon I have solved this in my fork by adding the following setting: {
"deploy": {
"<my_app_name>": {
"environment": "staging"
}
} The reason I'm not setting this under Let me know what you think of this approach. If you dislike it, I'm open to suggestions :) |
I resolved it slightly differently, by intoducing the However it remains an opened question - should we stick to Or maybe something like Thoughts? :) |
That would be great if I noticed that the environment is also used on the unicorn service template: For the template above to be rendered with the proper Another component that could also make use of this is the Sidekiq driver. I realised that the sidekiq monit template ( How could we design it so other drivers (not only framework) could also access the environment? |
I think the way OpsWorks solved this for for stacks prior to Chef 12 was to store it under |
@ajgon When would you want a different environment setting for different drivers on the same stack? I like @marcosbeirigo solution of putting it under deploy['app_name']['envrironment'], which would set the environment for all drivers. If its actually needed to be different for certain drivers maybe allow them to also be set at a more granular level which would override the higher level deploy['app_name']['envrironment'] setting. Something like {
"deploy": {
"app_name": {
"environment": "staging",
"framework": {
"deploy_environment": { "RAILS_ENV": "beta" }
}
}
}
} |
By changing `app['framework']['rails_env']` to `app['framework']['deploy_env']` the option itself is made more general. Thanks to that, when `rails` framework is used, `RAILS_ENV` will be set. If future frameworks are added to the stack, they can safely set their own configurations (`RACK_ENV`, `SINATRA_ENV` etc.). Related to #34
I see the point, but from different perspective. By hardwiring the environment to the framework, we can't set it when no framework is present at all (i.e. custom Ruby app, but with some kind of environment variation i.e. I followed the more general approach ( |
|
Awesome 💚 💙 💛 |
Before this change, RAILS_ENV was hardcoded to `production`. This was not a best solution, since many different environments may be introduced to AWS stack (`staging`, `beta` etc.). To solve this, the `app['framework']['rails_env']` configuration parameter is introduced, which serves exactly for that purpose. Resolves ajgon#34
By changing `app['framework']['rails_env']` to `app['framework']['deploy_env']` the option itself is made more general. Thanks to that, when `rails` framework is used, `RAILS_ENV` will be set. If future frameworks are added to the stack, they can safely set their own configurations (`RACK_ENV`, `SINATRA_ENV` etc.). Related to ajgon#34
The "environment" is a global concept for the whole application, so symantically it should be set on the application level (`node['deploy']['app_name']`) not on the framework level. Resolves ajgon#34 (finally)
From
opsworks_ruby/libraries/drivers_framework_rails.rb:12
This method always sets the RAILS_ENV as production with no way to set it to beta, staging, etc. Unless I'm missing some other place RAILS_ENV is supposed to be set. Should this method maybe be reversed like so?
That way you can set it in opsworks stack settings via
The text was updated successfully, but these errors were encountered: