הגדרת שרת Rocky Linux: מהתקנה ועד לסביבת ייצור

התקנת Rocky Linux: היכן נשבר התרחיש הטיפוסי

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

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

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

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

מה נותנת התקנה נכונה והגדרה בסיסית של השרת

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

כל סעיף מסיר סוג אחר של כשל — מ"לא עלה אחרי עדכון" ועד "הדיסק נגמר בשלוש לפנות בוקר".

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

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

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

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

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

מצבי פריסה: מה מתאים לאיזו משימה

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

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

סדר יישום: מביקורת ועד מסירה לתמיכה

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

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

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

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

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

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

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

ערכת אספקה: קונפיגורציות, סכמות, תקנונים

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

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

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

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

לפני: הרכבה ידנית וקונפיגורציות סוטות

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

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

השינוי: סכמה מנוהלת אחידה

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

אחרי: הכנסה צפויה ומינימום שינויים ידניים

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

מה לעשות אם השרת כבר פרוס ומוגדר ידנית

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

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

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

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

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

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

ספקות טכניים: מתחם סגור, עדכונים, גישות

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

כיצד להפריד גישות בין מנהלים לשירותים?

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

מה יקרה לנתונים במקרה של כשל דיסק או שינוי כושל?

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

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

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

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

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