Посты по тегу: Ruby

05/12/2019
Раздел: How To

Рестарт Passenger без простоя из Capistrano

Когда у вас достаточно нагруженный проект на RoR и для запуска вы используете Passenger, то рестарт приложения может вызывать небольшой (а иногда и простой) простой. Это не есть хорошо.

Passenger имеет две версии - Open Source и Enterprise. Так вот в Enterprise версии есть опция --rolling-restart, которая и позволяет не перезапускать сразу все инстансы приложения, а делать это поочереди.

В Capistrano это настраивается элементарно:

set :passenger_restart_options,
  -> { "#{deploy_to} --ignore-app-not-running --rolling-restart" }

Мониторим перезапуск вот так:

passenger-status

26/11/2019
Раздел: How To

Тэги: Capistrano, Ruby

Деплой на много хостов с Capistrano

Не так часто, но бывает надо сделать деплой на, скажем, 20 хостов, которые находятся за bastion'ом.

Если у вас 5 хостов и все работает как часы, то нет проблем, казалось бы. Увеличиваем количество хостов, запускаем деплой, profit.

Но чаще всего вы получите ошибку и будете очень долго удивляться, как же так...

Ошибка будет вида:

cap aborted!
Errno::EPIPE: Broken pipe
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/net-ssh-3.2.0/lib/net/ssh/transport/server_version.rb:44:in `write'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/net-ssh-3.2.0/lib/net/ssh/transport/server_version.rb:44:in `negotiate!'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/net-ssh-3.2.0/lib/net/ssh/transport/server_version.rb:32:in `initialize'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/net-ssh-3.2.0/lib/net/ssh/transport/session.rb:84:in `new'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/net-ssh-3.2.0/lib/net/ssh/transport/session.rb:84:in `initialize'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/net-ssh-3.2.0/lib/net/ssh.rb:232:in `new'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/net-ssh-3.2.0/lib/net/ssh.rb:232:in `start'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/sshkit-1.11.2/lib/sshkit/backends/connection_pool.rb:59:in `call'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/sshkit-1.11.2/lib/sshkit/backends/connection_pool.rb:59:in `with'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/sshkit-1.11.2/lib/sshkit/backends/netssh.rb:155:in `with_ssh'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/sshkit-1.11.2/lib/sshkit/backends/netssh.rb:49:in `upload!'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/capistrano-3.6.1/lib/capistrano/tasks/git.rake:24:in `block (3 levels) in <top (required)>'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/sshkit-1.11.2/lib/sshkit/backends/abstract.rb:29:in `instance_exec'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/sshkit-1.11.2/lib/sshkit/backends/abstract.rb:29:in `run'
/Users/khiem-nguyen/workspace/ruby/nenga-onepiece/cl-chef/deploy/vendor/bundle/ruby/2.3.0/gems/sshkit-1.11.2/lib/sshkit/runners/parallel.rb:12:in `block (2 levels) in execute'
Tasks: TOP => git:check => git:wrapper
The deploy has failed with an error: Broken pipe
** Invoke deploy:failed (first_time)
** Execute deploy:failed


** DEPLOY FAILED
** Refer to log/capistrano.log for details. Here are the last 20 lines:

И дальше еще большой стэк-трейс, который вам ровным счетом ничего не даст.

Опытным путем вы прийдете к тому, что 10 хостов деплоятся нормально, а вот 11 уже нет. И дело тут совсем не в Capistrano, а в вашем ssh сервере на bastion'е.

Во всем виноваты значения по умолчанию опции MaxStartups. Увеличьте ее первое значение и все у вас полетит, как вы того ожидаете.

Итак, было:

# MaxStartups 10:30:60

Стало:

MaxStartups 30:30:60

01/02/2013
Раздел: Linux

Тэги: error, ruby

Ruby и ошибка InvalidByteSequenceError

Столкнулся вот на виртуальных машинах LXC с проблемой, когда запуск приложения не удается с ошибкой типа:

:in `read': "\xD0" on US-ASCII (Encoding::InvalidByteSequenceError)

Лечится очень просто. Нужно добавить в /etc/environment:

LC_TYPE=en_US.UTF-8

Потом создать локаль:

$ sudo locale-gen en_US.UTF-8

И перезайти.

18/10/2012
Раздел: Linux

Тэги: chef, gems, ruby

Падение сервера Chef после обновления системных rubygems

Столкнулся вот на работе с такой проблемой - после перезагрузки виртуалки с Chef-server этот самый Chef не запустился. Грязно выругался на меня:

Starting chef-server /usr/lib/ruby/1.8/rubygems/remote_fetcher.rb:14: uninitialized constant Gem::UserInteraction (NameError)
from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:36:in gem_original_require' from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:36:inrequire'
from /usr/lib/ruby/1.8/rubygems/spec_fetcher.rb:4
from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:36:in gem_original_require' from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:36:inrequire'
from /usr/lib/ruby/vendor_ruby/chef/provider/package/rubygems.rb:32
from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:36:in gem_original_require' from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:36:inrequire'
from /usr/lib/ruby/vendor_ruby/chef/providers.rb:60
from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:36:in gem_original_require' from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:36:inrequire'
from /usr/lib/ruby/vendor_ruby/chef.rb:25
from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:36:in gem_original_require' from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:36:inrequire'
from /usr/sbin/chef-server:40

В результате я получил не работающий сервер шефа.

Как оказалось все дело в том, что я обновил в системе rubygems до 1.8. После этого все и случилось. Правда вылечить удалось тоже достаточно просто и быстро:

$ sudo gem update --system 1.3.7

После этого можно стартовать chef-server и chef-server-webui.

Страница 1 / 1