Лучшие практики для новых развертываний Rails в Linux? - PullRequest
31 голосов
/ 11 ноября 2008

Я использовал прямой Mongrel, я использовал кластеры Mongrel позади Apache, я смотрел на Thin, и Пассажир очень заинтриговал меня. Я тоже смотрел на Nginx. Я посмотрел на MRI, Ruby Enterprise Edition, Rubinius и JRuby. Есть много вариантов, каждый из которых претендует на звание нового Святого Грааля.

Каков наилучший вариант для нового, полностью обновленного развертывания? Единственные предположения таковы:

  • Приложение на основе Rails 2.2. (Я знаю, что 2.2 еще не полностью выпущен, но и это не развертывание.)
  • Сервер на основе Linux. Вероятно, Ubuntu Hardy, но на самом деле, все, что работает лучше всего в этом случае.
  • Rails должен быть полностью функциональным и, вероятно, общаться с базой данных MySQL.
  • Все остальное является предметом переговоров.

Учитывая эти особенно широкие ограничения, какая комбинация программного обеспечения даст наилучший результат с точки зрения параллелизма и низких издержек?

Я склоняюсь к Apache с «рабочим» mpm и Passenger + Ruby Enterprise Edition, просто потому, что он обеспечивает немедленную стабильность и простоту настройки и обслуживания.

Скорее всего, мне будет лучше с другим вариантом?

Ответы [ 9 ]

16 голосов
/ 11 ноября 2008

Я перешел с Mongrel Cluster на Passenger две недели назад (Debian Linux Server). Я не оглядывался ни на секунду. Пассажир, вероятно, самый простой способ запустить новый сервер. Производительность и надежность также разумны.

Лично я предпочитаю тратить свое время на разработку новых проектов Rails, а не заниматься вопросами развертывания - Passenger позволяет мне делать именно это. Тем не менее, Mongrel или что-то еще может быть предпочтительным, если у вас есть какие-то особые требования (не распространяется на большинство продуктов).

10 голосов
/ 13 ноября 2008

Этим утром DHH говорит об этой самой теме в своем блоге:

Но почему-то послание Пассажира было немного медленным. В нем уже тонна больших сайтов. Включая Shopify, MTV, Geni, Yammer, и вскоре мы переберем сначала Ta-da List, а затем, надеюсь, вскоре после этого остальные из набора 37signals.

Таким образом, хотя все еще есть причины для запуска собственной настраиваемой многоуровневой настройки настроенных вручную компонентов, точно так же, как есть люди, которые не хотят использовать mod_php для своих деталей, я думаю, что мы наконец-то остановились на ответе по умолчанию. То, что не требует, чтобы вы действительно задумывались о первом развертывании вашего Rails-приложения. То, что просто работает из коробки. Даже если этот ящик является общим хостом!

http://www.loudthinking.com/posts/30-myth-1-rails-is-hard-to-deploy

Тобиас Льюк на тему переключения Shopify (миллион запросов / день) на Пассажира:

Все это означает, что общий объем памяти, который используется Shopify во время обычной работы, увеличился с 9 ГБ до 5 ГБ. Мы равномерно распределили экономию по большему количеству процессов Shopify и большему количеству memcached пространства, что увеличило наше среднее время отклика с 210 мс до 130 мс, а трафик вырос на 30% за последние несколько месяцев.

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

http://blog.leetsoft.com/2008/11/15/passenger

4 голосов
/ 11 ноября 2008

Мы использовали старый стандартный стек nginx -> mongrel в течение последних 18 месяцев, и хотя настраивать его в первый раз было несложно, он оказался гибким и имел дело с некоторыми сайтами с очень высоким трафиком для нас. Nginx, в частности, был абсолютно надежным и быстрым, и если вы можете получить кэширование страниц своего приложения, вы сможете справиться с большим количеством запросов.

Застрявшие дворняги были проблемой, поэтому мы используем monit, чтобы убить их, когда они плохо себя ведут. Опять же, это было не совсем тривиально, но на этом этапе мы использовали один и тот же процесс на многих сайтах.

Мы еще не играли с пассажиром, так что, возможно, это будет проще и стабильнее, я буду полагаться на других респондентов по этому вопросу, все, что я могу сказать, - это то, что нет никакой причины, по которой вы не можете построить надежную стек с nginx и дворнягой.

2 голосов
/ 16 ноября 2008

Мы перешли с NginX + Mongrel на Passenger.

Я полностью уверен, что Passenger станет новым стандартом для рельсов, несмотря на то, что кластеры NginX и Mongrel поддерживаются некоторыми очень умными людьми. Недавние достижения в Passenger действительно продвинули его вперед.

Наша текущая конфигурация выглядит примерно так:

Веб-серверы

  • Ubuntu 8.04 LTS
  • Phusion Passenger на Apache2
  • МРТ Руби 1.8.6 и друзья (форма кв)
  • Ruby Gems 1.3.0 (устанавливается из источника)

Серверы баз данных

  • Centos 5
  • MySQL Cluster (мы только что перешли на это, но это многообещающе)

Стандартизировав точный дистрибутив linux, мы смогли написать рецепты Capitrano, чтобы помочь развертыванию (небольшие изменения в конфигурации явились источником МНОГО перебоев в обслуживании) и упростить нашу жизнь.

1 голос
/ 16 марта 2009

Еще немного золота:

Джош Пик Slicehost gem полон рецептов Capistrano, которые намного проще и гораздо более организованы, чем Deprec. Там нет ничего особенно специфичного для Slicehost.

1 голос
/ 11 ноября 2008

Мы также переключились с Mongrel на mod_passenger и обнаружили, что стабильность значительно улучшилась благодаря усилиям, необходимым для настройки и обслуживания. Хороший выбор.

1 голос
/ 11 ноября 2008

Посмотрите на Litespeed . Вы можете получить бесплатную версию, которая работает на 1 процессор или заплатить, чтобы получить несколько процессоров. Это немного дорого, но надежно и блестяще обрабатывает рельсы (т. Е. Использует меньше памяти и требует меньше ресурсов для мониторинга и настройки). Я запускаю огромное количество приложений на нем, и он не пропускает ни секунды.

0 голосов
/ 12 ноября 2008

Capistrano + Deprec за фактическую настройку моего стека в Ubuntu и физическое управление развертыванием.

Nginx проксирует к Mongrel clusers для серверной архитектуры. Это не новейший, передовой метод, но он работает хорошо, он хорошо документирован и очень, очень высокопроизводителен даже при работе с небольшими VPS. Предполагая, что вы не загрузили приложение, вы можете использовать Slashdot на 128 МБ Slicehost VPS, и оно просто продолжает возвращаться, чтобы получить больше.

Сказав это: в первый раз было много готчей, пока я не выяснил, как на самом деле работает Nginx. После этого это удивительно - как маленький Апачелет с легким русским акцентом.

0 голосов
/ 11 ноября 2008

Я размещаю свои новые приложения с Apache2 и Passenger на Ubuntu Hardy. Похоже, самый простой и лучший вариант для большинства сценариев. Я только что присоединился к Slicehost.com для этой цели. Они, кажется, получают хорошие отзывы и имеют самые конкурентоспособные цены хозяев первого класса.

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

То, что вы не упоминаете, это то, насколько большим и популярным будет ваше приложение. Этот критерий может повлиять на процесс принятия решения.

...