Получайте 504 Gateway Time-out после развертывания на ec2 с использованием резины - PullRequest
Новая
       28

Получайте 504 Gateway Time-out после развертывания на ec2 с использованием резины

2 голосов
/ 22 февраля 2012

Я использовал резиновый камень для развертывания моего приложения на ec2.Я следовал приведенным здесь инструкциям: http://ramenlab.wordpress.com/2011/06/24/deploying-your-rails-app-to-aws-ec2-using-rubber/.
Процесс, кажется, завершился успешно, но когда я пытаюсь использовать приложение, я продолжаю получать тайм-аут 504 шлюза.Почему это происходит и как мне это исправить?

Ответы [ 2 ]

1 голос
/ 28 мая 2013

Я получил ту же ошибку и решил проблему.Это был тайм-аут "haproxy".Это балансировщик нагрузки, установленный компанией Rubber.Он установлен на 30000 мс, вы должны изменить его в файле конфигурации резины.

Удачи!

1 голос
/ 16 мая 2012

Ответ от Мэтью Конвея (оставлен ниже): https://groups.google.com/forum/?fromgroups#!searchin/rubber-ec2/504/rubber-ec2/AtEoOf-T9M0/zgda0Fo1qeIJ

Примечание: даже с этим кодом вам нужно сделать что-то вроде:

> cap deploy: update

> FILTER = app01, cap приложения app02 развернуть: перезапустить

> FILTER = app03, app04 cap cap: перезапустить

Я полагаю, это приложение для рельсов? Стек рельсов, как известно, медленно загружается, поэтому эта задержка во времени загрузки, вероятно, то, что вы видите. Пассажир должен был сделать это лучше с функцией нулевого времени простоя v3, но, похоже, он отказался от этого и собирается предлагать ее только как часть неоплаченной платной версии в какой-то неопределенной точке в будущем.

Что я делаю, так это имею несколько экземпляров сервера приложений и перезагружаю их последовательно, чтобы я мог продолжать обслуживать трафик на одном, пока другие перезагружаются. Не работает с одним экземпляром, но большинству производственных установок в любом случае требуется несколько экземпляров для избыточности / надежности. На данный момент это не часть резины, но я настроил сценарии развертывания для моего приложения и в какой-то момент объединю его - моя конфигурация выглядит примерно так, как показано ниже.

Мэтт

резино-passenger.yml: 

roles:
  passenger:
    rolling_restart_port: "#{passenger_listen_port}"

  web_tools:
    rolling_restart_port: "#{web_tools_port}"

разворачивать-apache.rb: 

on :load do
  rubber.serial_task self, :serial_restart, :roles => [:app, :apache] do
    rsudo "service apache2 restart"
  end
  rubber.serial_task self, :serial_reload, :roles => [:app, :apache] do
    # remove file checked by haproxy to take server out of pool, wait some
    # secs for haproxy to realize it
    maybe_sleep = " && sleep 5" if RUBBER_ENV == 'production'
    rsudo "rm -f #{previous_release}/public/httpchk.txt #{current_release}/public/httpchk.txt#{maybe_sleep}"

    rsudo "if ! ps ax | grep -v grep | grep -c apache2 &> /dev/null; then service apache2 start; else service apache2 reload; fi"

    # Wait for passenger to startup before adding host back into haproxy pool
    logger.info "Waiting for passenger to startup"

    opts = get_host_options('rolling_restart_port') {|port| port.to_s}
    rsudo "while ! curl -s -f http://localhost:$CAPISTRANO:VAR$/ &> /dev/null; do echo .; done", opts

    # Touch the file so that haproxy adds this server back into the pool.
    rsudo "touch #{current_path}/public/httpchk.txt#{maybe_sleep}"
  end
end

after "deploy:restart", "rubber:apache:reload"


desc "Starts the apache web server"
task :start, :roles => :apache do
  rsudo "service apache2 start"
  opts = get_host_options('rolling_restart_port') {|port| port.to_s}
  rsudo "while ! curl -s -f http://localhost:$CAPISTRANO:VAR$/ &> /dev/null; do echo .; done", opts
  rsudo "touch #{current_path}/public/httpchk.txt"
end
...