התקנה אוטומטית של Linux באמצעות Preseed, Kickstart, Autoinstall

Preseed: מדוע התקנה ידנית של Linux אינה ניתנת להרחבה

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

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

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

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

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

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

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

• זמן פריסת השרת. הצומת עובר מהדלקה ועד מוכנות לתפקיד בדקות במקום שעות של קליקים ידניים — חלוקת הדיסק, הרשת, סט החבילות וההרשאות נלקחים מקובץ התשובות.
• שיעור הפעולות ללא מגע יד אדם. ההתקנה, ההגדרה הבסיסית והחיבור לניטור מבוצעים בלי שהמהנדס נכנס לקונסולה; ביד נשארות רק החלטות שדורשות בחירה.
• צמצום טעויות ידניות. שגיאת כתיב בחלוקה, מחיצה שנשכחה ללוגים, סט חבילות שהתפצל — הסיבות האלה נעלמות, כי התבנית אחת והיא עוברת בדיקה במאגר.
• חזרתיות של תצורות. שתי מכונות מאותה תבנית אינן ניתנות להבחנה לפי הרכב החבילות, פרמטרי הקרנל והגדרות הגישה: צמתים "מיוחדים" שאי אפשר לבנות מחדש לא נשארים.
• תבנית התקנה אחת. Preseed עבור Debian ונגזרותיה, Kickstart למשפחת Red Hat, Autoinstall לגרסאות עדכניות — המדיום שונה, הכללים מתוארים אותו דבר.
• תקריות בגלל הגדרות שונות. שיעור הכשלים שהשורש שלהם היה חוסר סנכרון בין מכונות יורד למקרים בודדים, ושחזור צומת מצטמצם להרצה חוזרת של התבנית.

השוואה בין Preseed, Kickstart ו-Autoinstall: מה לבחור

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

היכן כל תבנית מתאימה

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

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

שלבי הטמעת התקנה אוטומטית: מביקורת ועד קבלה

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

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

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

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

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

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

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

התחלנו ממלאי: חילקנו את המכונות למחלקות — צומתי ווב, בסיסי נתונים, מארחי שירות — ולכל אחת תיארנו את תשובות המתקין בקובץ תבנית.

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

מה שינו בתהליך

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

מדדים לפני ואחרי

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

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

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

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

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

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

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

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

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

ספקות טכניים נפוצים והתשובות להם

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

האם תבנית התקנה אינה פרצת אבטחה?

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

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

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

מה עושים אם ההתקנה נכשלה?

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

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

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

• מלאי: תפקידי הצמתים, דגמים שונים, נפח דיסקים, החלוקה הנוכחית ושיטת האתחול;
• רשת האתחול: האם קיים קונטור התקנה מרחוק, DHCP משלכם או שיש לבודד אותו מרשת העבודה;
• מצב היעד: LVM או RAID, הצפנה, מערכת קבצים, נקודות mount;
• פרמטרי מערכת: חשבונות ומפתחות גישה, אזור זמן, לוקאל, סט חבילות חובה;
• מקרים לא שגרתיים: מכונות בלי רשת קווית, צמתים עם UEFI ו-Secure Boot מופעל, התקנה מחדש מעל מערכת קיימת;
• בקרה לאחר ההתקנה: אילו בדיקות צריכות לעבור אוטומטית לפני שהצומת ייכנס לעבודה.

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

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

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