Столкнулся с такой задачей. Нужно как-то разместить 250 rails-приложений и желательно на одном сервере. Причем на каждом возможно потом появится Delayed Job или Rescue, что совсем сбивает с толку. Нагрузка на каждое будет маленькая. Но очень важна надежность — если какое-то из них упадет, будет очень плохо.
На каждое приложение запускать свой юникорн очень затратно. Даже 32Гб оперативки может не хватить.
Phusion Passenger, говорят, очень не надежный (или это не правда?). Кто-нибудь сталкивался с такой проблемой? Реально ли на одном серваке все это сделать?
Если сталкивались, может еще посоветуете, как их проще потом админить (обновлять из git-репа, проверять статус — работает или нет)? Или тут только свои скрипты писать?
Подкрутите в пассажире, чтобы максиум один инстанс на приложение был, ну и пул на 100 инстансев. Если приложение будут использовать более-менее похожий набор гемов то расход оперативы в пассажире будет не такой уж и большой на каждое из них. То есть память занимаемая рельсами должна шарится между инстансами.
Деплоить все это лушче всего капистрано.
Мне кажется, что вы пытаетесь сделать 1 клиент = один кастомизированный вариант приложения. В таком случае лучше задайте себе вопрос как вы будите поддерживать все приложения?
Сейчас приложение будет одно и то же, просто нужны разные БД. Я уже думал над тем, чтобы переписать его под одну БД, но я не знаю как оно будет дальше развиваться. Возможно появится несколько веток, или обновления станут платными для каждого клиента. Вообще без понятия куда все это развиваться будет, поэтому пока лучше для каждого клиента — отдельная бд и свой код.
А вы пользовались пассажиром? Как у него с надежностью? Спрашивал нескольких человек, все от него отказались, но не помнят почему. «Глючный» — все, что могли сказать.
Были проблемы у меня с каким-то определнным сочетанием rubygems и верссии пассажира. В основном все нормально, для хостинга мелких приложений использую как раз пассажир.
Небольшой совет про распиливание приложения для каждого клиента, постарайтесь как можно больше унифицировать все. Так как я пару раз сталкивался с такой ситуацией, когда несколько десятков клиентов и большое приложение, в итоге через пару лет это становится совсем не поддерживаемым. Если хочется кастомизации какой-то попробуйте сделать через engines, посмотрите, например, как сделано spree
Нет у Passenger'а никаких проблем с надежностью.
В сторону Unicorn люди уходят по трем причнам:
1. Zero downtime deploy
2. Возможность экономии памяти на Ruby 1.9 (т.к. REE c COW этой версии нет, а у unicorn есть хуки)
3. Потому что модно (самый частый вариант)
В вашем случае — 1 инстанс rails ~= 250Mb (меряйте для вашего приложения _после_ нескольких часов работы инстанса). Итого 250*250 = много памяти.
Если приложение одно, то может и обслуживать его как одно, но мультидоменное? Да, это вносит сложность, но на ресурсах вы значительно экономить будете.
Используйте thin, часто его достаточно, а для защиты от большинства форс-мажоров запускайте его инстансы через runit и мониторьте http через monit/god/bluepill.
Но исходя из ваших исходных данных — все может быть обработано одним приложением под unicorn.
Простой
