Run Rails app in different enviroment on Appfog - ruby-on-rails

I'd like to run my RoR app on Appfog in the "staging" environment rather than the default "production" environment.
I tried to add an environment variable RAILS_ENV=staging, and restarted the app. However, I got this error:
rake aborted!
database configuration does not specify adapter
Does anyone try to do this on Appfog ?

Creating new Environment:
Assuming you want create the hudson environment.
Create a new environment file in config/environments/hudson.rb.
You can start by cloning an existing one, for instance config/environments/test.rb. Add a new configuration block in config/database.yml for your environment. That's all.
Now you can start the server
ruby script/server -e hudson
Run the console
ruby script/server hudson
And so on.

Related

How to segregate rake from executing production DB commands from development environment?

I just noticed that a rake drop all command can also drop tables in the production db instance. Is there a way in rails to separate rails config so that the production systems are not touched by any commands from development environments ?
Separate and isolate production connections away from your development setup.
Your local database.yml should not have production credentials and connections in it, and should instead use environment variables that are only supplied in production environments.

Can Rails avoid picking VERSION environment variable in production

I want to host a Ruby on Rails application in a server with CentOS Linux release 7.4.1708 (Core).
Every time I SSH into the server I get an environment variable VERSION with value 7 by default.
When I try to run bundle exec rake db:migrate, Version=7 is automatically being picked by Rails and I get the following error:
ActiveRecord::UnknownMigrationVersionError:
No migration with version number 7
If I manually deploy the Rails app, I can unset VERSION and run the bundle exec rake db:migrate.
But unset VERSION is not working somehow with Capistrano auto deployment.
So, I am looking for a work around to run migrate task with Capistrano.
Is there an option in Rails where we can specify migrate task not to look for VERSION environment variable in production.
If you cant change the rails behaviour you could find from where the VERSION env variable comes, use env with different users to check if that env variable exists for your specific user only or if it is global. There not exists a VERSION environment variable for CentOS 7 by default, so it must have been added manually or by configuration, check systemd services and init scripts, /etc/environment, /etc/profile.d... etc

How to force Rails 4 app into production mode in Nginx and Unicorn?

I am running a Rails 4 app on a VPS with Ubuntu, NginX and Unicorn.
When I SSL into my server and update the app via git or run rake tasks on the database, my app always switches to development mode and I can't get it into production mode.
Typing RAILS_ENV=production seems to have no effect at all.
When I do
$ rails console
$ Rails.env
I get
--> development
all the time.
What must I do to force NginX into production mode?
Actually, I don't want Nginx to ever run in development mode.
How can this be achieved?
Thanks for any help.
Your application is probably running in production mode by default. What you're doing is engaging a shell, something using a different environment.
Normally on a production server you'd put this into your profile script:
# Add to ~/.bash_profile
export RAILS_ENV=production
That way when you power up rails c you will get the correct environment.
As a note, the only way this shell is engaging in the first place is that you have a development setting in your config/database.yml. That shouldn't be there, as the configuration for your production server should be production-only.
nginx doesn't run in development or production mode - your app does, via your unicorn configuration and/or the RAILS_ENV environment variable when you launch your unicorn instances.
You should be launching your unicorn instances with the RAILS_ENV variable prefixed to the command, eg:
RAILS_ENV=production bundle exec unicorn -c config/unicorn.rb -D
rails console launches a completely different instance which may be in an different environment - it is unrelated to your unicorn instances. If you want to launch a production console instance, then either invoke RAILS_ENV=production rails console or rails console production. Note that this has no bearing on the environment that your application runs in.

How to write ruby script that uses the production environment instead of development?

I have writen a ruby script that requires config/environment.rb so I can use all the models of my rails application in the script but the problem is that I want to use the production environment instead of the develoment environment which seems to be the default behavior.
Im using Rails 3.1.1 and Ruby 1.9.2
How can I run the script with the production environment?
Your script will take the environment variable RAILS_ENV as the environment to use.
I'd be very wary of overriding that in the script as it may cause much confusion if you try and run your script in another environment - e.g. staging - and it starts trying to access production databases etc.
So do either:
RAILS_ENV=production ./script/my-awesome-script
or
export RAILS_ENV=production
./script/my-awesome-script
Generally speaking; when I log into a production Rails environment I'd be changing the environment straight away if I haven't configured it to be "production" by default.
I think you want either Rails.env = 'production' or ENV['RAILS_ENV'] = 'production' in your script.
#davidb, I am not sure what u want also not as good on rails yet but may be you can use the seed.rb (i.e seed functionality) for achieving what you want if this script is run only once or sometimes as we can specify the environment while running seed
rake db:seed RAILS_ENV=production

rails3 app ENV not being recognized as production

I set up my rails app on my linode VPS, phusion passenger is installed and working, so is mysql (I know this cause my friend currently is running 2 production apps on it with the same set up). The VPS is running Ubuntu 10.10 and I'm using apache2 with passenger.
I SFTP'd the app to the server, bundle updated, set up my virtual host and specified RailsEnv to be production and paths are all accurate.
I then restarted the server (as root) with
apachectl -k restart
tried to rake db:migrate and it didn't do anything, so I figured it was because the environment didn't get changed, which is exactly what happend. If I go into the rails console and type Rails.env it gives me development.
I have no idea why, I did everything that should set it to production? Anyone know what I may have missed? Is there somewhere in the app where I'm supposed to change something to say production environment? I thought that only had to be done in rails 2.x
Thanks in advance for any and all help.
The RailsEnv setting is only for Passenger's use. It doesn't affect the commands you type in the shell.
Use
RAILS_ENV=production rake db:migrate
and
RAILS_ENV=production rails console
Or set the RAILS_ENV environment variable in your login shell to production so that you don't have to append RAILS_ENV=production to the commands you issue:
export RAILS_ENV=production
(exact command may vary depending on which shell you use; the above works in bash)
You were on the right track; all you need to do to actually run the app in production mode is set the RailsEnv as you did, assuming you are running the app using Passenger. However, to run the database migrations you need to tell Rails what environment to run within.
The rails console command defaults to the 'development' environment by default. The same goes for running database migrations.
To run the migrations on your production environment you need to run the command as such:
RAILS_ENV=production rake db:migrate
And to run the console in production mode, you need to run the console using the command:
rails console production
If you want this variable to be set automatically, put RAILS_ENV=productionat the end of your ~/.bashrc file. (This only works with a bash terminal)
Then open a new terminal, or restart your ssh connection.

Resources