I cannot for the life of me figure out how to get OpsWorks to use my rails staging environment. I have development, staging and production. Development for local machine and staging and production for two different stacks on OpsWoks. I am just trying to get my staging environment working, but it keeps deploying as production. Staging is basically a duplication of my development environment, but it's able to send email externally and has a different database host instead of localhost.
I am setting this custom json so far in my stack settings:
{
"deploy": {
"my_app_name": {
"rails_env": "staging",
"database": {
"adapter": "mysql2"
}
}
}
}
I kept having database connection issues with RDS until I added this database adapter key/pair. I just can't get it to start my rails app in staging.
When creating the App and specifying the git source and RDS it asks for "Rails environment". I set this to staging thinking that is all I needed to do to define what rails environment to use.
Any experts with OpsWorks that can help, it is greatly appreciated. I just started setting this up today. I wish the docs had a little better examples.
OpsWorks will start the app with the rails_env you specify in the custom json for the application. A caveat is that if you shell in to the server and do a rails console, you will see Rails.env is not equal to what you set in the JSON. This is because OpsWorks starts the application with the setting you entered, but it doesn't save that setting as an environment variable. So when you are on the cli, it doesn't know which environment to use.
For more information, refer to this excellent answer:
https://stackoverflow.com/a/21949946/973810
Related
The Heroku documentation at https://devcenter.heroku.com/articles/deploying-to-a-custom-rails-environment says I shouldn't use a staging.rb file to define my staging environment.
It may be tempting to create another custom environment such as “staging” and create a config/environments/staging.rb and deploy to a Heroku app with RAILS_ENV=staging.
This is not a good practice. Instead we recommend always running in production mode and modifying any behavior by setting your config vars.
I think this is terrible advice and conflicts with well-established Rails best practice. However, I'm not here to argue about best practices. I'm here to ask:
Are there any reasons not to use RAILS_ENV=staging on Heroku?
Is there anything that will break if I create a staging.rb file and set the xxx_ENV config vars like this?
heroku config:add RACK_ENV=staging --remote staging
heroku config:add RAILS_ENV=staging --remote staging
No, there isn't anything that will break if you do this.
However, I do think that Heroku is right here (note that I work at Heroku).
It introduces possible differences between your staging and production environments, when the only thing that changes between them should be configuration variables.
Heroku already provides a secure mean of setting configuration variables, with the config:set command.
Using 2 config files means you have to maintain the same configuration twice, and possible can have issues because you updated the configuration correctly in staging, but incorrectly in production.
As a side note, RACK_ENV should only ever have 3 values: production, development and none. See https://www.hezmatt.org/~mpalmer/blog/2013/10/13/rack_env-its-not-for-you.html
You'll get some warnings from Heroku when you deploy, but I can confirm I did run staging apps, with RAILS_ENV=staging, on Heroku. As long as you set the correct environment variables and Gemfile groups, it should just work.
My guess is that the reason they advise not to use custom environments is that they have some operational tooling that assumes your Rails app runs in production environment, but so far I didn't run into issues.
I am coming in late to add some functionality to an already existing app hosted on heroku. The original builder has given me access and I 'heroku git:clone -a app-name' to my local computer.
I've found some conflicting instructions on how to set up a staging environment for this site. I don't want to push to the original site but want a way to try out functionality.
If anyone has had experience with staging and heroku, I'd appreciate any clarification.
You'll need to create a staging.rb file in config/environments. You can copy development.rb or production.rb and adjust whatever values you need.
Heroku will handle configuring the database configuration and such. You can clone an app in Heroku or just create a new one, then set it's RAILS_ENV and RACK_ENV environment variables to staging, and push to it.
Please refer: Heroku - Managing Multiple Environments for an App
You Need to create a second Heroku application that hosts your staging application.
Follow the instructions provided in the link for working with multiple environment in heroku.
I have the production application in the server in a subdirectory like www.server.cl/myapp.
But when I am in the development enviroment (running rails server) the application run on localhost:3000 and I can not check if the routes are 100% correct in the production enviroment (subdirectory) especially the assets paths.
Create staging environment (similar or identical to production environment) and deploy and test in this environment before deploy to production environment.
Here is more detail description.
I have an action which causes an exception in my staging environment, but instead of sending the notification to hoptoad (which it should, the hoptoad test rake task works...), it shows me the standard rails stacktrace page like it does in development.
My staging environment is essentially a copy of my production environment with the only difference being the rails environment being set through passenger.
What could be the cause of this? Where should I be looking? I haven't confirmed that production does the same thing as we don't yet have a proper production environment set up, but I assume it would also act the same way.
Are you sure that your staging instance is running in the correct environment? Have you tried outputting Rails.env somewhere in your views just to make sure?
I only ask because you mentioned seeing a stack trace page, which shouldn't happen in a production environment unless you're making the requests locally, or you have config.action_controller.consider_all_requests_local set to true in your environment config.
I have a app that I'm deploying to a development server using Capistrano. I'd like to force this deployment to use the development database. So far the only way I've managed to do it is to make my production database info in database.yml equal to the development info. But this is a complete hack.
I've tried setting rails_env to development in deploy.rb but that hasn't worked.
Thoughts?
I ended up using the solution over here. Basically a recipe to replace a line in environment.rb after deploy but before restart.
The problems seems to be with DreamHost's Passenger config. It assumes you're running in production mode.
I'd use Capistrano Ext in order to define multiple deployment environments. I have used this in the past to deply staging and production installations of my apps, so I think it'd work well for you.
Jamis Buck has a writeup if you'd like an overview on how to use it.