Puma предоставляет три различных вида операций перезапуска, каждый из которых предназначен для разных случаев использования. В этом документе описывается "горячий перезапуск" и "фазированный перезапуск". Третий вид операции перезапуска называется "refork" и описан в документации для fork_worker.

Горячий перезапуск

Для выполнения "горячего" перезапуска Puma выполняет операцию exec, чтобы снова запустить процесс, поэтому между старым и новым процессом не происходит обмена памятью. В результате, перезапуск можно выполнять в любом месте, где вы бы вручную остановили Puma и снова его запустили. В частности, безопасно обновлять Puma само при помощи горячего перезапуска.

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

Как это сделать

Любое из следующего приведет к выполнению горячего перезапуска Puma сервера:

• Отправьте сигнал SIGUSR2 процессу puma
• Выполните GET-запрос к серверу статуса/управления Puma с путем /restart
• Выполните pumactl restart (это использует метод управления сервером, если он доступен, в противном случае отправляет сигнал SIGUSR2 процессу)

Поддерживаемые конфигурации

• Работает в режиме кластера и одиночного режима

• Поддерживается на всех платформах### Опыт клиента

• Все платформы: клиенты с активными запросами получают ответы перед тем, как соединение будет закрыто грациозно. Puma грациозно отключает любые бездействующие HTTP-соединения перед перезапуском.

• На MRI или TruffleRuby на Linux и BSD: клиенты, которые подключаются непосредственно перед перезапуском сервера, могут столкнуться с увеличенной задержкой, пока сервер не остановится и не запустится снова, но их соединения не будут закрыты преждевременно.

• На Windows и JRuby: клиенты, которые подключаются непосредственно перед перезапуском, могут столкнуться с ошибками "connection reset".### Дополнительные примечания

• Новый запущенный процесс Puma изменяет текущую рабочую директорию на директорию, указанную опцией directory. Если directory указывает на символическую ссылку, это автоматически переоценивается, поэтому эту механику можно использовать для обновления приложения.

• В любой момент времени работает только одна версия приложения.

• on_restart вызывается сразу перед тем, как сервер останавливается. Это можно использовать для освобождения ресурсов (например, долгоживущих соединений с базой данных) грациозно. С Ruby 2.0 обычно не требуется явно закрывать дескрипторы файлов при перезапуске. Это связано с тем, что любой дескриптор файла, открытый Ruby, имеет установленный флаг FD_CLOEXEC, что означает, что дескрипторы файлов закрываются при exec. Тем не менее, on_restart полезен, если вашему приложению необходимо выполнить какие-либо более грациозные процедуры завершения работы, специфичные для протокола, перед закрытием соединений.

Постепенный перезапускПостепенный перезапуск заменяет всех работающих рабочих процессов в кластере Puma. Это полезный способ грациозного обновления приложения, которое обслуживает Puma. Постепенный перезапуск работает путём сначала убийства старого рабочего процесса, затем запуска нового рабочего процесса, ожидания успешного запуска нового рабочего процесса перед переходом к следующему рабочему процессу. Этот процесс продолжается до тех пор, пока все рабочие процессы не будут заменены. Основной процесс не перезапускается.

Как это сделать

Любое из следующего приведёт к выполнению постепенного перезапуска Puma сервером:

• Отправьте сигнал SIGUSR1 процессу puma
• Выполните запрос GET к серверу статуса/управления Puma с путём /phased-restart
• Выполните команду pumactl phased-restart (эта команда использует метод управления сервером, если он доступен, в противном случае отправляет сигнал SIGUSR1 процессу)

Поддерживаемые конфигурации

• Работает только в режиме кластера
• Чтобы поддерживать обновление приложения, которое обслуживает Puma, убедитесь, что prune_bundler включен и что preload_app! отключен
• Поддерживается на всех платформах, где поддерживается режим кластера

Опыт клиента* Входящие запросы всегда обслуживаются ответами перед грациозным закрытием соединения.

• Бездействующие постоянные соединения грациозно отключаются.
• Новые соединения не теряются, и клиенты не столкнутся с увеличением задержки (пока количество настроенных рабочих процессов больше одного).### Дополнительные примечания
• Когда начинается постепенный перезапуск, основной процесс Puma изменяет текущую рабочую директорию на директорию, указанную опцией directory. Если directory указывает на символическую ссылку, это автоматически переоценивается, поэтому этот механизм можно использовать для обновления приложения.
• На одном сервере возможно, что во время постепенного перезапуска будут одновременно работать две версии приложения.
• on_restart не вызывается
• Постепенные перезапуски могут быть медленными для кластеров Puma с большим количеством рабочих процессов. Горячие перезапуски часто завершаются быстрее, но за счёт увеличения задержки во время перезапуска.
• Постепенные перезапуски не могут использоваться для обновления любых джемов, загруженных основным процессом Puma, включая puma сам по себе, а также всё, что находится в extra_runtime_dependencies и их зависимостей. Обновление других джемов безопасно.
• Если вы удаляете джемы из старых выпусков как часть своей стратегии развертывания, есть дополнительные соображения. Не добавляйте никакие джемы в extra_runtime_dependencies, которые имеют native расширения или имеют зависимости, которые имеют native расширения (одним из распространённых примеров является puma_worker_killer и его зависимость от ffi). Рабочие процессы будут завершаться с ошибкой при запуске во время постепенного перезапуска.Подобная проблема зафиксирована в проблеме проекта rubygems. Горячие перезапуски являются вашим единственным вариантом здесь, если вам необходимы эти зависимости.