アパートメントジェムを使用したマルチテナンシー

まずシングルテナントとマルチテナントの違いを理解しましょう

シングルテナンシー:

すべての顧客は独自のソフトウェア インスタンス、独自の DB を持ち、それは 1 人の顧客にのみサービスを提供します。ここで、ソフトウェアは独立しているため、特定の顧客要件を満たすようにカスタマイズできます。

マルチテナント:

この場合、ソフトウェア アプリケーションの単一インスタンスが複数の顧客にサービスを提供します。ここでは、各顧客をテナントと呼びます。ここでは、UI ルールとビジネス ルールを変更できますが、同じアーキテクチャが複数の顧客によって共有されているため、アプリケーション コードを変更することはできません。ソフトウェアの開発費や保守費をお客様で分担するため経済的です。ただし、更新はプロバイダーのみが行うことができます。

利点:
1. Single hardware that manages multiple customers.
2. Cost savings. Cost can be shared between all the customers.
3. Easy maintenance
4. Configuration can be changed without touching codebase.
5. New tenants can be added easily since it is a shared architecture.

短所:
DB customization will be difficult to handle since it is a single DB shared between multiple customers with different tenants.

There are milia, acts_as_tenant and apartment gem to handle multi-tenancy in the Rails application.

アパートメントジェム:

この gem は、マルチテナンシーに対処するために別の方法を採用しています。テナントごとに別のDBを作成することで機能します。 PostgreSql の場合、テナントごとに別のスキーマが作成されます。この状況では情報が実際に遮断されているという事実を考慮すると、私はこのアプローチが気に入っています。データベースは共有されないため、クライアントの情報を消去する必要がある場合は、データベース (またはパターン) を削除するだけで済みます。また、エレベーターもサポートしており、顧客のテナント間の自動切り替えが可能になり、それによって切り替えロジックが自動化されます。

This gem helps us to deal with multi tenancy in Rails application.

Add the line below, to your Gemfile and perform bundle install.

宝石の「アパートメント」

アパートメント初期化ファイルを生成するには、以下のコマンドを実行します。

Bundle exec Rails アパートメントの生成:インストール

config.excluded_models = %w{ テナント } 

Here, we can specify the tenants which are of global scope, such as the Authentication model which is a common one for all the tenants.

Here, I will be creating a Customer with subdomains, so, whenever customer logs in to the application, apartment fetches the subdomains and will query the database, based on tenant subdomain.

Rails g scaffold 顧客名:string tenant_domain:string

する

Rails データベース:移行

顧客を作成したら、アパートのテナントを作成する必要があります。

Apartment::Tenant.create('tenant_name') - テナントを作成するには

モデルで after_create コールバックを使用してテナントを作成します。

def create_tenant Apartment::Tenant.create(tenant_domain) end

Once the above callback gets executed, all the migrations will run under that respective tenant.

Switching of subdomains will be handled automatically when we request the application with subdomains. Below is the configuration line to switch the tenants based on subdomain.

Rails.application.config.middleware.use 'Apartment::Elevators::Subdomain'

テナントを切り替えるには

アパートメント::テナント.スイッチ!('テナント名')

All your ActiveRecord queries will be routed to the specific tenant when switch is called for.
Switch will be in the root scope when you call with no arguments.

Even tenant switch can be done based on the first subdomain but we need to set config in the initializer file. We can even exclude some subdomains here, such as the normal subdomain.

config.middleware.use 'Apartment::Elevators::FirstSubdomain'

Apartment::Elevators::FirstSubdomain.excluded_subdomains = ['www']

We can also restrict the users not to create some domains such as www, admin. These domains will not be available for the users while they were being registered.

Need to uncomment below config line in the apartment initializer file.

Apartment::Elevators::Subdomain.excluded_subdomains = ["public"、"www"、および "admin" ]

完全なホストに基づいて切り替えることもできます。ここでは、次の構成行を使用して、ハッシュ内の対応するテナント名を見つける必要があります。以下の行を application.rb に追加する必要があります。

config.middleware.use 'Apartment::Elevators::HostHash', {'example.com' => 'example_tenant'}

テナントを削除します。

以下のコマンドを使用してテナントを削除できます。

アパートメント::テナント.drop('テナント名')

さらに多くのドキュメントを見つけるには、gem 公式リソースを確認してください。