Skip to main content

በርካታ- किरायेदार መለያየት (Multi-Tenancy Isolation)

Ultimate Multisite: Multi-Tenancy 1.2.0 ለሉዓላዊ ተከታዮች (sovereign tenants) በየ-subsite የውሂብ ጎታ እና የፋይል ሲስተም መለያየትን ይደግፋል። ይህ የደንበኛውን መረጃ በተናጠል እንዲቆይ በማድረግ፣ በኔትወርክ ደረጃ የሚደረጉ አሰጣጥ (provisioning)፣ ክፍያ (billing) እና አስተዳደር ሂደቶችን ይጠብቃል።

የመለያየት ስልት (Isolation strategy)​

ለጠንካራ የውሂብ መለያየት፣ ለተመደበ የፋይል ማከማቻ ወይም ለተለየ የ호ስት ድንበር የሚያስፈልጋቸው ደንበኞችን ጠንካራ መለያየት (sovereign isolation) ይጠቀሙ።

እያንዳንዱ ሉዓላዊ ተከታይ የሚከተሉትን ሊኖረው ይገባል፦

  • ለ호ስቱ (host) የተፈቀደ የተለየ የደንበኛ የውሂብ ጎታ ወይም የውሂብ ጎታ ቅድመ-አ缀ር (database prefix strategy)።
  • የተለየ የደንበኛ የፋይል ሥር (dedicated tenant filesystem root)።
  • ጣቢያውን ወደ መረጃው፣ ዋና መንገድ (root path)፣ የ호ስት ስም (hostname) እና የመለያየት ሞዴል የሚያገናኝ የደንበኛ መዝገብ (tenant registry entry)።
  • ተከታዩ ከመጀመሩ በፊት የማሻሻያ ማረጋገጫ ውጤት (migration verification result)።

የውሂብ ጎታ 호ስት ማያያዝ (Database host binding)​

버전 1.2.0 ለሉዓላዊ መጫኖች (sovereign installs) በ ডিফল্ট ተመሳሳይ ማሽን ላይ የሚደረግ የ호ስት ማያያዝ ባህሪን ይለውጣል። እንደ localhost ያሉ ተመሳሳይ የማሽን እሴቶች Bedrock፣ FrankenPHP እና ወደ 컨ቴይነር የተጫኑ WordPress መጫኖች የMySQL የሚያዩትን 호ስት ስም በትክክል እንዲፈቅዱና ፈቃዶችን እንዲያረጋግጡ ያደርጋሉ።

ሉዓላዊ ተከታዩን ሲያዘጋጁ፦

  1. የውሂብ ጎታውን (database host) በተከታዩ ራይትማይን (runtime) የሚያስፈልገውን እሴት ይስጡ።
  2. 호ስት የአካባቢ ግንኙነቶችን በሚጠብቅበት ጊዜ ለባለቤትነት (local socket installs) localhostን ይጠቀሙ።
  3. የውሂብ ጎታው ለዚያ 호ስት መብቶችን ከሰጠው በስተቀር 127.0.0.1 ወይም የአገልግሎት ስም (service hostname) ብቻ ይጠቀሙ።
  4. የ호ስት ማያያዙን ከቀይረ በኋላ የማሻሻያ ማረጋገጫ (migration verification) ያድርጉ።

ማረጋገጫዎች ውድቀት (grant failures) ካሳዩ፣ የደንበኛውን DB ተጠቃሚ መብቶች (user grants) ከየተቀመጠው 호ስት ማያያዝ ጋር ያነፃፅሩ። ለuser@localhost የተሰጠው ተጠቃሚ ከ[email protected] ወይም user@% የተለየ ነው።

የፋይል ሥር (Filesystem root)​

የተከራዩ ሩት (tenant root) በሪስታርት እና በዲፕሎይመንት ላይ የተረጋጋ መሆን አለበት። ጊዜያዊ ማውጫ መንገዶችን ያስወግዱ። ለBedrock-ዘይቤ ጭነቶች፣ የሩቱ根 (root) ወደ ተከራዩ ቡትስት የሚጠብቀውን WordPress የድር ሥር እንጂ ፕሮጀክት ሩቱን ብቻ እንዳይመጥን ያረጋግጡ።

የማዘጋጃ ቅደም ተከተል (Provisioning order)​

ለአዳዲስ ሉዓላዊ ተከራዮች፣ ይህንን ቅደም ተከተል ይጠቀሙ፦

  1. የተከራዩ መዝገብ (tenant registry entry) ይፍጠሩ።
  2. የተከራዩን ዳታቤዝ እና የዳታቤዝ ተጠቃሚ ይፍጠሩ።
  3. የተከራዩን ስኪማ (schema) ያዘጋጁ (Bootstrap)።
  4. የተከራዩን ተጠቃሚዎች ያዘጋጁ።
  5. የድር ስርዓት መረጃ (filesystem) መንገዶችን ያዘጋጁ።
  6. የማሻሻያ ማረጋገጫውን (migration verification) ይስሩ።
  7. ማረጋገጫው ከወጣ በኋላ ሮቲንግን (routing) ወይም DNS-ን ይቀይሩ።

ይህ ቅደም ተከተል የዳታቤዝ ጸሐፊዎች፣ ተጠቃሚዎች እና የድር ስርዓት መረጃ ከመዘጋጋቸው በፊት የተከራዩ ተከፋፍሎ የሚመጡ ትራፊኮችን እንዳያገኙ ይከላከላል።

የሉዓላዊ ደንበኛ አስተዳደር ፍሰቶች (Sovereign customer management flows)​

Ultimate Multisite v2.13.0 በሉዓላዊ ሁነታው (sovereign mode) ሲበራ፣ የደንበኛ አስተዳደር እርምጃዎችን በዋናው ጣቢያ ላይ ይይዛል። ተከራዩ እንደ የተገለለ WordPress ጭነት ሊሰራ ቢችልም፣ በኔትወርክ ክፍያ፣ አባልነት ወይም የጋራ መለያ መረጃ ላይ የሚመሰረቱ የደንበኛ ግንኙነት እርምጃዎች በተከራዩ ራንታይም ውስጥ ለማጠናቀቅ ከመሞከር ይልቅ ደንበኛውን ወደ ዋናው ጣቢያ እንዲመለሱ ማድረግ አለባቸው።

ዋናው ጣቢያ ፍሰት የሚከተሉትን ያካትታል፦

  • የክፍያ ሂደት (Checkout) እና የዕቅድ ለውጦች።
  • የሂሳብ አጠቃላይ እይታ እና የደንበኛ መገለጫ እርምጃዎች።
  • የክፍያ አድራሻ ማሻሻያዎች እና የክፍያ አስተዳደር ገጾች።
  • የሂሳብ ደረሰኝ (Invoice) እና የክፍያ ታሪክ እይታዎች።
  • ጣቢያዎችን መጨመር ወይም መሰረዝ የመሳሰሉ የጣቢያ አስተዳደር እርምጃዎች።
  • ቴምፕሌት መቀየር።
  • የዶሜን ካርታ እና ዋና ዶሜን ለውጦች።

ደንበኛ አንድን ከእነዚህ እርምጃዎች አንዱን ከሉዓላዊ ተከራይ (sovereign tenant) ሲጀምር፣ Ultimate Multisite የሚዛመደውን ዋና ጣቢያ URL ይገነባል እና በደህንነት እስከተፈቀደ ድረስ የምንጩን ተከራይ እንደ መመለሻ መድረሻ ይጠብቃል። ይህ ደንበኞች የተያዙትን እርምጃዎች በኔትወርክ መዝገቦች ላይ እንዲያጠናቅቁ ያስችላል፣ ከዚያም በሉዓላዊው ዳታቤዝ ውስጥ ክፍያ ወይም የደንበኝነት ምደባ ሁኔታ እንዳይደገም ተከራይ አውድ ወደ መመለሻ ቦታ እንዲመለሱ ያደርጋል።

ለኦፕሬተሮች ተግባራዊ ህግ የሚከተለው ነው፡ ለሉዓላዊ መረቦች ዋና ጣቢያ ላይ የክፍያ፣ የሂሳብ መረጃ፣ የቼክአውት (checkout)፣ የኢንቮይስ (invoice)፣ የቴምፕሌት እና የዶሜን አስተዳደር ገጾች እንዲኖሩ ማድረግ። የተከራዩ ዳሽቦርዶች ወደ እነዚያ ገጾች ሊያገናኙ ይችላሉ፣ ነገር ግን ዋናው ጣቢያ ለድርጊቱ መረጃ ምንጭ ሆኖ ይቀጥላል።