Назад | Перейти на главную страницу

Почему у amazon ec2 простои после развертывания, а у других идентичных серверов - нет?

Это озадачило меня последние несколько месяцев ... Я, по общему признанию, новичок в администрировании серверов, и я попробовал запустить производственное приложение rails на EC2. Хотя я многому научился и чувствую себя довольно комфортно, используя его, я не знаю, почему требуется ~ 1-2 минуты для обработки запроса после развертывания моего кода. Из всего, что я собрал через гугл, это что-то из-за того, что пассажир снова взлетает. Решение похоже на создание сценария непрерывного перезапуска.

Моя настройка сервера:

Здесь происходит все довольно простое ... почти никакой нестандартной конфигурации в какой-либо части стека. Сначала я развернулся на Amazon с помощью Rubber, но затем построил сервер с нуля, потому что предположил, что Rubber является причиной медленного раскрутки после развертывания ... но он все еще зависает. Конечно, я мог бы выполнить скользящий перезапуск, добавить еще один экземпляр и балансировщик нагрузки вместе с третьим экземпляром, который будет экземпляром базы данных, но на данный момент это не имеет смысла для этого проекта.

У меня есть несколько почти идентичных настроек серверов на других хостах (rails, nginx, пассажира и postgresql на CentOS), и они развертываются намного быстрее. У них нет почти одинаковой задержки между завершением развертывания ограничения и первым проходящим запросом.

добавление моего файла развертывания шапки

require 'rvm/capistrano'
require 'bundler/capistrano'
require 'sidekiq/capistrano'

set :stages, %w(production staging)
set :default_stage, "staging"
require 'capistrano/ext/multistage'

set :application, "bundio"
set :repository,  "git@bitbucket.org:my/project.git"
set :scm, "git"
set :shared_children, shared_children + %w{public/uploads} # include public/uploads in the shared folder to be symlinked across releases

ssh_options[:forward_agent] = true
ssh_options[:keys] = [File.join(ENV["HOME"], ".ec2", "my-keypair")]
set :deploy_to, "/var/www/apps/project"
set :rails_env, "production"
set :rvm_type, :system
set :rvm_path, "/usr/local/rvm"
set :keep_releases, 3

set :deploy_via, :remote_cache

desc "check production task"
task :check_production do

  if stage.to_s == "production"
    puts " \n Are you REALLY sure you want to deploy to production?"
    puts " \n Enter the password to continue\n "
    password = STDIN.gets[0..12] rescue nil
    if password != 'doubleCheck'
      puts "\n !!! WRONG PASSWORD !!!"
      exit
    end

  end

end



#############
### Hooks ###
#############

before "deploy", "check_production"

# if you want to clean up old releases on each deploy uncomment this:
after "deploy:restart", "deploy:cleanup"

after "deploy:update_code", "deploy:symlink_shared"
after "deploy:update_code", "deploy:migrate"
after "deploy", "deploy:restart_daemons" 


#################
### End hooks ###
#################

set :bundle_without, [:development,:test]

namespace :deploy do
  namespace :assets do
    task :precompile, :roles => :web, :except => { :no_release => true } do
      begin
        from = source.next_revision(current_revision)
      rescue
        err_no = true
      end
      if err_no || capture("cd #{latest_release} && #{source.local.log(from)} vendor/assets/ app/assets/ | wc -l").to_i > 0
        run %Q{cd #{latest_release} && #{rake} RAILS_ENV=#{rails_env} #{asset_env} assets:precompile}
      else
        logger.info "Skipping asset pre-compilation because there were no asset changes"
      end
    end
  end
  task :link_db do
    #run "ln -s #{shared_path}/config/database.yml #{latest_release}/config/database.yml"
  end

  task :start do ; end
  task :stop do ; end
  task :restart, :roles => :app, :except => { :no_release => true } do
    run "#{try_sudo} touch #{File.join(current_path,'tmp','restart.txt')}"
  end
  task :restart_daemons, :roles => :app do
    sudo "monit restart all -g daemons"
  end
  desc "Symlink shared/* files"
  task :symlink_shared, :roles => :app do
    run "ln -nfs #{shared_path}/config/database.yml #{release_path}/config/database.yml"
  end

end

У меня такая же задержка между развертыванием и поступлением первого запроса. Если у вас небольшой объем оперативной памяти, Пассажиру может потребоваться даже несколько минут, чтобы встать.

Корпоративная версия Passenger гарантирует, что вы сможете выполнить развертывание без простоев: http://www.modrails.com/documentation/Users%20guide%20Nginx.html#PassengerRollingRestarts