Pull to refresh
29
0
Андрей Воронков @Antiarchitect

User

Send message
Здесь не как у Эдиссона — может быть и несколько правильных способов :)

Основная идея — прийти к разделению fronend/backend части при эксплуатации приложения.

А показал я на одном из многочисленных примеров — просто я использовал набор именно этих инструментов и мне они удобны. Более того, я уверен, что их набор должен меняться в соответствии с конкретной задачей.
Да, может. Причем при подходе, описанном в статье, получается, что каждое приложение имеет собственный конфигурационный файл для unicorn и собственный бинарник unicorn (благодаря bundle exec). Пачек «один мастер — n воркеров» тоже будет несколько — одна на приложение. Сокеты юникорнов будут расположены в разных местах и для запуска нового приложения на сервере вам будет необходимо создать еще одну upstream секцию (лучше делать в отдельном файле в conf/vhosts) в nginx. Рестартуем nginx один раз — и больше этого не требуется при деплоях.

Rvm для легкой смены версий руби, если одному приложению требуется 1.8.7 или ree, а другому 1.9.2 — задавать их через rvm очень удобно.

Ответ на второй вопрос здесь: habrahabr.ru/blogs/ror/120368/#comment_3947007

Мое мнение, что passenger — это модуль для nginx/apache и он как бы «впаян» во frontend сервер и без него никуда. Используя Unicorn мы получаем четкое разделение на frontend/backend сервера — с точки зрения построения продакшн инфраструктуры такой подход, на мой взгляд, надежнее.

Пассажир подкупает простотой своей настройки, при этом не являясь чем-то плохим, и вполне имеет право на жизнь.
По моим наблюдениям passenger на продакшн серверах начинает уходить, сменяясь на Unicorn.
Да — на гитхабе все «немножко» посложнее. Теперь хоть прочту, что значит вот эта строка:
GC.copy_on_write_friendly = true if GC.respond_to?(:copy_on_write_friendly=)
— там пояснение есть.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Works in
Date of birth
Registered
Activity