Развертывание Rails, одна среда для каждого клиента - это правильно?

Question

Наше приложение - Saas для больницы, развернуто на одном производственном сервере (тот же код с linux + nginx + puma) для всех наших клиентов. По умолчанию их три: тестовая, разработка и продакшн. Но в нашем случае у нас есть 10 файлов конфигурации среды, указывающие на файл конфигурации 10 клиентов в папке config / environment /. И мы даем имя больницы файлу среды, например

config/environments/hospital1.rb
config/environments/hospital2.rb
config/environments/hospital3.rb
...

Есть несколько платных функций, разработанных с помощью engine.

А теперь представьте, что больница1 заплатила за функцию1. Как активировать функцию1 только для больницы1? В настоящее время я делаю это в Gemfile

group :hospital1 do
  gem 'feature1', path to ....
end

Вопрос: Это хороший способ заменить производственную среду на клиентскую среду c и иметь возможность включать / отключать драгоценный камень в GEMFILE?

Любые предложения приветствуются!

Answer 1

Звучит как плохая идея.

Вы здесь «смешиваете апельсины и диваны». Среды и клиенты имеют разную семантику.

То, что у вас есть, - это либо разные экземпляры одного и того же приложения, развернутые на разных серверах (а затем данные c, специфичные для клиента, должны поступать из переменных среды), либо если это однократное развертывание (похоже, это ваш случай), тогда в базе данных должна быть сохранена настройка c, определяемая клиентом.

Что касается ограничения доступа к платным функциям, вам следует изучить решение вроде pundit для этого. Gemfile определенно не подходящее место для вашей бизнес-логи c!

Answer 2

Это действительно плохой подход.

В основном вы пытаетесь реализовать мультитанантность, но очень странным и неконтролируемым образом.

Это архитектурное решение, и оно не может соответствовать ответу StackOverflow, и многие принимают целая книга, чтобы объяснить это.

Взгляните на https://rubygarage.org/blog/three-database-architectures-for-a-multi-tenant-rails-based-saas-app, чтобы получить некоторое представление.

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

Answer 3

Лично я предпочитаю думать о среде как о предмете технического уровня, а не о логике приложения c. Поэтому я бы постарался сохранить как можно меньше окружений. Если вы хотите иметь условные операторы в Gemfile, возможно, лучше использовать переменные среды? Что-то вроде

if ENV['FEATURE_1_ENABLED']
  gem 'feature1', path to ....
end

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

Answer 4

Подход с учетом среды на клиента плохо масштабируется. Gemfile определенно не место для хранения клиентских настроек. Также его сложнее проверить.

Если вам нужно сильное разделение (отдельные db, рабочие и т.д. c.) - я бы все равно go с одной production средой:

1. имеет файл конфигурации, в котором есть настройки для всех ваших клиентов (включенные функции и т.д. c.):

hospital1:
  name: Imaginary Medical Center
  address: Nowhere st. 0
  features:
    cool_notifications: true
    feature2: false
hospital2:
  name: ObfuscatedView Commutinu Hospital
  features:
    feature1: false

позже он может быть преобразован в административную базу данных

вместо среды передайте переменную ENV с идентификатором клиента (например, HOSPITAL_NAME=hospital1 rails server -e production) и создайте одноэлементный объект, который загружает эту конфигурацию при вызове все движки могут быть в gemfile, но с require: false и вы можете загружать их только в application.rb (сразу после Bundler.require), если соответствующая функция включена

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