הגדרת AMI/Image Pipeline לתמונות זהב

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

היכולות שלנו:

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

מדוע הרכבה ידנית שוברת את תמונת הזהב של AMI

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

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

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

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

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

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

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

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

זמן ההרכבה וההעלאה לפעולה

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

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

זמן השחזור וצפיות החזרות לאחור

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

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

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

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

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

הרכבה מתבנית וממערכת בסיס

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

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

השלמת הגדרה של שרת שכבר עובד

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

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

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

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

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

בדיקת התמונה לפני העלייה לאוויר

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

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

תרשימים, קונפיגורציות ונוהלי הרכבה מחדש

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

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

כללי גישה ותפקידים

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

נוהל הרכבה מחדש ועדכונים

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

מקרה בוחן: סחיפת הקונפיגורציה הצטמצמה לאפס

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

מה היה לפני

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

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

מה נהיה אחרי

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

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

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

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

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

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

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

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

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

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

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

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

כמה זמן אורכת הרכבת תמונת הזהב עם הבדיקות?

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

מה עושים כשמתפרסם עדכון למערכת הבסיס?

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

מי אחראי לקו ההרכבה לאחר המסירה?

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

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

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

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

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