הבנת מתכונים

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

המודל המנטלי

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

1. Identity and target: שם, תיאור, תמונת בסיס וכוונת חומרה.
2. Operating system: תכונות, חבילות, שירותים, משתמשים, אבטחה, שולחן עבודה, מתקין, קבצים מצורפים וסקריפטים להפעלה תחת os.
3. Verification: תרחיש אחד או יותר עם בדיקות מובנות וקביעות מותאמות אישית.
4. Delivery intent: יעדי פרסום מבוקשים והגדרות משלוח אופציונליות.

{
  "name": "debian-web-check",
  "display_name": "Debian Web Check",
  "description": "Small Debian image with explicit smoke tests.",
  "base_image": "debian-trixie",
  "hardware": {
    "platform": "pc",
    "architecture": "x86_64",
    "min_cpu_cores": 2,
    "min_memory_gb": 4,
    "min_storage_gb": 16,
    "nic_count": 1
  },
  "os": {
    "features": ["ssh"],
    "packages": ["curl"],
    "services": [
      {
        "name": "ssh",
        "enabled": true,
        "config": {"port": 22, "disable_password_auth": true}
      }
    ],
    "security": {
      "hardening_level": "standard",
      "audit_logging": true
    }
  },
  "scenarios": [
    {
      "id": "primary-smoke",
      "name": "Primary image smoke test",
      "enabled": true,
      "tests": ["boot", "login", "packages"]
    }
  ],
  "publish_to": ["local"]
}

השתמש ב-snake_case. אינטגרציות חדשות לא אמורות לשלוח צורות מדור קודם כמו baseImage, features ברמה העליונה או startupScripts.

שלוש המחאות, שלוש תשובות שונות

אימות סכימה

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

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

בנה ראיות

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

אימות אורח

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

הגדרות האבטחה הן בכוונה

הערכים hardening_level המקובלים הם minimal, standard ו-strict, אך התוויות הללו אינן פרופילי תאימות ניידים. מחוללי יעדים יכולים לפרש אותם אחרת. אם אתה זקוק למבחן ביצועים, בחר את המדד הרלוונטי המדויק ושמר תוצאות לכל בקרה; אל תסיק התאמה של CIS מ- strict.

באופן דומה, הגדרות disk_encryption, audit_logging, SELinux, fail2ban, Secure Boot, dm-verity והגדרות מתקין דורשות בדיקות תואמות של חפצים וזמן ריצה.

צ’אט ובעלות על מתכונים

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

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

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

סקור את רשימת הבדיקה

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

ראה סכמת מתכונים להפניה לשדה ו-המבנה הראשון שלך לזרימת העבודה של הבנייה וההורדה.