我想将生产应用程序部署到我的本地服务器。我正在使用capistrano 3。
这是我的capfile
require 'capistrano/setup'
require 'capistrano/deploy'
require 'capistrano/rvm'
require 'capistrano/bundler'
require 'capistrano/rails'
#require 'capistrano/rails/migrations'
#require 'capistrano/rails/assets'
# Loads custom tasks from `lib/capistrano/tasks' if you have any defined.
Dir.glob('lib/capistrano/tasks/*.cap').each { |r| import r }
这是我的deploy.rb
# config valid only for Capistrano 3.1
lock '3.1.0'
set :application, 'ImpresaZiliani'
set :repo_url, 'francesco@10.0.1.8:repos/impresaziliani.git'
set :branch, 'master'
# Default branch is :master
# ask :branch, proc { `git rev-parse --abbrev-ref HEAD`.chomp }
# Default deploy_to directory is /var/www/my_app
set :deploy_to, '/home/francesco/impresaziliani'
# Default value for :scm is :git
set :scm, :git
set :deploy_user, "francesco"
set :rails_env, "production"
set :keep_releases, 5
namespace :deploy do
desc 'Restart application'
task :restart do
on roles(:app), in: :sequence, wait: 5 do
# Your restart mechanism here, for example:
# execute :touch, release_path.join('tmp/restart.txt')
end
end
after :publishing, :restart
after :restart, :clear_cache do
on roles(:web), in: :groups, limit: 3, wait: 10 do
# Here we can do anything such as:
# within release_path do
# execute :rake, 'cache:clear'
# end
end
end
end
set :rvm_ruby_version, '2.1.1'
set :default_env, { rvm_bin_path: '~/.rvm/bin' }
SSHKit.config.command_map[:rake] = "#{fetch(:default_env)[:rvm_bin_path]}/rvm ruby-# {fetch(:rvm_ruby_version)} do bundle exec rake"
我的database.yml是好的,因为如果我手动运行服务器上的迁移,我试图取消注释capistrano / rails /迁移和资产的行,但没有任何变化:当我部署它运行正常,直到捆绑安装,然后没有任何警告或错误,跳到资产预编译器,不运行迁移。
我该如何解决这个问题?
谢谢
答案 0 :(得分:71)
您还需要使用户部署具有db的角色,例如:
server 'you_ip_address', user: 'user_name', roles: %w{web app db}
答案 1 :(得分:18)
rake db:migrate在capistrano 3中每次部署都是自动的 您只需在Capfile中取消注释 #require' capistrano / rails / migrations'
答案 2 :(得分:0)
Jude Calimbas和hiveer的答案都比接受的答案更准确 - 迁移任务作为部署任务的一部分自动运行。
然而,他们的答案并没有解释所观察到的问题。我唯一想到的是database.yml文件没有在deploy.rb文件中显式链接。所以像
这样的一行set :linked_files, %w{config/database.yml}
会修复它。
我知道这是一个老问题,但是从OP了解有关问题和解决方案的更多细节会很有趣。