תוכנה מותאמת אישית ממאגרי מקור

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

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

צורת מתכון

ערכי חבילה מותאמות אישית פועלות תחת os.custom_packages:

{
  "os": {
    "custom_packages": [
      {
        "name": "my-agent",
        "git_url": "https://github.com/example/my-agent.git",
        "branch": "release-1.x"
      }
    ]
  }
}

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

הכן את המאגר

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

עבור אריזות דביאן, סקור לפחות:

• debian/control עבור זהות מקור/בינארית ותלות;
• debian/changelog עבור גרסת החבילה;
• debian/rules וסקריפטים אחרים לתחזוקה הניתנים להפעלה;
• התקנת מניפסטים ויחידות מערכת; ו
• רישוי וחומרי צד שלישי מצורפים.

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

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

בקרות חבילה אחרות

חבילות Native

השתמש ב- os.packages עבור חבילות שכבר סופקו על ידי ההפצה שנבחרה או מאגר מוגדר במפורש:

{
  "os": {
    "packages": ["curl", "jq"]
  }
}

עקיפות חבילה

os.package_overrides יכול להצהיר על כוונות add, remove או replace:

{
  "os": {
    "package_overrides": [
      {"name": "nano", "action": "replace", "replacement": "neovim"},
      {"name": "telnet", "action": "remove"}
    ]
  }
}

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

מאגרים נוספים

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

הוכחות קבלה

עבור כל חבילה מותאמת אישית, שמרו:

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

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

פתרון בעיות

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