Изпълнение на тънко рестартиране след внедряване на код на релси, постоянни 502 грешки на лош шлюз

Проблем: Всички заявки, направени, докато тънкият се рестартира, водят до 502 Bad Gateway Errors.

Когато разположа промени в кода на моя сървър, трябва да рестартирам тънкия, за да влязат в сила новите промени. Моят тънък конфигурационен yml изглежда така:

chdir: /var/www/appname
servers: 6
environment: production
onebyone: true
wait: 30
no-epoll: true
address: 0.0.0.0
port: 3000
timeout: 30
log: log/thin.log
pid: tmp/pids/thin.pid
max_conns: 1024
max_persistent_conns: 512
require: []
daemonize: true

Моето разбиране беше, че свойството "onebyone" ще гарантира, че поне 1 сървър винаги е на разположение, за да отговаря на заявки. Това, което се случва обаче, е, че всички заявки, направени до приключване на рестартирането на всички сървъри, ще доведат до грешки 502 Bad Gateway или 504 Gateway Time-out. Как мога да гарантирам, че моите заявки винаги се обработват правилно, след като пусна нов код в продукция?

АКТУАЛИЗАЦИЯ

тънките регистрационни файлове показват тази грешка:

/usr/local/lib/ruby/gems/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:572:in `start_tcp_server': no acceptor (RuntimeError)
    from /usr/local/lib/ruby/gems/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:572:in `start_server'
    from /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/backends/tcp_server.rb:16:in `connect'
    from /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/backends/base.rb:53:in `block in start'
    from /usr/local/lib/ruby/gems/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run_machine'
    from /usr/local/lib/ruby/gems/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run'
    from /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/backends/base.rb:61:in `start'
    from /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/server.rb:159:in `start'
    from /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/controllers/controller.rb:86:in `start'
    from /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/runner.rb:185:in `run_command'
    from /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/runner.rb:151:in `run!'
    from /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.3.1/bin/thin:6:in `<top (required)>'
    from /usr/local/bin/thin:19:in `load'
    from /usr/local/bin/thin:19:in `<main>'

Рестартирам с sudo thin -C /etc/thin/appname.yaml restart

Изглежда, че това, което се случва, е, че тънък се опитва да слуша на порт 3000, но предишният тънък процес все още работи на този порт? Защо би се случило това?


ruby-on-rails deployment ruby-on-rails-3 thin
person D-Nice    schedule 11.11.2012    source източник
comment
Използвате ли уеб сървър пред тънък (напр. nginx)?   -  person Andrew Marshall    schedule 11.11.2012
comment
Да, използвам nginx. Мисля, че това, което се случва, е, че nginx не може да говори с тънък, защото нещо странно се случва по време на тънкото рестартиране.   -  person D-Nice    schedule 11.11.2012

Отговори (1)


arrow_upward
1
arrow_downward

Когато Thin спре, той изтрива файла на сокета, докато комуникира с Nginx, и след това го създава отново при успешно стартиране. Дори със спрян Thin, NGinx все още слуша за уеб заявки. Ако в този момент бъде направена заявка към Nginx, това ще доведе до грешка, както споменахте. Това просто означава, че Thin не е успял да стартира правилно или да се свърже към сокет във вашия случай. Това може да означава, че се опитвате да спрете и започнете твърде бързо.

Задача за ограничение като тази би трябвало да работи добре.

task :restart do
  sudo "bundle exec thin restart -C thin.yml"
end

Това все още ли е проблем, когато onebyone бъде премахнат?

Освен това намерих тази статия за много полезна за прилагане на подвижни рестарти с Thin и Capistrano - http://pointatstar.wordpress.com/2011/01/17/rolling-restart-for-thin-cluster-via-capistrano/

Лично аз използвах Unicorn, тъй като има вградено подвижно рестартиране. Беше разгледано в RailsCast - http://railscasts.com/episodes/373-zero-downtime-deployment

person Akshay Rawat    schedule 11.11.2012
comment
Да, все още е проблем с премахването на oneoneby. Сега не използвам Capistrano и се надявах да не се налага да добавям други скъпоценни камъни към моята настройка в името на простотата. Unicorn звучи интересно - ще бъде ли заместител на тънък или допълнение към тънък? - person D-Nice; 11.11.2012
comment
Това е страхотен заместител на Thin. Преди време напуснах Thin за Unicorn. Най-голямата функция е, че можете да помолите Unicorn да създаде множество процеси и той ще ги управлява/домакиня. В Thin трябва да управлявате всеки Thin процес сами чрез God, Monit и т.н. NGinx + Unicorn е изборът по подразбиране в наши дни. - person Akshay Rawat; 11.11.2012
comment
За отстраняване на грешки просто поставете сън от 5 секунди между спиране и стартиране и вижте. Предполагам, че се опитва да започне, преди да спре напълно. Виждал съм това преди и си спомням, че го поправих чрез стартиране/спиране по друг начин. Можете ли да добавите този детайл към въпроса си. - person Akshay Rawat; 11.11.2012
comment
Страхотно, поне имам добра алтернатива, ако не мога да поправя това. Въпросът е редактиран, за да се добави исканата от вас информация. Мислех, че използването на „рестартиране“ вместо „стоп“ и „старт“ ще бъде единственият начин да се гарантира, че инстанция на thin винаги ще бъде достъпна за обслужване на заявки. - person D-Nice; 12.11.2012