שרת AlmaLinux: התקנה, אבטחה, אוטומציה

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

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

המקום היקר ביותר — פריסת דיסקים בזמן ההתקנה. תרחיש «כל הדיסק למחיצת שורש אחת» משאיר בלי מרווח את /var ו-/var/log: הצפת יומנים או גדילת בסיס נתונים מפילים את כל המערכת.

פריסה עם LVM וכרכים נפרדים עבור /var, /var/log, /home ונתוני שירותים מאפשרת להרחיב את הכרך הדרוש ללא השבתה, ותמונת מצב לפני עדכון מחזירה את המצב הקודם בתוך דקות.

המקור השני לתקלות — התצורה הראשונית של שרת linux. התקנה «תחת root עם סיסמה ב-SSH» ו-SELinux מושבת חוסכים שעה בהתחלה, אבל אחר כך דורשים טיפול ידני בהרשאות בכל פעם שמצטרף מהנדס חדש.

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

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

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

מה נותן שרת מוכן: זמן, יציבות, שליטה

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

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

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

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

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

אפשרויות התקנה: הגדרה ידנית, תמונה, אוטומציה

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

היכן נגמרת האוטומציה

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

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

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

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

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

מה הלקוח מקבל לאחר התקנה והגדרה של השרת

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

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

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

מקרה בוחן: כיצד קיצרנו את זמן שחזור השרת לאחר תקלה

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

מה שינינו

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

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

מה קרה למדדים

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

הגדרה לפרויקט ווב ולבסיס נתונים: מה ההבדל

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

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

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

בפועל בוחרים באחת משלוש סכמות אחסון.

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

ספקות טכניים: עדכונים, הרשאות, העברת שרת

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

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

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

האם אפשר להעביר שרת שכבר פועל?

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

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

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

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

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

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

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