בידוד רב-שכירות (Multi-Tenancy Isolation)

Ultimate Multisite: Multi-Tenancy 1.2.0 תומך בבידוד של מסד נתונים ומערכת קבצים לכל סאב-אתר עבור שוכרים בעלי ריבונות (sovereign tenants). זה שומר על נתוני השוכרים מופרדים תוך שמירה על אספקת רשת, חיוב וניהול ברמת הרשת.

אסטרטגיית בידוד

השתמש בבידוד ריבוני עבור לקוחות הדורשים הפרדה חזקה יותר של נתונים, אחסון מערכת קבצים ייעודי או גבול מארח נפרד.

לכל שוכר ריבוני צריך להיות:

• מסד נתונים ייעודי לשוכר או אסטרטגיית קידומת (prefix) למסד הנתונים שאושרה עבור המארח.
• שורש מערכת קבצים ייעודי לשוכר.
• רשומת רישום שוכר שממפה את האתר למסד הנתונים שלו, נתיב השורש (root path), שם המארח (hostname) ומודל הבידוד.
• תוצאת אימות מיגרציה לפני שהשוכר נחשב פעיל.

קישור מארח מסד נתונים (Database host binding)

גרסה 1.2.0 משנה את ההתנהגות המוגדרת כברירת מחדל של קישור מארח באותה מכונה עבור התקנות ריבוניות. ערכים כמו localhost שמוגדרים באותה מכונה מותאמים כך ש-Bedrock, FrankenPHP והתקנות WordPress מותקנות בתוך קונטיינרים יוכלו להעניק ולאמת הרשאות נגד מחרוזת המארח (host string) שהמסד הנתונים באמת רואה.

כאשר אתה מגדיר שוכר ריבוני:

1. הגדר את מארח מסד הנתונים לערך הנדרש בזמן ריצה של השוכר.
2. השתמש ב-localhost להתקנות סוקט מקומי כאשר המארח מצפה לחיבורים מקומיים.
3. השתמש ב-127.0.0.1 או בשם מארח שירות (service hostname) רק כאשר שרת מסד הנתונים מעניק הרשאות למארח זה.
4. הרץ אימות מיגרציה לאחר שינוי קישור המארח.

אם דוחות האימות מדווחים על כשלים בהענקת הרשאות, השווה את ההרשאות של משתמש מסד הנתונים לשוכר לקישור המארח שהוגדר. משתמש שניתן לו עבור user@localhost שונה מ-[email protected] או user@%.

שורש מערכת קבצים (Filesystem root)

שורש הושכר צריך להיות יציב לאחר הפעלה מחדש והפצה. הימנעו מנתיבי הרכבה זמניים. עבור התקנות בסגנון Bedrock, ודאו ששורש ההושכר מצביע על שורש האינטרנט של WordPress הצפוי על ידי ה-bootstrap של ההושכר, ולא רק על שורש הפרויקט.

סדר ייצור (Provisioning order)

עבור משכירים חדשים בעלי ריבונות, השתמשו בסדר הבא:

1. יצירת רשומת הרשמה להושכר (tenant registry entry).
2. יצירת מסד הנתונים של ההושכר ומשתמש ב-database user.
3. Bootstrap של סכמת ההושכר (tenant schema).
4. אספקת משתמשי ההושכר (tenant users).
5. הגדרת נתיבי מערכת הקבצים של ההושכר (tenant filesystem paths).
6. הרצת אימות המעבר (migration verification).
7. מעבר ניתוב או DNS לאחר שהאימות עובר בהצלחה.

סדר זה מונע מההושכרים המבודדים חלקית לקבל תנועה לפני שכותב מסד הנתונים, המשתמשים ומערכת הקבצים מוכנים.

זרימות ניהול לקוחות ריבוניים (Sovereign customer management flows)

Ultimate Multisite v2.13.0 שומרת פעולות ניהול לקוחות באתר הראשי כאשר מצב הריבונות מופעל. ניתן עדיין להריץ את ההושכר כהתקנת WordPress מבודדת, אך פעולות המכוונות ללקוח התלויות בחיוב רשת, חברות או נתוני חשבון משותף צריכות לשלוח את הלקוח בחזרה לאתר הראשי במקום לנסות להשלים את הפעולה בתוך זמן ריצת ההושכר.

זרימת האתר הראשי חלה על:

• שינויי Checkout ותוכניות.
• סקירת חשבון ופעולות פרופיל לקוח.
• עדכוני כתובת חיוב ומסכי ניהול תשלומים.
• תצוגות של חשבונית והיסטוריית תשלומים.
• פעולות ניהול אתר כמו הוספת אתרים או מחיקת אתר.
• החלפת תבניות (Template switching).
• מיפוי דומיין ושינויי דומיין ראשי.

כאשר לקוח מתחיל אחת מהפעולות הללו משכירות ריבונית (sovereign tenant), Ultimate Multisite בונה את כתובת ה-URL של האתר הראשי המתאימה ושומר על השכירות המקורית כיעד חזרה, כאשר זה בטוח לעשות זאת. כך לקוחות יכולים להשלים את הפעולה המנוהלת מול רשומות הרשת, ואז לחזור להקשר של השכירות מבלי לשכפל את מצב החיוב או החברות במסד הנתונים של השכירות הריבונית.

עבור מפעילים, הכלל המעשי הוא: שמרו על דפי החיוב, החשבון, הקופה (checkout), החשבונית, התבנית (template) וניהול הדומיין זמינים באתר הראשי עבור רשתות ריבוניות. ללוחות הבקרה של השכירות ניתן לקשר לדפים אלו, אבל האתר הראשי נותר מקור האמת לפעולה.