Объединение 2 приложений rails в единую кодовую базу

Наша компания начала с одного продукта, приложения rails, поддерживаемого некоторыми java-сервисами, затем решила, что им нужен другой продукт, который изначально значительно отличался от первого, но со временем мы поняли, что они начинают сходиться, и изменение кода в одном требует аналогичного изменения кода в другом для исправления новой функции/ошибки. Это явно становится болью.

В некоторых случаях у нас есть драгоценные камни, которые разделяют некоторые из этих функций, но они выходят за рамки ruby ​​​​в javascript, css и т. д.

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

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

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

Или, если у кого-то есть другие предложения о том, как объединить эти приложения, я внимательно слушаю.

Это оба приложения Rails 2.3.10, работающие под управлением JRUBY 1.5.3, но мы открыты для возможного обновления до Rails3, если это значительно упростит или упростит работу (например, с лучшей интеграцией Rack).

Я никогда не занимался программированием Rack, но никогда не помешает научиться, облегчит ли это нашу жизнь.


ruby-on-rails migration rack jruby
person brad    schedule 18.11.2010    source источник
comment
Стойка была бы решением для развертывания и, вероятно, не является решением здесь.   -  person Chirantan    schedule 19.11.2010
comment
стойку является промежуточным программным обеспечением правильно? Я думал, что он может перехватить запрос и правильно направить его? но опять же я мало что знаю об этом   -  person brad    schedule 19.11.2010

Ответы (2)


arrow_upward
1
arrow_downward

Я бы предложил вашу идею использования двигателей.

Для маршрутизации я бы обработал это вне Rails.

Например, вы должны сделать следующее в nginx:

server {
    # Match only one host.                                                      
    listen 80 default;
    server_name YOUR_SINGLE_APP_DOMAIN;

    location / {
        upstream YOUR_SINGLE_APP_RAILS;
    }
}


server {
    # Fall thru and match any other host.                                                      
    listen 80 default;
    server_name ~^.*$;

    location / {
        upstream YOUR_MULTI_DOMAIN_APP_RAILS;
    }
}
person Rafi Jacoby    schedule 24.11.2010
comment
Можете ли вы объяснить восходящую часть? Я никогда не использовал это с nginx. Кроме того, я понимаю соответствие домена и проксирования соответствующим образом, но я хочу, чтобы мои два приложения содержались в одном приложении rails, поэтому в соответствии с этим я полагаю, что мои маршруты между двумя движками rails должны быть уникальными? Я надеялся, что они могут использовать определенные маршруты, но будут перенаправлены на правильное действие в зависимости от домена. - person brad; 24.11.2010
comment
Я думаю, что я пошел по пути nginx, потому что вы говорили о доменах, и это то, что я обычно обрабатывал вне Rails. Что касается восходящего потока, вы просто определяете конечную точку (или более одной), которая обрабатывает запросы. В nginx+passenger: upstream my_rails_app { server 10.1.2.3:8000; } сервер { слушать 10.1.2.3:8000 и т.д. и т.п. - person Rafi Jacoby; 09.12.2010
comment
это по сути то, что мы в итоге сделали - person brad; 29.04.2011

arrow_upward
2
arrow_downward

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

Что касается переписывания функционала в одно приложение, выбирайте за основу то, в котором больше готового кода. Должна быть возможность переноса кода для каждого метода с использованием веб-сервера, поддерживающего перезапись URL-адресов. Я думал об использовании apache с mod_rewrite. Итак, план будет таким:

  1. Настройте оба приложения так, чтобы они были доступны через один apache.
  2. Выберите один метод, похожий в обоих случаях, и перепишите его в одном приложении, чтобы он поддерживал требования обоих приложений.
  3. В apache добавьте правило mod_rewrite для перенаправления трафика в одно приложение только на это действие.
  4. Перейти к пункту два, пока все не будет переписано.
  5. Удалите старое приложение и настройте маршрутизацию/mod_rewrite для использования одного приложения.

Вам не обязательно использовать apache, должны быть другие веб-серверы, поддерживающие перезапись URL.

Я думал использовать этот алгоритм, чтобы переписать наше приложение на рельсы 3.0.

person mpapis    schedule 19.11.2010