Skip to Content
เอกสาร OpenFactory

เอกสาร OpenFactory

OpenFactory ให้การประเมิน Linux ผ่านเบราว์เซอร์ สูตรและการสร้างอิมเมจแบบกำหนดเอง การตรวจสอบอาร์ติแฟกต์ การทดสอบ VM และเวิร์กโฟลว์การ deploy ที่เกี่ยวข้อง ฟีเจอร์ที่บัญชีหรือคอนโซล self-host ใช้ได้ขึ้นกับรุ่นที่ deploy แผน ธงฟีเจอร์ และโครงสร้างพื้นฐานที่เชื่อมต่อ

เริ่มจากงาน

เป้าหมายเส้นทางเอกสาร
สร้างและยืนยันอิมเมจแบบกำหนดเองการ build ครั้งแรก
เข้าใจ recipe JSON ที่ normalize แล้วRecipe Schema
ตั้งค่าฟีเจอร์ buildการ build ระบบปฏิบัติการ
boot และตรวจสอบ VMการจัดการ VM
กำหนดหลักฐานหลัง buildการทดสอบ
เชื่อม MCP clientการเชื่อม MCP
ประเมินคอนโซล KVM ในเครื่องคอนโซล VM แบบ Self-Host
เข้าใจขอบเขตการทำงานร่วมกันบทบาทและขอบเขตสิทธิ์

โมเดลหลักฐาน

OpenFactory แสดงสถานะหลายอย่างที่ไม่ควรรวมเป็นป้าย “สำเร็จ” เดียว:

  1. การตรวจสอบ recipe ตรวจรูปแบบการตั้งค่าที่รู้จักและขอบเขตคำขอที่ระบุชัด
  2. การ build เสร็จ หมายถึงอาร์ติแฟกต์อิมเมจถึงเส้นทาง finalize
  3. การทดสอบเสร็จ บันทึกผลของ guest assertion ที่เลือก
  4. สถานะการรับรองหรือนโยบาย (ถ้ามี) ใช้กับสัญญาหลักฐานที่ตั้งชื่อเท่านั้น
  5. การรับรองทางกายภาพหรือ production ยังเป็นกิจกรรมแยก เว้นแต่จะทดสอบฮาร์ดแวร์ โทโพโลジี โหมดความล้มเหลว และรุ่นที่ตรงกันแล้ว

ใช้ข้อความที่แคบและรองรับที่สุด แพ็กเกจใน recipe ไม่ใช่หลักฐานว่าติดตั้งแล้ว แพ็กเกจที่ติดตั้งแล้วไม่ใช่หลักฐานว่า service สุขภาพดี การ boot VM ไม่ใช่หลักฐานว่า installer หรืออุปกรณ์จริงใช้ได้

ขอบเขต Hosted และ Self-Host

บริการ hosted มี workflow การ build อิมเมจและการสนทนา การ deploy Compose แบบ self-host ใน repo เป็นคอนโซล KVM บนโฮสต์เดียวที่มีสิทธิ์สูงสำหรับการประเมิน มันปิด build hosted การสนทนา การ schedule และ workflow เอกสารนโยบาย และไม่ได้สร้างการทำงาน production หรือ air-gapped ด้วยตัวเอง

สำหรับ deploy production แบบ private ใช้เอกสารสถาปัตยกรรม ตัวตน การเก็บถาวร สำรอง อัปเกรด และการสนับสนุนตามรุ่นที่ตกลงกับ OpenFactory อย่าใช้รายการความสามารถทางการตลาดหรือไฟล์ Compose สำหรับประเมินแทน runbook นั้น

วิธีอ่านเอกสารนี้

  • คำสั่งระบุบริบทการทำงานและผลที่คาดหวังเมื่อเป็นไปได้
  • ข้อความด้านความปลอดภัย การปฏิบัติตาม ความพร้อมใช้ และความเข้ากันได้ มีขอบเขตหลักฐาน
  • ถ้า UI กับหน้าคงที่ไม่ตรงกัน เก็บ build หรือ run ID และตรวจ API/สถานะปัจจุบันก่อนทำซ้ำการกระทำที่ทำลายข้อมูล
  • รายงานเอกสารล้าสมัยพร้อม URL หน้า รุ่นผลิตภัณฑ์หรือ commit เวลา และผลที่สังเกต

ต่อด้วย เริ่มต้นใช้งาน