Smol machines – เครื่องเสมือนแบบพกพาที่มี cold start ต่ำกว่า 1 วินาที

 (github.com/smol-machines)
7 คะแนน โดย GN⁺ 12 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • smolvm คือ เครื่องมือจัดการเครื่องเสมือนแบบ CLI ที่ทำงานบน macOS และ Linux สำหรับรันซอฟต์แวร์ในสภาพแวดล้อมแบบแยกส่วน
  • รองรับ cold start ระดับ sub-second (ต่ำกว่า 1 วินาที), การจัดการหน่วยความจำแบบยืดหยุ่น, และ การพกพาแบบไฟล์เดียว ทำให้รัน VM ได้อย่างรวดเร็วและเบา
  • VM ทำงานในรูปแบบ microVM ที่ใช้เคอร์เนล Linux และสามารถแพ็กเกจเป็นไฟล์ .smolmachine เพื่อ นำไปรันซ้ำได้โดยไม่ต้องพึ่งพา dependency
  • รองรับทั้ง การแยกส่วนที่ขอบเขต hypervisor, SSH agent forwarding, และ การประกาศสภาพแวดล้อมด้วย Smolfile เพื่อรองรับทั้งงานพัฒนาและงานด้านความปลอดภัย
  • รองรับ การบูตอิมเมจ OCI โดยไม่ต้องมี Docker daemon และนำเสนอทางเลือกของ virtualization แบบเบาด้วย เวลาเปิดเครื่องต่ำกว่า 200ms และการแยกส่วนระดับฮาร์ดแวร์

ภาพรวม

  • smolvm คือ เครื่องมือจัดการเครื่องเสมือนแบบ CLI สำหรับ รันซอฟต์แวร์ในสภาพแวดล้อมแบบแยกส่วน
  • ทำงานบน macOS และ Linux และรองรับ cold start ระดับ sub-second, การใช้หน่วยความจำแบบยืดหยุ่น, และ การแพ็กเกจแบบไฟล์เดียวที่พกพาได้
  • แต่ละ workload จะทำงานเป็น microVM ที่ใช้เคอร์เนล Linux และให้ การแยกส่วนระดับฮาร์ดแวร์
  • VM ที่แพ็กเกจเป็นไฟล์ .smolmachine สามารถ นำไปรันซ้ำได้โดยไม่ต้องพึ่งพา dependency บนแพลตฟอร์มที่มีสถาปัตยกรรมเดียวกัน

ฟีเจอร์หลัก

  • การจัดการและรันเครื่องเสมือนภายในเครื่อง

    • รัน Linux VM แบบกำหนดเองด้วยคำสั่ง smolvm machine run
    • cold start ใช้เวลาต่ำกว่า 1 วินาที และรองรับทั้ง macOS และ Linux
    • หน่วยความจำถูกจัดการแบบยืดหยุ่นด้วย virtio balloon โดยโฮสต์จะจัดสรรตามปริมาณที่ใช้งานจริงเท่านั้น

  • การแพ็กเกจแบบไฟล์เดียวที่พกพาได้

    • สามารถรวมเป็นไฟล์ .smolmachine ที่มีสถานะของ VM อยู่ภายใน เพื่อสร้างใหม่บนแพลตฟอร์มอื่นได้
    • มี dependency ทั้งหมดฝังมาในตัว จึงรันได้ทันทีโดยไม่ต้องติดตั้ง และใช้เวลาเปิดเครื่อง ต่ำกว่า 200ms

  • แซนด์บ็อกซ์สำหรับโค้ดที่ไม่น่าเชื่อถือ

    • แยก filesystem, network และ credentials ของโฮสต์ ออกจากกันอย่างสมบูรณ์ผ่านขอบเขตของ hypervisor
    • เครือข่ายถูกปิดใช้งานเป็นค่าเริ่มต้น และสามารถอนุญาตเฉพาะโฮสต์บางตัวได้ด้วยตัวเลือก --allow-host

  • VM แบบคงอยู่สำหรับงานพัฒนา

    • สร้างและจัดการ VM ได้ด้วยคำสั่ง machine create, start, stop
    • แพ็กเกจที่ติดตั้งไว้จะยังคงอยู่หลังการรีสตาร์ต จึงนำไปใช้เป็นสภาพแวดล้อมพัฒนาได้

  • SSH agent forwarding

    • ส่งต่อ SSH agent ของโฮสต์เข้าไปใน VM ได้ โดย private key จะไม่ถูกคัดลอกเข้า guest
    • ใช้งานการยืนยันตัวตน SSH ของโฮสต์ได้อย่างปลอดภัยผ่านตัวเลือก --ssh-agent

  • การประกาศสภาพแวดล้อมด้วย Smolfile

    • ประกาศการตั้งค่า VM ด้วย Smolfile ในรูปแบบ TOML
    • สามารถกำหนดอิมเมจ เครือข่าย คำสั่งเริ่มต้น โวลุ่ม และตัวเลือกการยืนยันตัวตน เพื่อสร้าง สภาพแวดล้อมที่ทำซ้ำได้

ตัวอย่างการใช้งาน

  • รัน VM ชั่วคราว

    • smolvm machine run --net --image alpine -- sh -c "echo 'Hello world'"
    • เป็นรูปแบบการรันครั้งเดียวที่ VM จะถูกล้างอัตโนมัติเมื่อจบการทำงาน

  • สร้างไฟล์ปฏิบัติการที่แพ็กเกจแล้ว

    • smolvm pack create --image python:3.12-alpine -o ./python312
    • สามารถใช้ไฟล์ปฏิบัติการที่สร้างขึ้นเพื่อรันสภาพแวดล้อม Python แบบอิสระได้

  • การควบคุมเครือข่าย

    • เครือข่ายถูกปิดไว้เป็นค่าเริ่มต้น
    • อนุญาตให้เข้าถึงได้เฉพาะบางโดเมนผ่านตัวเลือก --allow-host

  • การใช้งาน SSH และ Git

    • smolvm machine run --ssh-agent --net --image alpine
    • สามารถใช้ SSH key ของโฮสต์อย่างปลอดภัยเพื่อเข้าถึง Git repository ได้

โครงสร้างภายในและวิธีการทำงาน

  • แต่ละ workload จะรัน เคอร์เนลแยกอิสระ บน Hypervisor.framework(macOS) หรือ KVM(Linux)
  • ใช้ VMM ที่อิงกับ libkrun และ เคอร์เนลแบบกำหนดเอง (libkrunfw)
  • รองรับ ฟอร์แมตอิมเมจ OCI จึงสามารถดึงอิมเมจจาก Docker Hub, ghcr.io เป็นต้น มารันได้โดยตรง
  • ไม่ต้องใช้ Docker daemon และสามารถบูตอิมเมจ OCI มาตรฐานได้โดยตรง
  • ค่าตั้งต้นคือ 4 vCPU, RAM 8GiB และปรับได้ด้วยตัวเลือก --cpus, --mem
  • เธรด vCPU จะเข้าสู่โหมดประหยัดพลังงานอัตโนมัติใน hypervisor เมื่อว่างงาน ทำให้ แทบไม่มีต้นทุนจากการ overcommit

การเปรียบเทียบ

รายการ smolvm Containers Colima QEMU Firecracker Kata
ระดับการแยกส่วน VM ต่อ workload namespace (ใช้เคอร์เนลร่วมกัน) namespace (VM เดียว) VM แยก VM แยก VM ต่อคอนเทนเนอร์
เวลาเปิดเครื่อง <200ms ประมาณ 100ms หลายวินาที 15~30 วินาที <125ms ประมาณ 500ms
สถาปัตยกรรม ไลบรารี (libkrun) daemon daemon ใน VM process process runtime stack
VM ต่อ workload รองรับ ไม่รองรับ ใช้ร่วมกัน รองรับ รองรับ รองรับ
รองรับ macOS แบบเนทีฟ รองรับ ผ่าน Docker VM อิง krunkit รองรับ ไม่รองรับ ไม่รองรับ
มี SDK ในตัว รองรับ ไม่รองรับ ไม่รองรับ ไม่รองรับ ไม่รองรับ ไม่รองรับ
อาร์ติแฟกต์แบบพกพาได้ .smolmachine อิมเมจที่ต้องใช้ daemon ไม่รองรับ ไม่รองรับ ไม่รองรับ ไม่รองรับ

การรองรับแพลตฟอร์ม

โฮสต์ เกสต์ ข้อกำหนด
macOS Apple Silicon arm64 Linux macOS 11 ขึ้นไป
macOS Intel x86_64 Linux macOS 11 ขึ้นไป (ยังทดสอบไม่สมบูรณ์)
Linux x86_64 x86_64 Linux ต้องใช้ KVM(/dev/kvm)
Linux aarch64 aarch64 Linux ต้องใช้ KVM(/dev/kvm)

ข้อจำกัดที่ทราบ

  • เครือข่ายถูกปิดใช้งานเป็นค่าเริ่มต้น และเปิดได้ด้วยตัวเลือก --net เท่านั้น
  • รองรับเฉพาะ TCP/UDP ไม่รองรับ ICMP
  • การเมานต์โวลุ่มทำได้ เฉพาะระดับไดเรกทอรี ไม่รองรับไฟล์เดี่ยว
  • บน macOS สามารถรันได้เฉพาะ ไบนารีที่เซ็นด้วยสิทธิ์ของ Hypervisor.framework เท่านั้น
  • เมื่อใช้ --ssh-agent โฮสต์ต้องมี SSH agent ทำงานอยู่ (SSH_AUTH_SOCK ต้องถูกตั้งค่า)

เกี่ยวกับการพัฒนา

  • ดูแนวทางการพัฒนาได้ที่ docs/DEVELOPMENT.md
  • เผยแพร่ภายใต้ สัญญาอนุญาต Apache-2.0 และสร้างโดย @binsquare

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 12 일 전
ความคิดเห็นจาก Hacker News

  • ฉันกำลังสร้าง virtual machine ที่จะมาแทน Docker container
    โดยตั้งเป้าหมายให้คงความใช้งานง่ายแบบเดียวกับ container ไว้ แต่มี เวลาเริ่มต้นต่ำกว่า 1 วินาที
    ตอนทำงานเกี่ยวกับ Firecracker ที่ AWS ฉันตระหนักได้ว่า container เป็นเลเยอร์ที่ไม่จำเป็น และ Firecracker ก็เป็นเทคโนโลยีที่ถูกออกแบบมาให้เข้ากับโครงสร้างภายในของ AWS
    เลยลงมือสร้างรูปแบบไฮบริดที่ผสานข้อดีของ container กับข้อดีของ Firecracker ด้วยตัวเอง
    อยากฟังความคิดเห็น

    • นี่เจ๋งมาก ฉันเองก็เคยทำ Locki โดยใช้การจับคู่ Lima+Incus ตอนกำลังค้นคว้าโซลูชัน AI sandboxing
      ปกติแล้ว microVM มักรัน Docker หรือ Kubernetes ไม่ได้ เลยเป็นจุดที่ค้างคาใจอยู่
      ฉันอยากใส่ Kubernetes cluster ทั้งก้อนไว้ใน sandbox เลย อยากรู้ว่ารองรับการ รัน k3s ด้วยไหม
    • อยากรู้ว่าสถานะการรองรับ live migration เป็นอย่างไร
      มันเป็นฟีเจอร์ที่มักหายไปจากระบบลักษณะนี้เสมอ แต่ก็ยังมีหลายสภาพแวดล้อมที่ต้องการฟีเจอร์นี้นอกเหนือจากงานแบบ cloud-native
      ถ้าใส่ฟีเจอร์นี้ได้ น่าจะเป็นจุดสร้างความแตกต่างที่ชัดมาก
    • อยากรู้ว่าส่วนไหนของโค้ดถูก LLM/AI เขียน ไปมากน้อยแค่ไหน
    • ฉันก็เคยทำอะไรคล้าย ๆ กันเหมือนกัน — ชื่อ shuru.run
      เพราะ Firecracker ใช้งานบน macOS ไม่ได้ เลยอยากทำ microVM sandbox สำหรับแอป AI ให้สร้างได้ง่าย ๆ
      สำหรับผู้ใช้ทั่วไป Firecracker หนักเกินไป
    • อยากรู้ว่าโจทย์ด้านการออกแบบที่ยากที่สุดในการทำให้ได้ เวลา boot ต่ำกว่า 1 วินาที คืออะไร
      แล้วถ้าจะลดเวลาให้ลงไปอีก ตอนนี้มี คอขวด อยู่ตรงไหนบ้าง

  • โปรเจกต์นี้ฟังดูคล้ายกับ unikernel implementation หลายตัว — เช่น Unikraft

    • ฉันไม่ค่อยรู้รายละเอียดภายในของ Unikraft เพราะมันไม่ได้เป็นโอเพนซอร์ส
      แต่ Smol Machines ไม่ใช่การทำ unikernel หากเป็น Linux kernel เวอร์ชันที่ถูกทำให้เล็กลง
      จึงเข้ากันได้กับซอฟต์แวร์ส่วนใหญ่ค่อนข้างดี

  • ฟีเจอร์สร้างไบนารีแบบพึ่งพาตัวเองได้ ดูเหมือนจะเป็นวิธีแพ็ก JVM app ที่ง่ายกว่า GraalVM Native
    ตัวอย่างคำสั่ง:
    smolvm pack create --image python:3.12-alpine -o ./python312
    ./python312 run -- python3 --version
    → Python 3.12.x จะรันแบบแยกขาดอย่างสมบูรณ์ โดยไม่ต้องใช้ pyenv/venv/conda

    • นี่เป็นแนวคิดที่คล้ายกับ Electron
      เหมือนที่ Electron แจกจ่ายเว็บแอปไปพร้อมเบราว์เซอร์ Smol Machines ก็ แพ็กซอฟต์แวร์ไปพร้อม Linux VM
      ช่วยหลีกเลี่ยงปัญหาเรื่องการจัดการ dependency หรือความเข้ากันได้
      ส่วนตัวฉันอยากเห็นเครื่องมืออย่าง Codex หรือ Claude Code แจกจ่ายในรูปแบบนี้เหมือนกัน
    • ทุกคนน่าจะเคยมีประสบการณ์ “ทำสภาพแวดล้อมสำหรับพัง” กันมาบ้าง
      นี่คือแนวคิดของ ‘เครื่องที่พร้อมแจกจ่าย’ เพื่อแก้ปัญหานั้น
      ถ้าตั้งค่าไว้ดีครั้งเดียว ก็แชร์ให้ใครก็ได้เอาไปรันต่อได้ทันที

  • อยากรู้ว่าไฟล์ .smolmachine รองรับ digital signature และ self-attestation หรือไม่
    และสามารถทำงานได้คล้าย เอกสารการเซ็น/ตรวจสอบของ Sylabs หรือเปล่า

  • อยากรู้ว่าถ้านำแนวคิดของ zeroboot มาใช้ จะทำให้เร็วขึ้นได้ไหม

  • ตารางเปรียบเทียบทำออกมาได้ดีมาก
    ตอนแรกฉันก็คิดว่า “คล้าย Firecracker นี่นา” แต่พอดูตารางแล้วเห็นความต่างได้ชัดเจน
    อ่านง่าย และโดยรวมถือว่าเป็นงานที่ น่าประทับใจมาก

    • ขอบคุณ

  • เห็นอิมเมจ alpine กับ python:3.12-alpine ในเอกสาร CLI เลยสงสัยว่ามันมาจากไหน
    ดึงมาจากที่อย่าง Docker registry หรือเปล่า เป็นของที่ฝังมาให้เลย หรือว่าต้องสร้างเองด้วย smolfile
    แล้วมีอิมเมจ Ubuntu ไหม
    ถ้ามีฟีเจอร์ memory/CPU hot resize เพิ่มเข้ามาก็น่าจะดี และน่าจะใช้กับการ orchestration backend infrastructure แยกตามลูกค้าได้ด้วย

  • โปรเจกต์โอเพนซอร์สส่วนใหญ่ใช้ Docker Compose ในการรัน container แต่ Smol Machines ไม่รองรับ Docker ภายใน microVM
    และก็น่าเสียดายที่ไม่รองรับ nested VM อย่าง Vagrant ด้วย

    • มีแผนจะรองรับ Docker โดยในรีลีสถัดไปตั้งใจจะปล่อย kernel ที่เข้ากันได้ พร้อม kernel flag ที่จำเป็น
    • ดูเหมือน Vagrant จะต้องใช้ nesting เพราะมันต้องเปิด VM บนเครื่องโลคัล
      แต่อาจลองใช้ วิธี trampoline ให้มันรันเป็น sibling VM ของ Vagrant VM แทนได้ไหม

  • อยากให้ช่วยอธิบายสั้น ๆ ว่าเหตุผลหลักที่ควรใช้ Smol Machines แทน Docker sandbox คืออะไร

  • เป็นผลงานที่ยอดเยี่ยมมาก ขอแสดงความยินดี