Я разработчик, пытающийся определить лучший подход к рельсовому приложению. Мне нужно предоставить несколько вариантов развертывания, и я пытаюсь минимизировать как затраты на разработку, так и затраты на долгосрочный хостинг.
Рассмотрим сайт, который позволяет нескольким авторам совместно работать над одной «работой», будь то роман, техническое руководство или даже исходный код. «Пользователям» разрешено «проверять» главы, вносить изменения и объединять изменения обратно. Пользователи оценивают модификации друг друга более высокими рейтингами, открывая доступ ко все большему и большему количеству контента. Назовем это «социальным контролем версий».
Хотя можно написать одно приложение rails, которое может различать «работы», с точки зрения кодирования может быть проще размещать каждую работу в виде собственного приложения rails. «Главное» приложение будет создавать / контролировать каждый экземпляр рабочего сервера, позволять просматривать произведения в поисках авторов и быть центром отчетности для владельца сайта. А пока предположим простейшую схему, в которой каждая работа использует URL-адрес порта:
Master - http://collabowork.it
My Novel - http://collabowork.it:3001
Some Manual - http://collabowork.it:3002
Another work - http://collabowork.it:3003
Мой вопрос: сколько экземпляров рельсов я смогу запустить на одном ящике, прежде чем он будет перегружен? Есть ли способ определить, сколько экземпляров может работать на обычном сервере? Есть ли другой вариант, который позволил бы недорого развернуть дополнительные работы (возможно, на EC2 или что-то подобное). Поскольку это не задумано как прибыльное предприятие, какой наименее затратный способ развернуть его (если не считать дополнительных усилий по кодированию). Я хотел бы провести какой-то анализ затрат, прежде чем предлагать альтернативы, но я не знаю, как начать определять размеры чего-то вроде этого.
Любые идеи или мысли приветствуются.
У меня есть нечто очень похожее на то, что есть у вас.
У нас одно приложение находится в одном каталоге. Это приложение настроено для разных клиентов. Единственная разница между каждым клиентом - это база данных, которую они используют. Когда мы его настраивали, я решил, что иметь отдельный порт для каждого клиента - это не очень красиво, поэтому мы выбрали другой подход.
Я знаю, что Apache не очень популярен в среде Rails, но это все еще отличная программа. Мы использовали виртуальный хост Apache на основе имен, чтобы решить эту проблему вместе с Passenger3. В новой версии вы можете определить RailsEnv для каждого виртуального хоста, используя тот же каталог приложения. Директива называется PassengerAppGroupName.
Виртуальный хост будет выглядеть примерно так:
<VirtualHost _default_:80>
ServerName preprod.xxxx.fr
DocumentRoot /var/xxxx/current/public/
TimeOut 5000
# Passenger directives
PassengerHighPerformance on
PassengerAppGroupName "preprod"
RailsEnv preprod
# Logging
ErrorLog /var/log/apache2/preprod-error.log
CustomLog /var/log/apache2/preprod-access.log combined
</VirtualHost>
Я думаю, этот пример должен прояснить ситуацию. Это решение позволяет разделять ваши приложения с помощью HTTP-хоста, используемого для подключения к нему.
Подводя итог, можно сказать, что если «работает» имеет одну и ту же базу кода, вы можете использовать это чистое решение IMHO.
РЕДАКТИРОВАТЬ : Что касается производительности, Apache / Passenger требуется 512 МБ ОЗУ. Я обнаружил, что все, что ниже, приведет к плохой производительности, кроме YMMV. Я не думаю, что потребуется больше ОЗУ, если вы добавите больше виртуальных хостов.