И тоже самое с джобами

Тогда понятно кто что вызывает

еще стоит настроить какой-нить downdetector для всего. Я использую uptimerobot.com

Это кстати хороший совет, желательно хелсчек использовать, но там свои заморочки есть с ним в том плане, что это не просто OK эндпоинт должен быть

да, для апи я использую один из самых легких публичных ендпоинтов, но который таки дергает базу

Уважаемые, в puma учитывая https://github.com/puma/puma/blob/0ea7af5e2cc8fa192ec82934a4a47880bdb592f8/lib/puma/configuration.rb#L333-L335 (что бы не открывать ссылку - если использовать preload_app!, то pumactl phased-restart (zero-time deployment feature) выключает воркеры (не мастер) "одновременно", nginx и сокет при этом не страдают, по этому это как бы не down-time, а супер долгий ответ от сервера, пока worker-ы не начнут подниматься) - вы предпочитаете preload_app! + дополнительные "возможные задержки для пользователя" или красивый phased-restart? На что обратить внимание при "личном выборе"?

UPD: из доки по puma:
> In clustered mode, Puma can "preload" your application. This loads all the application code prior to forking. Preloading reduces total memory usage of your application via an operating system feature called copy-on-write.
Насколько это прям "полезно"? Как оценить "реальную экономию"? У меня нет "особо возможности" проверять это в проде.

Я предпочитаю не делать phased restart, чтобы было проще с миграциями

деплои по много раз в день и никто ничего не замечает

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

ну и еще 80% трафика унас идет с телефонов, так что как-то глупо переживать, что на какое-то время пропадет связь с сервером, когда эта связь и так не очень-то стабильная

это на практике довольно бессмысленно из-за сборщика без  компакшена. Его вроде завезли в 2.7, это значит, что перед форком нужно 1) собрать весь мусор 2) сделать компакшен. И вот только потом можно ожидать какого-то эффекта. Я сам не пробовал, да и вообще мало кто пробовал, ситуация будет варьироваться от приложения к приложению

мб у гитхаба где-то есть графики, потому что компакшеном Аарон занимался

вроде бы в этой статье есть полезное по этой теме, но я не очень-то шарю, чтобы судить
https://brandur.org/ruby-memory

я тут запили CI/CD на докерах, свормах и гитхабовских екшенах с реджистри и zero-downtime, все никак статью не допишу 🙁

цели и необходимости переходить на докер нет сейчас, спасибо.

я попробовал сравнить, с copy-on-write даже если стартуешь много воркеров памяти на начальном этапе использует как под один процесс. Если же стартуешь несколько воркеров с preload_app! грузится все полностью. Т.е. если приложения будт интенсивно "изменять" содержимое "расшариной" памяти, то в конце концов доростем до "полного" размера...

ну вот я прямо доволен пеерездом, плюс в интернете куча гайдов типа “Dockerize your Rails app”, но такое ощущение что их под копирку писали копирайтеры
там огромное количество проблем, которое вообще не решено от слова никак
я три недели потел пока собрал свой идеальный конфиг и все проблемы смог решить

я дружу с докером. Использую tmpfs что-бы базочку в ram деражть для быстрых тестов. Эксперименты делаю внутри контейнеров. На предыдущем проекте весь env запихнул в докер (10-11 сервисов). Но в текущем в этом "сейчас" нет "необходимости" - другими словами - лучше обойтись пока что.

а по сетапам, очень годные советы были для меня здесь - https://evilmartians.com/chronicles/ruby-on-whales-docker-for-ruby-rails-development
в остальном образ собирательный. Уже года 4 его использую по потребности.