Ana içeriğe geç

Tenancy: single vs multi

Deployment shape — single-tenancy vs multi-tenancy — env var tarafından değil, aktif lisans tarafından deklare edilir. Aynı codebase, iki yüz, tek doğruluk kaynağı.

TL;DR​

  • single tenancy — tek customer org. Sistem ilk lisans yüklemesinde varsayılan org'u + local cluster'ı o org'un edge'i olarak otomatik oluşturur. Admin/public sayfalar (Public Edges / Global Marketplace / Public Registries) gizlenir.
  • multi tenancy — operator UI üzerinden organizasyonlar oluşturur. Admin/public sayfalar ilgili MaxPublic* lisans cap'i pozitif olduğunda yüzeylenir.

Ayrım lisansın Binding.Tenancy field'ında yaşar — "single" veya "multi".

Neden iki shape​

DT Edge Platform iki ayrı customer tipine hizmet eder:

  • Bir ops console'una ihtiyacı olan tek customer. Ekipleri kendi sahip oldukları tek (ya da küçük sayıda) cluster'lara uygulama kurar. Org gerekmez. Marketplace yayınlamaz. Sadece helm + observability + alarms etrafında bir UI ister.
  • Birçok customer org için DT Edge Platform çalıştıran SaaS operator. Her biri kendi edge'leri + registry'leri + marketplace + member'larıyla izole birden çok tenant. Sözleşmeye göre opsiyonel public/admin yüzeyler.

Aynı ürün, aynı code path, iki shape. Hangi lisansın hangisi için iyi olduğuna sales / contracts karar verir.

İkisi arasında ne değişir​

Belirgin olmayan şey: ürünün çoğu aynıdır. Çekirdek akış (bir edge'e uygulama kur, release yönet, alarmla izle) tenancy'yi umursamaz. Farklılaşan admin yüzey alanıdır.

YüzeySingleMulti
Sidebar → Organizationsgizli (sadece bir tane var)görünür
Sidebar → Public Edges (admin)gizliMaxPublicEdges > 0 ise görünür
Sidebar → Global RegistriesgizliMaxPublicRegistries > 0 ise görünür
Sidebar → Global MarketplacegizliMaxPublicMarketplacePackages > 0 ise görünür
First-run experiencelocal edge hazır dashboard"create your first org" walkthrough
Org-scoped feature'lar (helm, alarms, audit log, …)aynıaynı

Neden license-driven, env-driven değil​

Eskiden aynı işi yapan bir MODE=single|platform env var'ı vardı. Onu çıkardık. Sebepler:

  1. İki doğruluk kaynağı. Operator'lar bazen tenancy field'ı multi olan bir lisans için MODE=single set ediyordu, ya da tersi. Çalışan sistemden bu uyumsuzluğu tespit etmenin yolu yoktu; UI bir shape gösterirdi, sözleşme başkasını söylerdi.
  2. Sözleşme shape'i sürmeli. Bir customer "single-tenant up to 25 nodes" için ödedi. Lisans bunu zaten encode ediyor. Deployment'ın ayrıca bir env var'a ihtiyaç duyması gereksiz ve hata-eğilimliydi.
  3. Tenancy swap bir sözleşme event'i olmalı. Customer single'dan multi'ye yükselttiğinde bu yeni cap'lerle re-issued bir lisanstır. Helm upgrade da gerektirmemelidir.

Yani bugün: bir artifact (lisans), bir doğruluk kaynağı, yanlış yapılandırılacak env var yok.

Trade-off: pre-license boot'un artık net semantiği var — UI "License Required" landing page gösterir, API mutasyonları reddeder. "Single mode'dayız ama lisans yüklü değil" muğlaklığı yok.

Single tenancy'de "the local cluster" ne demek​

Single-tenancy lisans yüklendiğinde DT Edge Platform bootstrap.EnsureSingleTenancy çağırır:

  1. Lisansın customer adını taşıyan varsayılan org oluşturur
  2. DT Edge Platform'un çalıştığı cluster'ı o org'un edge instance'ı olarak ekler — kubeconfig herhangi bir k8s pod'u içinde çalışan rest.InClusterConfig()'den gelir
  3. Super-admin'e varsayılan org üzerinde org:admin grant'i verir

Idempotent — lisans yenileme bootstrap için no-op'tur (org + edge zaten orada).

Local cluster diğer her edge gibidir. Onun yanında başka edge'ler kaydedebilir (aynı org), her ikisine de uygulama kurabilir, DT Edge Platform'u bir gün başka yere migrate ederseniz local'i kaldırabilirsiniz.

Tenancy'yi değiştirme​

Lisansı farklı Binding.Tenancy değeriyle yeniden mint edip yükleyin. Etkiler:

  • single → multi — admin/public sayfalar yeni lisansın MaxPublic* cap'lerine göre yüzeylenmeye başlar. Mevcut varsayılan org + local edge yerinde kalır; tutabilir veya değiştirebilirsiniz.
  • multi → single — admin/public sayfalar gizlenir. Mevcut org'lar veritabanında kalır; bootstrap idempotent ve hiçbir şeyi silmez. Genelde tek bir org'a konsolide ederken yaparsınız.

Nadirdir; genelde sözleşme değişimini yansıtır.

Single tenancy'de multi-tenant kalan ne​

Codebase temelden multi-tenant'tır. Single tenancy multi tenancy'nin özel halidir, N=1.

Yani:

  • Her satır hâlâ org_id taşır. Varsayılan org (potansiyel) birçoğundan biridir.
  • Casbin hâlâ çalışır. Varsayılan org'un kendi rolleri, üyeleri, izinleri var.
  • Admin / super-admin ayrımı hâlâ var. Super-admin varsayılan org'un otomatik üyesi değildir — bootstrap sırasında açık bir org:admin grant alır.

Bir single-tenancy kurulumun multi-tenancy'ye "büyümesi" gerekirse (örn: küçük bir ekip SaaS oluyor) bu lisans re-issue

  • yeni JWT yükleme. Veri migration'ı yok.

Ayrıca bakın​