ריבוי אתרים ב-1C-Bitrix: היכן נשברת הרישיון האחיד
ריבוי אתרים ב-1C-Bitrix מתוכנן כמצב תקני: רישיון אחד משרת כמה דומיינים, לכל אחד תיקייה משלו, תבנית משלו ועץ מדורים משלו. בפועל הכול נשבר לא בשלב ההפעלה, אלא באתר השלישי או הרביעי, כשההגדרות המשותפות מתחילות להתנגש עם הפרטיות. מפרקים היכן בדיוק.
הכשל הטיפוסי הראשון — התנגשות תבניות. האתרים חולקים מערכת אחת של קומפוננטות, ותיקון תבנית עבור דומיין אחד משנה בשקט את התצוגה באחרים: המפתח מתקן בלוק באתר א', ובאתר ב' הפריסה מתפרקת. השני — כפילות כללים.
מטפלי אירועים, כללי ניתוב, הגדרות הרשאות נרשמים מחדש עבור כל אתר, ובמקום הפעלה אחת מתקבלות שתיים-שלוש, וסדר ההפעלה שלהם תלוי באיזה אתר נפתח ראשון.
השלישי והיקר ביותר — אובדן השליטה. לוח הניהול האחיד מפסיק להיות אחיד: חלק מההגדרות חיות ברמת האתר, חלק ברמת המודול, וחלק מוטבע בקוד התבנית. להבין מה משתנה והיכן אפשר רק על ידי מעבר בכוח, וביטול תיקון אחד גורר אחריו אתרים אחרים. בדיוק כאן ריבוי אתרים ב-1C-Bitrix הופך מחיסכון ברישיון למקור מתמיד של תקלות.
אנחנו מתחילים באודיט: מפרקים את ההגדרות לפי רמות, מתעדים מה באמת משותף ומה חייב להיות מבודד, ומפרידים את התבניות כך שתיקון של אתר אחד לא יוכל פיזית לפגוע בשכן. בהמשך — כללים אחידים במקום כפילויות ומבנה שקוף שבו רואים איזה דומיין נשלט על ידי מה. כך כמה אתרים על רישיון אחד נשארים צפויים, ולא הופכים להגרלה בכל עדכון.
מה נותנת רב-אתריות נכונה על רישיון אחד
רב-אתריות ב-1C-Bitrix נבנית על הפרדת תוכן לפי אתרים בתוך ליבה אחת: מודולים משותפים, תבניות ומטפלים קיימים בעותק יחיד, והצמדת התוכן מתבצעת באמצעות הצמדה לאתר.
בפועל משמעות הדבר היא שפלטפורמה חדשה מוקמת לא על ידי העתקת בסיס הקוד, אלא על ידי הוספת אתר למבנה הקיים — עם דומיין משלו, תבנית משלו והרשאות גישה משלו, אך ללא ליבה שנייה וללא רישיון שני.
נקודת ניהול אחודה מניבה אפקט מדיד ישיר: עדכון הליבה, המודולים וכללי האבטחה מבוצע פעם אחת ומוחל על כל הפלטפורמות בבת אחת. בעבר, עם שלוש התקנות נפרדות, היה צורך להחיל טלאי אבטחה שלוש פעמים, וכל עותק שנשכח נותר פגיע. כעת אי-התאמת גרסאות בין האתרים נמנעת מבחינה טכנית, ולא מכוח נהלים.
דומיינים עצמאיים שומרים על אוטונומיה: לכל אתר יש מבנה מדורים משלו, תבנית משלו, הגדרות SEO משלו וסטטיסטיקה נפרדת. משתמש של דומיין אחד אינו רואה את התוכן של האחר, וההרשאות מופרדות ברמת האתר. הדבר מסיר את החשש המרכזי של הלקוח — שהפלטפורמות "יידבקו" לאחת ויאבדו את הייחודיות שלהן.
מהירות ההקמה של מדורים ואתרים חדשים עולה בזכות שימוש חוזר: תבנית טיפוסית, רכיבים משותפים ואינפובלוקים מוגדרים כבר מוכנים, ונותר רק להצמיד אותם לדומיין החדש.
זמן ההשקה של פלטפורמה מתקצר משבועות לימים, והפחתת הכפילויות — בקוד, בתבניות ובהגדרות — מסירה מחלקה שלמה של שגיאות, שבהן תיקון במקום אחד אינו מגיע לשאר העותקים.
דרכי ארגון: השוואת גישות
ריבוי אתרים ב-1C-Bitrix מיושם בשלוש דרכים, והבחירה ביניהן קובעת לא רק את עלות הרישיון, אלא גם כיצד תעדכנו, תפרסו ותגדירו הרשאות גישה. ההבדל מתגלה לא בהתחלה, אלא בשנה השנייה-שלישית, כאשר מספר האתרים גדל, והצוות — יותר מאדם אחד.
| אפשרות | מתי מתאימה | מגבלות הגישה |
|---|---|---|
| ליבה משותפת ותבניות משותפות | אתרים של אותה קבוצה: פלטפורמה ראשית, דפי נחיתה, מראות אזוריות. העיצוב והמבנה זהים, ההבדלים — בתוכן ובתחום | עריכת תבנית משפיעה על כל האתרים בבת אחת. קשה להפריד הרשאות לפי אתרים, עדכון הליבה — חלון משותף לכולם |
| ליבה משותפת, תבניות נפרדות | מוצר אחד, קהלים או מותגים שונים. הלוגיקה והמודולים משותפים, הבנייה ומבנה הקטלוג — משלכם | הליבה והמודולים בכל זאת משותפים: קונפליקט בגרסת מודול מפיל את כל האתרים. יש לבדוק שינויים בכל הפלטפורמות |
| מופעים נפרדים | לקוחות שונים, צוותים שונים, דרישות מבודדות לאבטחה ולעומס | כל מופע — רישיון משלו, מסד נתונים משלו, עדכונים משלו. עלות התמיכה גדלה באופן ליניארי עם מספר האתרים |
האפשרות הראשונה מספקת חיסכון מקסימלי ברישיון ונקודת עדכון אחודה, אך כל שגיאה בקוד המשותף מתפשטת לכל הפלטפורמות. השנייה — פשרה: התוכן והבנייה מבודדים, התשתית משותפת. השלישית מסירה את התלות לחלוטין, אך מחזירה אתכם ל-N פרויקטים עצמאיים עם N סטים של גיבויים וניטור.
בפועל, לרוב בוחרים בהיבריד: ליבה משותפת לפלטפורמות קשורות ומופע נפרד לאותו אתר שאסור להחזיק לצד האחרים בשל דרישות אבטחה או עומס. נבחן כיצד לפרוס זאת על התשתית ולא לאבד את השליטה.
סדר היישום: מה�audit ועד למסירה
העבודה מתבצעת בשלבים, וכל שלב מסתיים בארטיפקט שניתן לבדוק: בלי זה ריבוי אתרים הופך לאוסף של עריכות ידניות שנשברות בעדכון הראשון. להלן הסדר שבו אנו מובילים את הפרויקט, מניתוח ראשוני ועד מסירה לצוות שלכם.
- Audit מבנה. אוספים מפה של האתרים, הדומיינים, המדורים והתבניות הקיימים: מה כבר פועל על ליבה אחת, היכן הגדרות משוכפלות, אילו רכיבים קשורים לאתר מסוים. בפלט — רשימת צווארי בקבוק ורשימה של מה שאין להעביר ללא עיבוד מחדש.
- תכנון הסכמה. קובעים כיצד מתחלקים האתרים בין הליבה והרישיון, היכן תבניות משותפות והיכן נפרדות, כיצד מופרדות ההרשאות והגרסאות הלשוניות. מקבעים את הסכמה על הנייר לפני תחילת ההגדרה — כך נקודות מחלוקת עולות בשלב התכנון ולא ביום ההשקה.
- הגדרת ריבוי אתרים. מקשרים דומיינים, מגדירים את שיוך האתרים למדורים ולinfoblocks, מעבירים תוכן ותבניות, מסדירים את כללי הניתוב וההפניות מחדש. כל שינוי — בקונפיגורציה, ולא "ידנית בניהול", כדי שהתוצאה תהיה ניתנת לשחזור.
- בדיקה. מריצים תרחישים לכל אתר: התחברות, הרשמה, הזמנות, טפסים, סנכרון עם 1С, הרשאות גישה, התנהגות בעת השבתת אחד האתרים. בנפרד בודקים שרכיבים משותפים אינם מושכים נתונים של אתר אחר.
- תיעוד. מתארים את הסכמה, השיוכים, נקודות ההרחבה וסדר הוספת אתר חדש. המסמך נשאר אצלכם — הוא נחוץ גם למפתחים שלכם וגם לנו בפנייה הבאה.
- מסירה. מראים לצוות כיצד לבצע עריכות ומה אסור לשנות ללא בנייה מחדש של הסכמה, מוסרים הרשאות גישה ומקבעים תקנון עדכונים.
סדר כזה מאפשר השקה צפויה: כל שלב נבדק בנפרד, ולא "הכול בבת אחת בפרודקשן". תארו את המשימה שלכם — נחזור עם הערכה ותוכנית לפי השלבים האלה.
מדיניות גישה, תבניות והרשאות בכל אתר
ריבוי אתרים ב-1C-Bitrix נבנה על בסיס קוד משותף: ליבה אחת, רישיון אחד, אך לכל אתר יש דומיין משלו, תבנית משלו וקבוצת משתמשים משלו. אם ההרשאות והניתוב אינם מופרדים, מנהל של אתר אחד רואה ועורך תוכן של אתר שכן, ועריכה של תבנית שוברת את הפריסה בכל הפרויקטים בבת אחת. להלן כיצד אנו סוגרים זאת ברמת ההגדרות.
הפרדת הרשאות מנהלים
ההרשאות ניתנות לא "לפורטל", אלא לאתר ספציפי: תפקיד המנהל נקשר לאתר דרך קבוצות משתמשים ורמות גישה למודולים. מנהל תוכן של פרויקט אחד אינו מקבל גישה לאינפובלוקים ולהגדרות של אחר — גם אם שניהם עובדים באותו פאנל ניהול.
בידוד תבניות וניתוב דומיינים
כל אתר מקבל תבנית משלו וספריית משאבים משלו, ורכיבים משותפים מועברים לשכבה נפרדת, כך שעריכה של אתר אחד אינה פוגעת בשאר. את הניתוב מגדירים לפי דומיין: הכללים קובעים איזה אתר מטפל בבקשה, לאן הולך הרידיירקט וכיצד מסודרות הגרסאות הלשוניות. כך שינוי מבנה של פרויקט אחד אינו משנה כתובות באתרים השכנים.
- קבוצות משתמשים נפרדות ורמות גישה למודולים עבור כל אתר
- קישור תפקידי מנהל לאתר ספציפי, ולא לכל ההתקנה
- תבנית משלו וספריית משאבים משלו לכל פרויקט
- רכיבים משותפים בשכבה נפרדת — עריכה אינה משפיעה על אתרים שכנים
- כללי ניתוב לפי דומיין: טיפול בבקשות, רידיירקטים, גרסאות לשוניות
- הגנה מפני השפעה הדדית: תקלה בפרויקט אחד אינה מפילה את האחרים
- הפרדת גישה לאינפובלוקים, להגדרות ולספריית המדיה
- תקנון מתן הרשאות: מי ומה יכול לשנות בכל אתר
בודקים את התוצאה בסביבת בדיקה: תחת חשבונות שונים מוודאים שהגישה מוגבלת ושהניתוב אינו מצטלב. סביבה כזו מסירה סוג שלם של תקלות, שבהן עריכה של אתר אחד מוציאה מכלל פעולה את האחרים.
מקרה בוחן: כיצד חברת אחזקות אחת איחדה חמישה אתרים ללא גידול ברישיונות
חברת אחזקות עם חמישה מותגים הגיעה עם כאב טיפוסי: כל אתר חי על מופע נפרד של 1C-Bitrix עם הרישיון שלו, הליבה שלו ומסד הנתונים שלו. עדכון האבטחה היה צריך להתבצע חמש פעמים, תבנית התוכן נערכה בחמישה ממשקי ניהול, והצגת מדור חדש בכותרת נמשכה ימים. בנוסף, חמישה סטים של מודולים — וכתוצאה מכך, חמש גרסאות שונות של אותו קוד בדיוק.
הכול הועבר לריבוי אתרים במסגרת רישיון אחד: ליבה אחת, מסד נתונים אחד, חמישה אתרים כישויות נפרדות עם הדומיינים, התבניות וההרשאות שלהם. מודולים והגדרות משותפים הועברו לרמת הפלטפורמה, וההבדלים בין המותגים — לתבניות ולשיוך התוכן. ההעברה בוצעה בשלבים, אתר אחר אתר, עם בדיקת הפניות ושמירה על האינדוקס.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| מופעים ורישיונות | 5 נפרדים | רישיון אחד, 5 אתרים |
| עדכון ליבה ומודולים | 5 הרצות ידניות | הרצה אחת לכל האתרים |
| עריכת תבנית משותפת | 5 ממשקי ניהול | נקודת שינוי אחת |
| הצגת מדור חדש | ימים | שעות |
| גיבויים | 5 סטים מפוזרים | מדיניות אחידה |
מה זה נתן בתפעול
הניהול עבר לפאנל אחד: הרשאות מחולקות לפי אתרים, עורכי תוכן רואים רק את המדורים שלהם, והפיתוח מנהל קוד משותף. הגיבוי והניטור מוגדרים על קו מתאר אחד במקום חמישה — השחזור לאחר תקלה נכנס לחלון צפוי מראש, ולא לניתוח סדרתי של כל מופע.
אפקט נפרד — צפיות מראש של מהדורות. בעבר חוסר הסנכרון בין הגרסאות באתרים יצר באגים שונים על אותו קוד בדיוק. כעת העדכון מתבצע פעם אחת ובאופן זהה לכל המותגים, ונסיגה אפשרית לחתך הקודם המשותף.
במה שונה ריבוי אתרים ממופעים נפרדים?
ריבוי אתרים ב-1C-Bitrix הוא מצב שבו מופע אחד של המוצר משרת כמה דומיינים עם רישיון משותף, ליבה משותפת וממשק ניהול אחיד. כל אתר מקבל הגדרות משלו: תבנית, מבנה מדורים, הרשאות של קבוצות משתמשים, שיוך למחסנים ולמטבעות בקטלוג המסחרי.
הליבה אחת — כלומר עדכונים, תיקוני אבטחה ותיקונים במודולים משותפים מיושמים פעם אחת ומיד על כל הפלטפורמות.
מופעים נפרדים הם התקנות בלתי תלויות: מסד נתונים משלו, קוד משלו, מחזור עדכונים משלו. תכנית כזו מוצדקת כאשר הפלטפורמות חייבות להיות מבודדות זו מזו: צוותי פיתוח שונים, מחזורי שחרור שונים, דרישות להחזיק נתונים על שרתים נפרדים או בתחומי שיפוט שונים.
הבידוד מעניק יציבות — קריסה או עדכון כושל של פלטפורמה אחת אינו פוגע באחרות, וניתן לפזר את העומס על שרתים שונים בלי צוואר בקבוק משותף.
קריטריון הבחירה המרכזי הוא עד כמה האתרים דומים בהיגיון ועד כמה יש להפריד ביניהם באופן נוקשה. אם מדובר בסניפים, נציגויות אזוריות, מותגים של אותה קבוצה עם קטלוג משותף ומשתמשים משותפים — ריבוי אתרים מבטל את הכפילות: קטלוג מוצרים אחד, מחירים אחדים, סל אחד, אימות אחיד בין הדומיינים.
תיקון במודול משותף אינו הופך למשימה של "להכניס את אותו הדבר בחמש התקנות ולא לשכוח אף אחת".
הצד השני של ריבוי אתרים הוא המשאב המשותף. שאילתה כבדה או שגיאה ברכיב מותאם אישית באתר אחד משפיעה על כולם, ועדכון הליבה נוגע בכל המעגל בבת אחת.
לכן לפני בחירת התכנית אנחנו בוחנים את פרופיל העומס של כל פלטפורמה, את תדירות השחרורים, את הדרישות לבידוד נתונים ואת מידת הנכונות של הצוותים לתאם לוח זמנים משותף לעדכונים. לפי נתוני פתיחה אלה נקבע היכן משתלם יותר מופע אחיד והיכן סביר יותר להפריד את האתרים להתקנות נפרדות.
מה הלקוח מקבל לידיו לאחר ההגדרה
הגדרת ריבוי אתרים על רישיון אחד אינה תיקון חד-פעמי של התצורה, אלא מארז של תוצרים שלפיהם ניתן להמשיך להפעיל את המערכת, להעביר אותה לצוות אחר ולשחזר אותה לאחר תקלה. להלן מה שנשאר ברשותכם בתום העבודה.
- תצורות הליבה והמודולים. ייצוא של תצורת העבודה עם הגדרות ריבוי האתרים: שיוך האתרים לרישיון, מודולים משותפים ונפרדים, הגדרות מטמון לכל אתר בנפרד. ניתן לפרוס את הקובץ על סביבת בדיקה ולהשוות את ההתנהגות מול סביבת העבודה.
- תרשימי ניתוב דומיינים. מפת התאמה «דומיין → אתר → תיקייה», כללי טיפול בכתובות והפניות, נקודות כניסה לכל אתר. בנפרד מתעדים כיצד הניתוב מתנהג בעת הוספת דומיין חדש.
- מדיניות גישה והפרדת הרשאות. מטריצת תפקידים לפי אתרים ומדורים בממשק הניהול: מי רואה תוכן של איזה אתר, מי מנהל משתמשים, מי имеет גישה להגדרות משותפות. הדבר מסיר את הסיכון שעורך של אתר אחד יערוך בטעות נתונים של אתר אחר.
- נהלי תחזוקה. סדר עדכון הליבה והמודולים כאשר מספר אתרים על רישיון אחד, כללי גיבוי לכל אתר בנפרד, רצף הפעולות בעת תקלה. הנהלים מתארים מה יש לעשות לפני ואחרי עדכון כדי לא להפיל את כל האתרים בבת אחת.
- הוראות למנהלי מערכת. תרחישים שלב-אחר-שלב למשימות אופייניות: הוספת אתר, העברה בין סביבות, החלפת דומיין, אבחון התנגשויות מודולים. מיועדים למנהל מערכת ללא ידע מעמיק במבנה הפנימי של המערכת.
- תרשים גיבוי ושחזור. מה נגבה ובאיזו תדירות, היכן נשמרים העותקים, תוך כמה זמן משוחזר אתר בודד ללא עצירת האחרים.
המארז נמסר בצורה מוכנה לעבודה: תצורות — כקבצים, תרשימים ומטריצות — בתיעוד, נהלים והוראות — בצורת טקסט. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית להרכב התוצרים עבור הסביבה שלכם.
בואו נדון במשימה שלכם בנושא ריבוי אתרים
כדי לחזור עם הערכה ותוכנית בנושא ריבוי אתרים, אנחנו צריכים להבין את המבנה הנוכחי שלכם: כמה אתרים, באילו דומיינים, מה ייחודי לכל אחד ומה משותף — קטלוג, סל קניות, משתמשים, ביצוע הזמנה.
מכך תלוי אם הכול נכנס ברישיון 1C-Bitrix אחד או שנדרש הרחבה, וכיצד נכון להפריד את התוכן כך שהאתרים לא יפריעו זה לזה.
תארו את המשימה בצורה חופשית: אילו פלטפורמות כבר פועלות, אילו אתם מתכננים להוסיף, היכן כרגע התוכן משוכפל ומה כואב — מהירות, עדכונים, גישות נפרדות לעורכים. אם יש גישה לתצורה הנוכחית או לתרשים הפריסה, צרפו — זה יאיץ את הבדיקה ויסיר שאלות מיותרות.
נחזור עם הערכה ותוכנית עבודה: נפרק את ריבוי האתרים לשלבים, נראה מה מעבירים לליבה משותפת ומה משאירים מבודד, ונסמן את סדר המיגרציה ללא השבתה של האתרים הפעילים. בתוכנית יהיה ניתן לראות אילו הגדרות אנחנו נוגעים בהן, כיצד מתחלקות ההרשאות ובאיזה שלב תוכלו לבדוק את התוצאה.
נדון במשימה באופן ענייני — בלי מילים כלליות על "גמישות" ו"יכולת הרחבה". ככל שהנתונים הראשוניים על מבנה האתרים שלכם יהיו מדויקים יותר, כך ההערכה תהיה מדויקת יותר ופחות תיקונים יהיה צורך לבצע כבר בתהליך.