התקנת CMS Drupal: הגדרת שרת, מודולים ואבטחה

התקנת Drupal: צווארי בקבוק וכשלים אופייניים

התקנת Drupal נשברת בדרך כלל לא בשלב פריסת החבילה, אלא במעבר הראשון ממכונה מקומית לשרת production: האתר מחזיר 500, חלק מהעמודים ריקים, העלאת קבצים לא עובדת. מבחוץ זה נראה כתקלה של מערכת ניהול התוכן עצמה, אף שהסיבה כמעט תמיד היא סביבה לא מוכנה והגדרות שהתפצלו בין הסביבות.

את דרישות הסביבה בודקים לפני הפעלת המתקין: ענף גרסה עדכני של שפת ההרצה, הרחבות נדרשות (עיבוד תמונות, חיבור למסד נתונים, עבודה עם מחרוזות), מגבלות זיכרון וזמן הריצה המרבי של הסקריפט. הרחבה שחסרה יוצרת שגיאה באמצע התהליך — הטבלאות כבר נוצרו חלקית, והרצה חוזרת מתבצעת מול מצב לא עקבי.

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

הרשאות קבצים — הכשל האופייני השני. שרת האינטרנט, המפרש ובעל התיקיות פועלים תחת חשבונות שונים; תיקיית ההעלאות ותיקיות השירות חייבות להיות ניתנות לכתיבה, והקוד — לקריאה בלבד.

כשההרשאות נקבעות בנדיבות "העיקר שיעבוד", האתר נפתח, אבל כל עמוד שנטען בידי משתמש הופך לפוטנציאלית להרצה.

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

מה משתנה לאחר הגדרת השרת והמודולים

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

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

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

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

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

אפשרויות התקנה של Drupal: השוואת גישות

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

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

סדר העבודה: אבחון, סכימה, הגדרה, בדיקה

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

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

רצף השלבים

1. אבחון הסביבה. מקבעים גרסאות ליבה, PHP ומסד נתונים, הרכב מודולים ותבניות, הרשאות לתיקיות, הגדרות שרת האינטרנט ונקודות הכשל הנוכחיות — משאילתות איטיות ועד הרשאות גישה לא סגורות לאזורי שירות.
2. סכימת תצורה. מתארים את תצורת היעד: אילו מודולים נשארים, אילו מוחלפים, איך מופרדות הגדרות סביבות, היכן נשמרים סודות ואיך התצורה נכנסת למערכת בקרת גרסאות.
3. בניית קווי בדיקה. פורסים עותק בסביבה נפרדת עם אותן גרסאות והגדרות, מעבירים נתונים וקבצים — ומקבלים זירה שבה אפשר להחזיר כל שינוי בלי סיכון לאתר.
4. הגדרה בסביבת הבדיקה. מתקינים ומגדירים מודולים, מעבירים תוכן, מגדירים מטמון, הרשאות תפקידים, שליחת דואר והגנת טפסים מפני ספאם אוטומטי.
5. בדיקה. עוברים על תרחישי מפתח — התחברות, הרשמה, פרסום, חיפוש, תשלום, הורדת קבצים — ובודקים מרקאפ ומהירות תגובה, מתעדים תוצאת מדידות לפני ואחרי.
6. מעבר לסביבת העבודה. מעבירים את התצורה שנבדקה, מסנכרנים נתונים, מפעילים גיבוי ומעבירים תעבורה עם חלון אי-זמינות מינימלי.
7. מסירת הפרויקט. מוסרים גישות, סכימת תצורה, הוראות עדכון וחזרה, ומקיימים סשן הסבר עם הצוות שלכם — בהמשך הוא מתחזק את האתר בעצמו או בתמיכתנו.

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

מה נשאר בפרויקט: תצורות, סכימות, נהלים

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

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

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

קייס: קיצרנו את זמן ההתאוששות והסרנו השבתות

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

מה שינינו

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

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

מדדים לפני ואחרי: זמן התאוששות — מארבע שעות ל-15 דקות, שיעור הכשלים בשעות שיא — מ-5–6% ל-0.3%. יציבות ההגשה נשמרה גם בהכפלת השיא הקודם: זמן התגובה לרוב הבקשות נשאר בגבולות הקודמים.

במה פרויקט חדש שונה מהעברה של אתר פעיל?

ההבדל אינו בהתקנה, אלא במצב ההתחלתי של הפרויקט. באתר חדש התצורה נבנית מאפס: ליבת Drupal נקייה, רק המודולים הנחוצים, תפקידים והרשאות מתוארים מיד. בהעברה קודם כל נעשית ספירת מלאי — גרסת ליבה מז'ורית, מערך מודולים, היקף קוד מותאם, גודל מסד ואחסון קבצים.

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

מעבר בלי השבתה מבצעים על עותק: סביבה חדשה עולה לצד, המסד והקבצים מועברים, הכתובות נבדקות לפי מפת הפניות עם קוד 301. המעבר אורך דקות — מפחיתים מראש את ה-TTL של הדומיין.

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

ספקות לגבי אבטחה, עדכונים ועומס

לפני ההתחלה נשמעות בדרך כלל אותן שאלות טכניות: האם ה-CMS תפתח כניסות מיותרות, האם האתר ישרוד שיא ביקורים, מה קורה לאתר בזמן עדכון. אנחנו עונים לגופו של עניין — כפי שזה פותר בפרויקט.

עדכונים עוברים בלי השבתה?

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

איך מופרדות הרשאות גישה?

תפקידים מתוארים לפי תחומי אחריות אמיתיים: עורך מתקן תוכן, אבל לא נוגע במבנה ובהגדרות. פעולות ניהוליות — רק דרך חשבונות אישיים, עם יומן פעולות ואימות דו-שלבי.

מה עם גיבויים ועומס?

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

נדבר על המשימה: נשלח תוכנית עבודה והערכה

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

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

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

מכאן — שיחה עניינית: תארו את המשימה, ונחזור עם הערכה ותוכנית. להתחיל עבודה או לא — אתם מחליטים.