RVM Gemset - Bundler & Capistrano in Production

I'm deploying a rails app to a VPS with capistrano, bundler开发者_运维知识库 and rvm. Here is part of my deploy.rb

$:.unshift(File.expand_path('./lib', ENV['rvm_path']))
require "rvm/capistrano"     
require "bundler/capistrano"             # Load RVM's capistrano plugin.

set :rvm_type, :system
set :rvm_ruby_string, '1.9.2@gemset_name'

my .rvmrc

rvm --create use 1.9.2@gemset_name

When I logged into the server I noticed that the rvm gemset was created, however all the gems were installed in /shared/bundle/ruby/1.9.1/gems --not in the gemset(/usr/local/rvm/gemset)

I use RVM in development and I think it's great but when is time to deploy to production. what are the best practices? Is there a way to tell bundler to install the gems in the gemset?

Do I even need a gemset at all? (seems like bundler is already isolating gemsets), Am I missing something?

Please help me understand!

Thank you very much

I use RVM in development and production as well. However, while I use gemsets in development to separate gems between my rails projects, I only use RVM to install rubies on my production VPS and let Bundler handle the versions of my gems.

Using the bundler integration via require "bundler/capistrano" automatically sets some things up for bundler. You can see the code behind this in Bundlers Github page. The basic settings are so that bundle executes this command:

bundle install --gemfile Gemfile --path shared/bundle --deployment --quiet --without development test

As you can see, the --deployment and --path flags are given, which tells Bundler to bundle your gems with your application in the shared/bundle directory, and only use the versions specified in your Gemfile.lock (i.e. the versions that are working in development). Since the bundle directory is shared between deployments, I find it comparable to using RVM gemsets for each application, just easier.

If you still want to put gems in separate gemsets I'd recommend this tutorial from Darcy Laycock for further reading.