Can Rails avoid picking VERSION environment variable in production - ruby-on-rails

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

Related

Is there a way to connect to a Rails app's console on a linux server?

I have deployed a rails application using capistrano on a linux server and it is running without any problems. When I connect to my remote server via ssh, the folder structure of my app is quite different from what I have on my local machine. I would like to go to project root and say rails console so that I can have access to the console of my application. Is there a way to achieve this?
When I go to ~MyApp/ folder and run rails console it says command rails not found. I think that is probably because the app is running in another folder.
bundle exec to the rescue inside of project folded:
$ RAILS_ENV=production bundle exec rails console
If you've installed with rbenv it could be that you are defaulting to the wrong Ruby version. So you can run rbenv exec to get it to run on the right version, along with bundle exec to run the right version of Rails
So try running this:
rbenv exec bundle exec rails console
To sum up for anyone having the same problem in the future,
I went to MyApp/releases/2020331231231231 which is the latest release of my app and there I used this command RAILS_ENV=production bundle exec rails console and I was able to do whatever I wanted to do in the console.
First you need to move inside the folder where the code is.
Check Capistrano config if deploy_to is defined. (If it's not it should be set to /var/www/#{application}/ by default read here)
Since Capistrano keep older versions of your app go to the current folder which is a symlink of the latest deployed version.
And run ENVIRONMENT=production bundle exec rails c or ENVIRONMENT=production bin/rails c. If doesn't work try with rbenv ENVIRONMENT=production rbenv exec bundle exec rails c

Unable to run rails console/server in AWS Cloud9 CodeStar EB dev Ruby on Rails environment

I created my first environment with CodeStar and selected the Ruby on Rails w/ Elastic Beanstalk option. I'm using AWS Cloud9 for the IDE. I'd like to use the Preview option to view the impact of code changes prior to committing, and have looked through the docs at http://docs.aws.amazon.com/cloud9/latest/user-guide/app-preview.html, however I can't seem to get a server running in the development environment.
From within my environment directory in the Cloud9 terminal (path: /home/ec2-user/environment/env_name) I tried rails s -b $IP -p $PORT as documented for the previous non-AWS Cloud9, and also rails server and even rails console just to check. In each case I just get the help details for rails new:
$ rails s
Usage:
rails new APP_PATH [options]
Options:
-r, [--ruby=PATH] # Path to the Ruby binary of your choice
...etc...
What am I missing?
Per the discussion on this question, this behavior indicates that rails does not recognize that it is running in a rails directory so it thinks the only valid action is rails new. There were several suggested answers, but the one that worked for me was to run rake rails:update:bin (or rake app:update:bin for Rails 5).

Loading rails env in production

I have deployed a new Rails site to a Linux VM using Capistrano. I am using nginx as the front end and running my Rails app using unicorn.
If I try to run rake routes on the server, I get an error telling me that Rails is not installed, even though Rails is installed. The problem seems to be that the gem search directory is different for the app and the logged in user.
How do I load the Rails environment that my app is seeing as the logged in user?
Just use:
RAILS_ENV=production bundle exec rake routes
The RAILS_ENV part sets your environment variable so your app is loaded in full production mode, including database settings and so on.
The bundle exec part is necessary so that any commands that come after that are executed within the environment of the gems installed in your Gemfile.

Run Rails app in different enviroment on Appfog

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.

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