EDIT:
The issue here was that I used RVM on my local machine and rbenv on the server. This is highly not recommended, if you're managing several ruby installation (or upgrading your ruby version but do not want to change the system's) use either RVM or rbenv on all environments!
/EDIT
So I'll start with a bit history:
I'm in the process of upgrading our rails2 website to rails3. Most of the things are working properly by now, except Capistrano's deploy script.
The current setup I have is:
RVM (1.14.1) installed locally
ruby-1.9.3-p194 (set to the project's folder)
Capistrano v2.12.0 (upgraded from 2.6.0, but it doesn't work on 2.6.0 as well) installed as an RVM gem
rvm-capistrano (1.2.2), added to the Gemfile (after doing some reading online and on SO)
rbenv (with ruby 1.9.3p194 used globally) installed on the server
(by now if you see anything that doesn't make sense, please let me know)
Nothing changed in the deploy script, yet when I try to deploy to my testing server (let's call it beta) I get this error:
* executing `deploy:restart'
* executing "cd /home/foo/bar/current && rake RAILS_ENV=beta queue:restart_workers"
servers: ["208.0..."]
[208.0...] executing command
*** [err :: 208.0...] rake aborted!
*** [err :: 208.0...] no such file to load -- bundler/setup
*** [err :: 208.0...] /home/foo/bar/releases/20120630161947/Rakefile:5
*** [err :: 208.0...] (See full trace by running task with --trace)
** [out :: 208.0...] (in /home/foo/bar/releases/20120630161947)
command finished in 1183ms
failed: "sh -c 'cd /home/foo/bar/current && rake RAILS_ENV=beta queue:restart_workers'" on 208.0...
The relevant part on deploy.rb looks like this:
task :restart do
run "cd /home/foo/bar/current && rake RAILS_ENV=#{CAP_ENV} queue:restart_workers"
run "cd /home/foo/bar/current && rake RAILS_ENV=#{CAP_ENV} db:migrate"
run "touch #{deploy_to}/current/tmp/restart.txt"
end
Needless to say, rake RAILS_ENV=beta queue:restart_workers' works perfectly when run manually on the server. Also, the application gets deployed (the code was copied from git, it's just the last part of the deploy fails).
Lastly, the error didn't change since before I installed rvm-capistrano and added to the Gemfile, so I'm not even sure it's related to rvm, I'm just guessing from looking online.
Thanks
In order to work correctly, rbenv must override all the ruby and gem-related executables with the shims it provides.
Usually this is done with a startup script (this is why it works when you login to your server) but Capistrano logs in without shell and thus does not run those scripts.
You must add the following to your deploy.rb :
set :default_environment, {
'PATH' => "$HOME/.rbenv/shims:$HOME/.rbenv/bin:$PATH"
}
and do not use anything rvm related on your server, rbenv and rvm really do not like each other
PS : a little more explanation on this topic : http://henriksjokvist.net/archive/2012/2/deploying-with-rbenv-and-capistrano/
Related
I'm deploying to a VPS using capistrano, based on the guide at RailsCasts.
http://railscasts.com/episodes/335-deploying-to-a-vps?view=asciicast
It's failing on the deploy:cold command, with a conflict with Ruby. I actually can't see what the problem is, as when I shell into the same user the Ruby version looks correct.
$ cap shell
cap> which ruby
[establishing connection(s) to 192.xxx.xxx.xxx]
** [out :: 192.xxx.xxx.xxx] /home/deployer/.rbenv/shims/ruby
cap> ruby -v
** [out :: 192.xxx.xxx.xxx ruby 1.9.3p327 (2012-11-10 revision 37606) [x86_64-linux]
This is the error:
command finished in 655ms
* 2013-07-01 16:40:39 executing `bundle:install'
* executing "cd /home/deployer/rails/assay/releases/20130701144038 && bundle install -- gemfile /home/deployer/rails/assay/releases/20130701144038/Gemfile --path /home/deployer/rails/assay/shared/bundle --deployment --quiet --without development test"
servers: ["192.xxx.xxx.xxx"]
[192.xxx.xxx.xxx] executing command
** [out :: 192.xxx.xxx.xxx] rbenv: version `1.9.3' is not installed
command finished in 662ms
*** [deploy:update_code] rolling back
My question is: how can I debug this? When I read the deploy.rb file I can't see where it even references the Ruby version. Pretty frustrating, I am about ready to ftp the repo up, which is not ideal obviously.
Well I finally got to the bottom of the issue - a mismatch between ruby versions use by Capistrano and what was actually on the server.
To debug Capistrano run it like this:
cap deploy:cold -d
That was you can step through the commands and access the temporary directories on the remote server before they are deleted.
I just had similar issue, the reason was .ruby-version file pointing at 1.9.3 (file was generated by rails-composer), while there was 1.9.3-p392 installed via rbenv on remote machine.
Debug info of capistrano can be shown by tail -f log/capistrano.log.
I solved many problems already, but struggling with this one.
Deploy environment:
ubuntu 12.10
rvm 1.18.21 (stable)
ruby 1.9.3p392
Getting this error with
cap deploy:cold
Error:
* 2013-03-23 18:01:27 executing `deploy:start'
triggering before callbacks for `deploy:start'
* 2013-03-23 18:01:27 executing `foreman:export'
* executing "cd /home/gwuix2/picurwebaruhaz/current && bundle exec foreman export bluepill /data/picurwebaruhaz/shared/config"
servers: ["198.211.117.84"]
[198.211.117.84] executing command
** [out :: 198.211.117.84] ERROR: Procfile does not exist.
** [out :: 198.211.117.84]
command finished in 1430ms
My deploy.rb:
https://gist.github.com/gwuix2/5228473
Gemfile: https://gist.github.com/gwuix2/5228488
According to Spree's docs, it looks like you need to generate a Procfile (which is used by Foreman) in your app before deploying it.
Spree guide to Application Processes
That guide shows a default Procfile's contents, which you may be able to get by with. Spree also has a deployment service which can take care of generating several things for you, including the Procfile:
Every server will get some basic configuration, such as Rails Environment environment variable, placeholder directories for your Spree application, automatically generated database.yml and Procfile files, and more.
So that may be worth looking into, because even if you are able to generate the Procfile manually, you may run into more issues from missing config files, and their deployment service may take care of all of that for you automatically.
I'm trying to deploy my app for the first time on a ubuntu server.
I keep hitting this error:
2013-03-24 15:13:36 executing `deploy:run_migrations'
* executing "rvm gemset use vapin"
servers: ["111.111.111.11"]
[111.111.111.11] executing command
** [out :: 111.111.111.11]
** [out :: 111.111.111.11]
** [out :: 111.111.111.11] RVM is not a function, selecting rubies with 'rvm use ...' will not work.
** [out :: 111.111.111.11]
** [out :: 111.111.111.11]
** [out :: 111.111.111.11]
** [out :: 111.111.111.11] You need to change your terminal emulator preferences to allow login shell.
** [out :: 111.111.111.11]
** [out :: 111.111.111.11] Sometimes it is required to use `/bin/bash --login` as the command.
** [out :: 111.111.111.11]
** [out :: 111.111.111.11] Please visit https://rvm.io/integration/gnome-terminal/ for a example.
Here's some of my deploy.rb file:
require 'bundler/capistrano'
require 'rvm/capistrano'
# set the ruby version
#set :rvm_ruby_string, 'ruby-1.9.3-p392'
#set :rvm_type, :system
# set the rvm gemset to use
set :rvm_gemset, 'vapin'
...
task :install do
run "rvm gemset use #{rvm_gemset}"
run "cd #{current_path} && bundle install --without=test"
end
RVM is installed on my server.
$ which rvm
/usr/local/rvm/bin/rvm
$ which ruby
/usr/local/rvm/rubies/ruby-1.9.3-p392/bin/ruby
Any help is appreciated. I've been googling this one for days.
EDIT
I've uninstalled my multiuser installation of RVM and reinstalled the single user version.
I added this line to my deploy.rb script:
set :default_shell, "/bin/bash --login" # required for rvm scripts to work properly
and now i do not get the "RVM is not a function...." error.
The problem is that when bundle install runs, the gems are not installed in my rvm gemset.
In my deploy.rb file, setting this line:
set :bundle_dir, "/usr/local/rvm/gems/ruby-1.9.3-p392"
before this line:
require 'bundler/capistrano'
seemed to help bundler know where to install the gems. Not sure why this is needed. I've never needed it before.
Don't use rvm1/capistrano3 or rvm/capistrano; don't set :pty.
Change ~/.rvmrc for the runner user, on the server, to this — note that it has to come before the line where it kills itself when not running interactively:
# get rvm for non-interactive shells (eg capistrano) too
source /etc/profile.d/rvm.sh
export BASH_ENV=$HOME/.bashrc
export rvm_is_not_a_shell_function=0
# If not running interactively, don't do anything
[ -z "$PS1" ] && return
I've just been struggling with this issue. Tried everything listed above, nothing worked. Deploying from osx, to ubuntu.
Finally, on ubuntu, "su-ed" as my deploy user, I did "rvm get head" (where I had been using "rvm get stable"). (I have it setup in a single-user environment, with rvm under "/home/deploy/.rvm".)
Like magic, it started working! Phew. So I guess maybe there's some fix in the latest rvm, that isn't in stable yet?
Maybe you need to add the RVM bin directory to your $PATH for scripting:
PATH=$PATH:$HOME/.rvm/bin
Although it seems you've answered your own question, I'll throw my hat in the ring as well...
I had a similar issue with the whole RVM is not a function error when trying to create a Rails template, and got around it by getting the rvm environment instance on a specific Ruby version, and then setting the gemset/running bundle install directly on it. In your case, it may be something like:
require 'bundler/capistrano'
require 'rvm/capistrano'
# set the ruby version
set :rvm_ruby_string, 'ruby-1.9.3-p392'
# set the rvm gemset to use
set :rvm_gemset, 'vapin'
...
task :install do
require 'rvm'
env = RVM::Environment.new(rvm_ruby_string)
# If you need to create a new app-specific gemset
# env.gemset_create(rvm_gemset)
env.gemset_use!(rvm_gemset)
# If you need to install bundler in a new gemset
# env.system("gem", "install", "bundler")
env.system("bundle", "install", "--without=test")
end
Obviously, the above code is not tested, but I created similar code that I've had success with in this Rails template file that will hopefully serve as some reference to you if the above code completely fails.
Having some issues deploying this. I've tried to deploy it twice now. Here's what I've done so far....
Installed the gems and versions required on the install page:
gem install -v=2.3.5 rails
gem install -v=1.0.1 rack
gem install -v=0.8.7 rake
gem install -v=0.4.2 i18n
Downloaded the package:
git clone git://github.com/chiliproject/chiliproject.git
cd chiliproject
git checkout stable
Had to find and set bundle since it wasn't in my path:
BUNDLE="/usr/lib/ruby/gems/1.8/bin/bundle"
Put my database info into database.yml:
And then started the bundle stuff:
$BUNDLE install --without=postgres rmagick
$BUNDLE exec rake generate_session_store
The last command got the error:
rake aborted!
can't activate rails (= 2.3.5, runtime), already activated rails-2.3.12. Make sure all dependencies are added to Gemfile.
So I changed 2.3.12 to 2.3.5 in the Gemfile and carried on:
RAIL_ENV=production $BUNDLE exec rake db:migrate
Then I got an error on this command too:
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
rake aborted!
undefined method `autoload_paths' for #<Rails::Configuration:0x68a68dbb82c0>
/home/USERNAME/DOMAIN/public/config/environment.rb:44
I tried commenting out line 44 there, but then it threw another error undefined methodconvert_to_without_fallback_on_iso_8859_1' for class Class' so I didn't want to play around with it further. Note this only happened the second time I tried to deploy it. The first time I tried db:migrate succeeded (and I checked there was not data already in the DB).
*So for the second try I am stuck here :-( *
But this is what happened the first time after db:migrate succeded....
RAILS_ENV=production $BUNDLE exec rake redmine:load_default_data
With the last command however it failed saying permission denied for mysql 'user'#'173.236.128.0/255.255.128.0' and I was like WTF is it trying to connect to a network as if it were a host?
So I moved on, copied my configuration file and environment files in. Changed/added these lines:
# Uncomment below to force Rails into production mode when
# you don't control web/app server and can't set it the proper way
ENV['RAILS_ENV'] ||= 'production'
# Specifies gem version of Rails to use when vendor/rails is not present
RAILS_GEM_VERSION = '2.3.5'# unless defined? RAILS_GEM_VERSION
if ENV['RAILS_ENV'] == 'production' # don't bother on dev
ENV['GEM_PATH'] = '/home/USERNAME/.gems' + ':/usr/lib/ruby/gems/1.8'
end
Then made this stuff writable and restarted Passenger:
chmod -R 777 files log tmp public/plugin_assets/
touch tmp/restart.txt
Sorry for the wall of text, is anybody able to shine some light on something I've done wrong?
Thanks in advance.
EDIT: So this is all wrong, here's how I got it working
rm ~/.gem*
gem install bundler
PATH=$PATH:/usr/lib/ruby/gems/1.8/bin
cd ~
git clone git://github.com/chiliproject/chiliproject.git
cd chiliproject
git checkout stable
cp * ../example.com/ -R
cd ../example.com
# Make sure database is working
bundle install --without postgres rmagick test
bundle exec rake generate_session_store
RAILS_ENV=production bundle exec rake db:migrate
# No output is no good, check database.yml
RAILS_ENV=production bundle exec rake redmine:load_default_data
Or see this: https://gist.github.com/1127306
The current ChiliProject stable releases (2.x) require the use of bundler. Thus the answer by Slotos is incorrect here. gen install doesn't work anymore, we NEED bundler.
Also, we require Rails 2.3.12 now. You won't get any working results if you arbitrarily edit files. On certain platforms, you need to adapt the Gemfile (e.g. when using Ruby 1.8.6 or for certain versions of ImageMagick). For the currently suggested setup using Ruby 1.8.7 or REE, you don't need to adapt anything though.
For installing the dependencies of the currently stable ChiliProject 2.x releases, you basically need to do the following:
At first you need to make sure that the directory where gem binaries re installed to is in your $PATH. This can be temporarily be achieved by running this (in your case)
export PATH=/usr/lib/ruby/gems/1.8/bin:$PATH
Then you need to install the bundler gem and instruct it to install all dependencies
gem install bundler
bundle install --without rmagick postgres test # in your case
What is really strange in your case is that rake seems to try to enable Rails 2.3.5. It should not do that (and doesn't unless you have changed certain files). I strongly recommend to start with a new clean source tree and don't change any arbitrary files.
Don't mix up gem install commands with bundler package management. You will get unexpected results from doing so.
If you really want to use bundler - add all the gems you want into a Gemfile.
Otherwise just omit it.
Quick search for "bundler chiliproject" lead me to chiliproject-gemfile. Apparently it have been merged into unstable already.
My custom capistrano task "app:sample" fails with the following error message:
mnylen ilmo-on-rails $ cap app:sample
* executing `app:sample'
* executing "export RAILS_ENV=production; cd /home/mnylen/ilmo-on-rails/current; ruby script/coursegen 10"
servers: ["rails.cs.helsinki.fi"]
* establishing connection to gateway `melkinpaasi.cs.helsinki.fi'
* Creating gateway using melkinpaasi.cs.helsinki.fi
* establishing connection to `rails.cs.helsinki.fi' via gateway
Password:
[rails.cs.helsinki.fi] executing command
*** [err :: rails.cs.helsinki.fi] Rails requires RubyGems >= 1.3.2. Please install RubyGems and try again: http://rubygems.rubyforge.org
command finished
failed: "sh -c 'export RAILS_ENV=production; cd /home/mnylen/ilmo-on-rails/current; ruby script/coursegen 10'" on rails.cs.helsinki.fi
Am I missing something or doing something wrong? The task is:
namespace :app do
desc "Run sample data on production2
task :sample do
run "export RAILS_ENV=production; cd #{current_path}; ruby script/coursegen 10"
end
end
If I run the same command from the actual server, it works fine.
Cap is running the remote command as an unexpected user - and that user does not have the correct path to ruby and gem. Check your settings in your recipe for :user and :use_sudo. Carefully read the cap output to see what user is being connected. I see you are using a :gateway; there can be two users in this case. One to connect to the gateway, and another to actually run commands on the target server.
Okay, solved.
The problem was that there was two Ruby installations on the production server.
The .profile file under my home directory on the production server set the PATH environment variable to point to the correct Ruby version.
run command, it seems, doesn't source the .profile file and thus, running ruby script/coursegen 10 in the task used the wrong Ruby version, which was the reason for the weird error message about RubyGems version. This also explains why it worked when manually running the command from production servers shell.
My solution was to use full path to the Ruby executable in my run task, like this:
run "export RAILS_ENV=production; cd #{current_path}; /opt/ruby-enterprise-1.8.7-2009.10/bin/ruby script/coursegen 10"
Of course, this isn't pretty, but it works. If anyone has any prettier solutions, I'd be more than glad to use those instead. :)
Seems like you should update your RubyGems on the remote server.