התקנה והגדרה של CentOS / RHEL Server מקצה לקצה

התקנת CentOS Server: היכן נשברת התצורה הידנית

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

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

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

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

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

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

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

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

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

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

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

אפשרויות פריסה: שרת ייעודי, וירטואליזציה, ענן

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

אותה הפצה בדיוק — הענף העדכני של Red Hat Enterprise Linux או המקבילה החופשית שלו — מתנהגת באופן שונה על חומרה ובענן: שונים העבודה עם דרייברים, עם צילומי מצב ועם הגדרות רשת.

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

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

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

שלבי ההטמעה: מהאבחון ועד מסירה לתחזוקה

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

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

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

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

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

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

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

תצורות CentOS Server, תרשימי רשת ותקנונים

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

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

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

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

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

מה שינו

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

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

מה התקבל

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

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

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

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

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

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

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

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

האם הסביבה החדשה תואמת לזו הנוכחית שלנו?

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

מי וכיצד מקבל גישה לשרת?

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

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

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

מה כולל התחזוקה לאחר ההטמעה?

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

נדון במשימה ונחזור עם הערכה ותוכנית עבודה

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

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

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