cap v3 rails 4乘客部署无法启动Web应用程序,因为找不到Gemfile

时间:2014-09-25 00:49:52

标签: ruby-on-rails nginx capistrano rbenv

当我们部署到我们的服务器时,所有部署都很好,但是我们之后得到错误“Gemfile not found”。起初我以为这是nginx无法启动,但如果我重新启动该框,则错误消失,应用程序完美运行。我们正在尝试确定这种情况发生的原因以及如何解决这个问题。截至目前,我不知道从哪里开始,似乎没有什么我似乎研究“谷歌”已经找到答案。

服务器设置和部署的细分:

  • rails 4
  • rbenv
  • ruby​​ 2.1.0
  • capistrano v3
  • 乘客
  • 使用厨师构建服务器

Capfile:

require 'pry'
# Load DSL and Setup Up Stages
require 'capistrano/setup'

# Includes default deployment tasks
require 'capistrano/deploy'

# Includes tasks from other gems included in your Gemfile
#
# For documentation on these, see for example:
#
#   https://github.com/capistrano/rvm
#   https://github.com/capistrano/rbenv
#   https://github.com/capistrano/chruby
#   https://github.com/capistrano/bundler
#   https://github.com/capistrano/rails/tree/master/assets
#   https://github.com/capistrano/rails/tree/master/migrations
#
# require 'capistrano/rvm'
require 'capistrano/rbenv'
# require 'capistrano/chruby'
require 'capistrano/bundler'
# require 'capistrano/rails/assets'
require 'capistrano/rails/migrations'

# Loads custom tasks from `lib/capistrano/tasks' if you have any defined.
Dir.glob('lib/capistrano/tasks/*.cap').each { |r| import r }

deploy.rb:

set :application, 'api'

set :scm, :git
set :repo_url, 'git@github.com:PlacewiseMedia/API.git'
set :branch, 'develop'
set :deploy_to, '/home/apps/api'

set :deploy_via, :remote_cache
set :keep_releases, 10
set :user, 'deploy'
set :use_sudo, false

set :rbenv_type, :system
set :rbenv_ruby, '2.1.0'
set :rbenv_path, '/opt/rbenv'

namespace :deploy do

  desc 'Restart application'
  task :restart_application do
    on roles(:app), in: :sequence, wait: 5 do
      spacer("Setting up restart file")
      execute "mkdir -p #{release_path}/tmp ; touch #{release_path}/tmp/restart.txt"
      spacer("Restarting the nginx service")
      execute "sudo service nginx restart"
      spacer()
    end
  end

  desc 'Run Migrations'
  task :update_database do
    on roles(:app), in: :sequence, wait: 5 do
      within(release_path) do
        with rails_env: fetch(:rails_env) do
          spacer("Updating the database")
          execute :rake, "db:migrate", "--trace"
          spacer()
        end
      end
    end
  end

  desc 'Create application symlinks'
  task :shared_links do
    on roles(:app), in: :sequence, wait: 5 do
      spacer("Creating application symlinks")
      execute "rm #{release_path}/config/database.yml"
      execute "ln -s #{shared_path}/config/database.yml #{release_path}/config/database.yml"
      execute "ln -s #{shared_path}/config/secrets.yml #{release_path}/config/secrets.yml"
      execute "ln -s #{shared_path}/bin/passenger #{release_path}/bin/passenger"
      spacer()
    end
  end

  after 'deploy:updated', 'deploy:shared_links'
  after :finishing, 'deploy:update_database'
  after :finishing, 'deploy:restart_application'
  after :finishing, 'deploy:cleanup'
end

namespace :setup do
  desc 'Copy the secrets.yml and database.yml files'
  task config: ['config/secrets.yml', 'config/database.yml'] do |t|
    on roles(:all) do
      execute "mkdir -p #{shared_path}/config"
      t.prerequisites.each do |file|
        upload! file, "#{shared_path}/config"
      end
    end
  end
end

def spacer(desc = nil)
  puts "-----------------------------------------------------------------------------"
  if desc
    puts desc
    puts "-----------------------------------------------------------------------------"
  end
end

错误:

enter image description here

更新09/25:太平洋标准时间下午02:10

使用https://hackhands.com/后,我们发现nginx的多个实例正在运行,如下所示:

enter image description here

我可以努力终止服务并重新启动它,但似乎有些东西可能无法通过厨师或我们的帽子部署在服务器上正确配置。如果我重新启动框,事情按照说明工作,但我们也试图杀死nginx服务。我们发现它也有效。我们的开发团队正在努力解决这个问题,但我们仍然对这种情况如何发生或如何修复感到困惑。

更新09/26:太平洋标准时间上午11:06

  

如果你的话,我发现乘客旋转的配置来自哪里   查看/etc/service/您将看到应用程序的文件夹   在服务器上。查看您感兴趣的文件夹中的run文件   在,你会看到乘客配置。这会触发ruby .bin/passenger start进程,然后会触发/tmp nginx   应用程序重启时挂起的进程。我已经尝试重新启动了   不同的组合,似乎有效的是杀死nginx   进程,然后运行sudo killall ruby重新生成新应用程序...   不理想

1 个答案:

答案 0 :(得分:1)

因此,我们的DevOps团队为解决此问题所做的更新围绕着乘客产生nginx的方式。它使用的配置是以前版本中较旧的spawn-lv2,我将其更改为当前版本4的spawn。这样做似乎是停止在{{1}中创建新目录由runit脚本引用但由于旧版本仍在运行而失败。现在看起来更新是在当前/tmp目录中完成的,因此进程仍在运行并不重要。

此更新已完成到chef中的rackbox默认属性:default [“rackbox”] [“default_config”] [“passenger_runit”] [“spawn_method”] =“smart”