הגדרת שרתים באמצעות Puppet: ניהול תצורה מלא

Puppet ניהול תצורה: היכן נשברת ההגדרה הידנית

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

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

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

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

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

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

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

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

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

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

דרכים לתיאור מצב השרתים: השוואת גישות

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

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

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

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

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

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

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

ארטיפקטים של יישום: מודולים, תפקידים, נהלים, דוחות

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

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

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

מקרה בוחן: איך נעלם סוג של תקלות בגלל אי-התאמות בין סביבות

נקודת מוצא

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

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

מה הראו המדדים

• זמן שחזור צומת — מ-3–5 שעות ל-15–20 דקות: הצומת עולה ביישום תפקיד, לא נותרו צעדים ידניים.
• שיעור ההגדרות האוטומטיות — מ-55% ל-99%; היתר הם רישיונות ונתונים שאנחנו במכוון לא מחזיקים בריפו.
• אי-התאמות בין סביבת הבדיקות לסביבת העבודה — מיותר משלושים סעיפים לאפס; עכשיו בדיקה לפני פריסה תופסת סטייה, ולא תורן אחרי תקלה.

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

במה Puppet שונה מסקריפטים ידניים לפריסה

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

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

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

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

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

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

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

מה עם שרתים שמוגדרים ידנית?

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

האם לגישה יש מגבלות?

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

מה קורה אחרי המסירה?

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

בואו נדון במשימה: מאיפה להתחיל סדר

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

מה נדרש מכם להתחלה:

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

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