Skip to Content
Getting Startedทำความเข้าใจ recipe

ทำความเข้าใจ recipe

BuildRecipe คือ specification ที่ normalize แล้วที่ OpenFactory ส่งเข้า image pipeline chat ช่วยเขียนได้ แต่ recipe source snapshot ไฟล์ที่ generate และหลักฐาน test คือสิ่งที่กำหนด build

แบบจำลองในหัว

recipe มาตรฐานมีสี่ชั้นหลัก:

  1. Identity and target: ชื่อ คำอธิบาย base image และ hardware intent
  2. Operating system: feature package service user security desktop installer attachment และ startup script ภายใต้ os
  3. Verification: scenario หนึ่งรายการขึ้นไปพร้อม built-in test และ custom assertion
  4. Delivery intent: ปลายทาง publication ที่ขอและการตั้งค่า delivery ทางเลือก
{
  "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 integration ใหม่ไม่ควรส่งรูปแบบ legacy เช่น baseImage features ระดับบนสุด หรือ startupScripts

สามการตรวจ สามคำตอบที่ต่างกัน

Schema validation

การ validate ตอบว่า “ข้อมูลที่รู้จักมีรูปร่างที่ยอมรับได้หรือไม่?” ไม่พิสูจน์ว่า package มีอยู่หรือพฤติกรรมใช้งานได้ field ที่ไม่รู้จักบางตัวถูกละเว้นเพื่อ compatibility ดังนั้น validate สำเร็จอาจยังขาดคำขอสำคัญ

เปรียบเทียบ recipe ที่ normalize แล้วที่คืนมากับ chat และ requirement เดิมเสมอ desktop application installer attachment หรือ test ที่ขาดเป็นข้อบกพร่องของ recipe แม้ validation บอก valid

Build evidence

build สำเร็จตอบว่า “pipeline สร้าง artifact หรือไม่?” ไม่พิสูจน์ว่า feature ที่ตั้งใจทุกอย่างเข้า image ตรวจ package inventory source provenance คำเตือน และหลักฐาน build stage

Guest verification

guest test ตอบคำถาม runtime แคบๆ ว่า VM boot หรือไม่ service active หรือไม่ พอร์ต listen หรือไม่ เนื้อหาไฟล์ตรงที่คาดหรือไม่ application launch หรือไม่ assertion ที่ผ่านสนับสนุนเฉพาะพฤติกรรมที่ observe จริง

การตั้งค่าความปลอดภัยคือ intent

ค่า hardening_level ที่ยอมรับคือ minimal standard และ strict แต่ label เหล่านี้ไม่ใช่ compliance profile ที่พกพาได้ target generator อาจตีความต่างกัน หากต้องการ benchmark เลือก benchmark ที่ใช้ได้ตรงๆ และเก็บผลต่อ control อย่าอนุมาน CIS conformance จาก strict

เช่นกัน disk_encryption audit_logging SELinux fail2ban Secure Boot dm-verity และการตั้งค่า installer ต้องมี artifact และ runtime test ที่สอดคล้อง

Chat และความเป็นเจ้าของ recipe

เมื่อ validate หรือแก้ recipe ที่ chat เขียน การสนทนาเดิมยังเป็นส่วนหนึ่งของ authoring context validation ควร refine recipe ปัจจุบัน ไม่แทนที่ด้วย generic default เงียบๆ ถึงอย่างนั้น recipe ที่ normalize แล้วยังเป็น checkpoint สุดท้ายก่อน build

สำหรับ requirement ที่มีนัยสำคัญแต่ละรายการ:

  • หา field ที่ normalize ที่สอดคล้อง;
  • ยืนยันค่าและ scope เป้าหมาย;
  • เพิ่ม assertion ที่พิสูจน์ runtime ได้; และ
  • เก็บงาน deploy เท่านั้นเป็น explicit warning แทนการแกล้งว่าทำระหว่าง image build

Checklist การทบทวน

  • base image และ architecture ถูกต้องหรือไม่?
  • desktop และ application feature ที่ขอครบหรือไม่?
  • แหล่งภายนอกถูก pin และมี license ตาม intended use หรือไม่?
  • ไม่มี secret ใน field recipe และ script ที่บันทึกหรือไม่?
  • installer ตั้งค่าและทดสอบบน disposable disk หากขอหรือไม่?
  • scenario ทดสอบ acceptance criteria จริงหรือไม่?
  • requirement ที่ไม่รองรับหรือตอน deploy ถูกระบุหรือไม่?

ดู Recipe Schema สำหรับ field reference และ บิลด์ครั้งแรกของคุณ สำหรับ workflow บิลด์และดาวน์โหลด

บิลด์ครั้งแรกของคุณIndex