【问题标题】:Capistrano Rollback breaking Whenever CronjobCapistrano 回滚打破每当 Cronjob
【发布时间】:2017-12-10 18:16:07
【问题描述】:

问题似乎是在 capistrano 部署期间,创建的 cron 作业具有 RAILS_ENV=staging 与预期一样,因为部署环境是 staging。但是,在 capistrano 回滚中,创建的 cron 作业具有 RAILS_ENV=new_staging,其中 new_staging 是正在回滚的 capistrano 阶段。

我的日程安排文件

set :job_template, nil
job_type :rake,    "cd :path && :environment_variable=:environment bundle exec rake :task :output"

every 15.minute, roles: [:db] do
  rake "jobs:publish", output: lambda { "2>&1 >> /path/to/capistrano_directory/shared/log/jobs.log" }
end

我的 deploy/new_staging.rb 文件

set :branch, "develop"
set :deploy_env, 'staging'
set :rails_env, 'staging'

server "user@server_ip", :web, :app, :db, :metrics
role :db, "user@server_ip", :primary => true       # This is where Rails migrations will run
ssh_options[:forward_agent] = false                                # use local SSH keys remotely

ssh_options[:paranoid] = false

set :use_sudo, false
set :deploy_to, "/path/to/capistrano_directory"
set :unicorn_conf, "#{deploy_to}/current/config/environments/#{deploy_env}/unicorn.rb"
set :unicorn_pid, "#{deploy_to}/shared/pids/unicorn.pid"

before 'deploy:finalize_update', 'set_current_release'
before "deploy:finalize_update", "deploy:update_crontab"
after 'deploy:update_code', 'deploy:symlink_db'

namespace :deploy do
  task :symlink_db, :roles => :app do
    run "ln -nfs #{deploy_to}/shared/config/database.yml #{release_path}/config/database.yml"
  end

  task :start, :roles => :app, :except => { :no_release => true } do
    run "cd #{deploy_to}/current && bundle exec unicorn -c #{unicorn_conf} -E #{deploy_env} -D"
  end

  task :stop do
    run "#{try_sudo} kill -QUIT `cat #{unicorn_pid}`"
  end

  task :restart, :roles => :app, :except => { :no_release => true } do
    run "#{try_sudo} kill -s USR2 `cat #{unicorn_pid}`"
  end
end

task :set_current_release, :roles => :app, :except => { :no_release => true } do
  set :current_release, latest_release
end

还有我的 deploy.rb

require 'bundler/capistrano'
require 'capistrano/ext/multistage'
set :whenever_command, "bundle exec whenever"
set :whenever_environment, defer { stage }
set :whenever_roles, [:db, :metrics]
require "whenever/capistrano"

set :stages, %w(production staging new_staging)

set :application, "###"
set :repository,  "###"
set :deploy_via, :remote_cache
set :scm, :git

default_run_options[:shell] = '/bin/bash --login'

ssh_options[:forward_agent] = false
ssh_options[:paranoid] = false


namespace :deploy do
  desc "Update the crontab file"
  task :update_crontab do
    run "cd #{release_path} && RAILS_ENV=#{fetch(:rails_env)} bundle exec whenever --update-crontab #{application} --set environment=#{fetch(:rails_env)}"
  end
end
  • 任何版本 (0.9.7)
  • Capistrano 版本 (2.12.0)

运行Whenever gem 时,是什么导致回滚使用capistrano 阶段而不是rails_env?我怎样才能让它正确使用 rails_env?

【问题讨论】:

    标签: ruby-on-rails ruby capistrano whenever whenever-capistrano


    【解决方案1】:

    我对您的 staging 设置有点困惑(staging 和 new_staging 有什么区别?)。也就是说,您应该能够通过将 whenever_environment 更改为使用 rails_env 而不是 capistrano 设置的 stage 值来做到这一点:

    所以

    set :whenever_environment, defer { stage }
    

    会变成:

    set :whenever_environment, defer { rails_env }
    

    whenever README

    【讨论】:

    • 是的,我们正在将系统的暂存环境从拥挤的旧服务器转移到新的专用服务器...我认为这可能很简单,但我不是不确定为什么常规部署使用正确的变量?任务是否覆盖它?
    • 常规部署是指部署到production 还是staging?我认为这些工作是因为 capistrano 阶段与 rails_env 相同,当您 cap new_staging deploystage 变量设置为您指定的阶段 (new_staging) 时,这意味着它与 @987654333 不匹配@。不过我可能会错过你的问题:)
    • 好吧...在 cron 作业中执行bundle exec cap new_staging deploy 导致RAILS_ENV=staging,但bundle exec cap new_staging deploy:rollback 导致RAILS_ENV=new_staging
    • 啊,不幸的是我不知道那里。它可能在回滚任务的某个地方被破坏了。我不熟悉回滚行为,因为我通常只是重新部署旧版本而不是依赖回滚。
    • 仔细观察,确实看起来任务手动覆盖了默认环境配置。不知道为什么会这样,但至少它现在可以工作了
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2021-07-29
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多