הגדרת SaltStack לאוטומציה של תצורת שרתים

הגדרת SaltStack: היכן מתפצלת תצורת השרתים

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

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

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

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

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

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

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

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

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

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

השוואת גישות להגדרת SaltStack: מצבי עבודה

מה בדיוק משווים

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

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

סדר ההטמעה: מניתוח הצי ועד מסירת התקנונים

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

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

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

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

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

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

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

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

מה מוסרים לידיים: states, סכמות ומדיניות גישה

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

מה נשאר במאגר שלכם:

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

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

ניתוח הטמעה: מדדים לפני ואחרי בצי שרתים

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

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

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

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

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

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

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

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

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

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

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

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

איך מאובטח צומת הניהול?

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

האם אפשר לשנות תצורה ללא השבתה?

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

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

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

מה צריך כדי להעביר תחזוקה לצוות שלכם?

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

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

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

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

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