Здравствуйте, хабралюди!

Хочу поделиться с вами способом разворачивания нескольких приложений Ruby on Rails на одном сервере.
Поможет нам в этом RVM, Unicorn и Nginx.

Недавно заказчик попросил поставить Redmine к ним на сервер, на котором уже крутился проект на Ruby on Rails и использующий версию руби 1.9.2. А redmine работает максимум с ruby-1.8.7. Так как других проектов на сервер размещать не предполагалось, то там изначально поставили Nginx + mod_passenger. Как известно, используя mod_passenger на одном сервере не запустишь два приложения с разными версиями руби.

Вы знаете, что когда требуется организовать many-to-many отношения между двумя моделями, прогрессивная часть человечества применяет join-таблицы и метод has_many с опцией :through => :join_model_name. Каждая связь между двумя ActiveRecord-объектами представляет собой ActiveRecord-объект.

И это чудесно, ибо в join-таблице можно насоздавать полезных (так называемых «extra») полей с дополнительной информацией о связях между объектами.

Вопрос в том, как красиво достучаться до этих extra атрибутов.

Все скринкасты и книжки, как назло, оперируют простыми примерами. Например, дружат между собой модели Article и Category. Само собой, для join-класса интуитивно напрашивается имя Categorization или ArticleCategorization.



Соответственно, если у нас есть два объекта — article и category, и мы хотим найти AR-объект (или объекты), олицетворяющий связь между ними, то авторы книжек с чистым сердцем предлагают делать так:

relations = article.article_categorizations.find_by_category_id(category)

В жизни все сложнее. Модели нередко имеют длинные составные имена, либо между моделями такая связь, что придумывание имени для каждой join-модели превращается в маленькую пытку. Представим, что у нас модели не Article и Category, а UserGroup и Community, или Preorder и CustomerNotification. Как должна называться связующая модель? Возможны варианты.

В данном посте я решил поделиться опытом разворачивания rails сервера на Amazon. Все предыдущие rails проекты я выкладывал на готовые сервера. Это были частные сервера, или широко известный сервис heroku. И единственные команды, которые я посылал серверу, были cap deploy и cap deploy:cold. Но в последнем проекте заказчик пожелал разместить сайт на своем амазоновском образе, поэтому пришлось погрузиться в тему более глубоко.

Думаю каждый кто работал с под-доменами в Rails 3 видел данный скринкаст.

Когда столкнулся с этим примером стояла задача сделать динамические поддомены + некоторые фиксированные. Динамические должны были соответствовать некоторому полю одной из моделей. Таким образом были выдвинуты условия для конечного решения:

• возможность указания фиксированного поддомена, либо группы поддоменов;
• возможность привязки к полю из модели ActiveRecord;
• удобный синтаксис для записи всего этого в routes.rb.

То, что контроллеры должны быть «худыми» знают все, но по мере наращивания функционала поддерживать чистоту контроллеров становится все сложнее и сложнее. Мы хотим предложить несколько рекомендаций как содержать свои контроллеры максимально чистыми без ущерба для качества кода.