Tencent Cloud เปิดตัว CubeSandbox: AI Sandbox ที่เริ่มต้นใน 60 มิลลิวินาที ใช้โซลูชันแยกฮาร์ดแวร์ระดับ RustVMM และ KVM

คำสำคัญ: AI Sandbox, MicroVM, KVM Isolation, RustVMM, E2B Compatibility

ในวินาทีที่คุณให้โมเดลภาษาขนาดใหญ่สร้างสคริปต์ Python และกดปุ่ม “รัน” ปัญหาด้านความปลอดภัยพื้นฐานก็ปรากฏขึ้นทันที — โค้ดที่ยังไม่ผ่านการตรวจสอบนี้จะทำงานที่ไหน?

Docker container เป็นตัวเลือกแรกของทีมส่วนใหญ่ แต่การแยก Namespace ที่ใช้ kernel ร่วมกันนั้นพิสูจน์แล้วว่ามีความเสี่ยง: ช่องโหว่การหลบหนีจาก container เกิดขึ้นเป็นระยะ หาก AI Agent ถูกชักจูงให้รันโค้ดที่เป็นอันตราย โฮสต์ทั้งเครื่องอาจตกอยู่ในอันตราย

• CubeSandbox เป็นบริการ sandbox ที่ปลอดภัย มีประสิทธิภาพสูง พร้อมใช้งานทันที สร้างจาก RustVMM และ KVM รองรับทั้งการติดตั้งแบบโหนดเดียวและสามารถขยายเป็นคลัสเตอร์หลายโหนดได้อย่างง่ายดาย บริการนี้เข้ากันได้กับ E2B SDK สามารถสร้างสภาพแวดล้อม sandbox ที่แยกด้วยฮาร์ดแวร์และมีความสามารถเต็มรูปแบบได้ภายใน 60 มิลลิวินาที พร้อมควบคุมการใช้หน่วยความจำให้ต่ำกว่า 5MB
• ที่อยู่โปรเจกต์: https://github.com/TencentCloud/CubeSandbox

แม้ว่า Virtual Machine แบบดั้งเดิมจะให้การแยกที่แข็งแกร่ง แต่ความเร็วในการเริ่มต้นที่ใช้เวลาหลายนาทีและการใช้หน่วยความจำที่มักสูงถึงหลายร้อยเมกะไบต์ ทำให้มันไม่เหมาะกับสถานการณ์การใช้งาน AI ที่ต้อง “สร้างสภาพแวดล้อมใหม่ทุกครั้งที่มีการสนทนา”

มีวิธีใดที่สามารถรวมความปลอดภัยระดับ kernel ของ Virtual Machine กับความเบาและคล่องตัวของ container ได้พร้อมกันหรือไม่? CubeSandbox ที่เปิดตัวโดย Tencent Cloud นั้นคือคำตอบทางวิศวกรรมสำหรับปัญหาที่ยากลำบากนี้

สารบัญบทความ

• ศูนย์ เริ่มต้นใช้งานอย่างรวดเร็ว: เรียกใช้ sandbox ปลอดภัยตัวแรกของคุณตั้งแต่เริ่มต้น
  • 0.1 ข้อกำหนดสภาพแวดล้อม
  • 0.2 ขั้นตอนที่หนึ่ง: ติดตั้งบริการด้วยคำสั่งเดียว
  • 0.3 ขั้นตอนที่สอง: สร้างเทมเพลต sandbox
  • 0.4 ขั้นตอนที่สาม: ใช้ E2B SDK เพื่อรันโค้ด
• หนึ่ง ภาพรวมสถาปัตยกรรมและปรัชญาการออกแบบ
  • 1.1 วงจรชีวิตเต็มรูปแบบของคำขอ
• สอง CubeAPI: API Gateway ที่เขียนใหม่ด้วย Rust
  • 2.1 การลงทะเบียนเส้นทางและ Middleware Stack
  • 2.2 การควบคุมอย่างละเอียดของ Asynchronous Runtime
• สาม CubeShim: containerd Shim v2 ที่พัฒนาด้วย Rust
  • 3.1 เทคนิคการขยาย File Descriptor ล่วงหน้าเมื่อเริ่มต้น
  • 3.2 การแบ่งโมดูลหลัก
• สี่ CubeProxy: การกำหนดเส้นทางอัจฉริยะบนพื้นฐาน OpenResty
• ห้า Hypervisor Layer: การปรับแต่งเชิงลึกบนพื้นฐาน Cloud Hypervisor
• หก CubeVS และโมเดลความปลอดภัยเครือข่าย
• เจ็ด การติดตั้งด้วยคำสั่งเดียวและการปฏิบัติในสภาพแวดล้อมจริง
• สรุปและแนวโน้มในอนาคต

ศูนย์ เริ่มต้นใช้งานอย่างรวดเร็ว: เรียกใช้ sandbox ปลอดภัยตัวแรกของคุณตั้งแต่เริ่มต้น

ส่วนนี้มีจุดมุ่งหมายให้ผู้อ่านสามารถทดสอบการทำงานแบบ end-to-end ภายใน 5 นาที สำหรับเนื้อหาขั้นสูง เช่น การติดตั้งคลัสเตอร์หลายโหนด เทมเพลตที่กำหนดเอง การจัดการใบรับรอง TLS โปรดดูคู่มือ Quick Start ฉบับเต็ม

0.1 ข้อกำหนดสภาพแวดล้อม

• เซิร์ฟเวอร์ Linux แบบกายภาพที่มีสถาปัตยกรรม x86_64 ต้องเปิดใช้งาน KVM (ตรวจสอบว่ามีอุปกรณ์ /dev/kvm)
• Docker ติดตั้งและกำลังทำงานอยู่
• เซิร์ฟเวอร์ต้องสามารถเข้าถึงอินเทอร์เน็ตภายนอกได้ (สำหรับดึงอิมเมจและแพ็กเกจติดตั้ง)

💡 คำแนะนำ: สภาพแวดล้อม Virtual Machine (Nested Virtualization) สามารถใช้ได้ในทางทฤษฎี แต่ไม่แนะนำสำหรับการใช้งานจริง เซิร์ฟเวอร์คลาวด์ต้องยืนยันว่าประเภทอินสแตนซ์รองรับ KVM Passthrough ดูรายละเอียดเพิ่มเติมในเอกสารการติดตั้งหลายโหนด

0.2 ขั้นตอนที่หนึ่ง: ติดตั้งบริการด้วยคำสั่งเดียว

bash
curl -sL https://github.com/tencentcloud/CubeSandbox/raw/master/cube-sandbox/deploy/one-click/online-install.sh | bash

สคริปต์ติดตั้งจะทำงานต่อไปนี้โดยอัตโนมัติ: เริ่มต้น CubeAPI (พอร์ต 3000), CubeMaster, Cubelet, CubeShim, CubeProxy (รวมใบรับรอง TLS จาก mkcert), CoreDNS และ container ที่จำเป็นอื่นๆ เช่น MySQL / Redis

⚠️ หมายเหตุ: หากชื่อเน็ตเวิร์คการ์ดหลักของเซิร์ฟเวอร์ไม่ใช่ eth0 ต้องระบุ IP ของโหนดด้วยตนเองก่อนรันคำสั่งติดตั้ง:
bash
CUBE_SANDBOX_NODE_IP=<your-ip> bash <(curl -sL https://github.com/tencentcloud/CubeSandbox/raw/master/cube-sandbox/deploy/one-click/online-install.sh)

หลังจากติดตั้งเสร็จ ให้เพิ่มเครื่องมือ CLI เข้าไปใน PATH ของระบบ:
bash
echo 'export PATH=/usr/local/services/cubetoolbox/CubeMaster/bin:$PATH' >> ~/.bashrc
source ~/.bashrc

0.3 ขั้นตอนที่สอง: สร้างเทมเพลต sandbox

bash
cubemastercli tpl create-from-image
--image ccr.ccs.tencentyun.com/ags-image/sandbox-code:latest
--writable-layer-size 1G
--expose-port 49999
--expose-port 49983
--probe 49999

รอให้การสร้างเทมเพลตเสร็จสิ้น (สามารถติดตามความคืบหน้าด้วยคำสั่ง cubemastercli tpl watch --job-id <job_id>) และบันทึก Template ID จากผลลัพธ์

สำหรับเวิร์กโฟลว์แบบเต็มของการสร้างเทมเพลตจากอิมเมจที่กำหนดเอง โปรดดูเอกสาร Template Concepts

0.4 ขั้นตอนที่สาม: ใช้ E2B SDK เพื่อรันโค้ด

ขั้นแรก ติดตั้ง E2B SDK:
bash
pip install e2b-code-interpreter

ตั้งค่าตัวแปรสภาพแวดล้อมที่จำเป็น:
bash
export E2B_API_URL="http://127.0.0.1:3000"
export E2B_API_KEY="dummy" # สำหรับการติดตั้งในเครื่อง ใช้สตริงที่ไม่ว่างใดๆ ก็ได้
export CUBE_TEMPLATE_ID="<Template ID ที่ได้จากขั้นตอนที่สอง>"
export SSL_CERT_FILE="$(mkcert -CAROOT)/rootCA.pem"

| ตัวแปร | คำอธิบาย |
| :— | :— |
| E2B_API_URL | ชี้ E2B SDK ไปที่ CubeAPI ที่ติดตั้งในเครื่อง แทนที่จะเป็นบริการคลาวด์อย่างเป็นทางการ |
| E2B_API_KEY | ภายใน SDK มีการตรวจสอบว่าต้องไม่ว่างเปล่า สำหรับการติดตั้งในเครื่องสามารถกรอกค่าใดๆ ก็ได้ |
| CUBE_TEMPLATE_ID | ID เทมเพลต sandbox ซึ่งกำหนดสภาพแวดล้อมเฉพาะที่รันภายใน Virtual Machine |
| SSL_CERT_FILE | เส้นทางไปยังใบรับรองรูทของ mkcert ใช้สำหรับการเชื่อมต่อ HTTPS ของ SDK ไปยัง sandbox |

รันโค้ดชุดแรกของคุณในสภาพแวดล้อมที่แยกด้วยฮาร์ดแวร์:
python
import os
from e2b_code_interpreter import Sandbox # ใช้ E2B SDK อย่างเป็นทางการโดยตรง

with Sandbox.create(template=os.environ[“CUBE_TEMPLATE_ID”]) as sandbox:
# โค้ดต่อไปนี้ทำงานภายใน MicroVM แบบ KVM ที่มี kernel เป็นของตัวเอง
result = sandbox.run_code(“print(‘Hello from Cube Sandbox!’)”)
print(result)

# หรือสามารถรันคำสั่ง Shell ได้
cmd = sandbox.commands.run("uname -a")
print(cmd.stdout)  # ผลลัพธ์จะแสดงว่านี่คือ Guest kernel ที่เป็นอิสระ

สำหรับตัวอย่างโดยละเอียดของสถานการณ์การใช้งานอื่นๆ (เช่น การรันคำสั่ง Shell การอ่านเขียนไฟล์ การทำอัตโนมัติเบราว์เซอร์ การหยุด/กลับมาทำงานต่อของ sandbox การกำหนดค่านโยบายเครือข่าย ฯลฯ) โปรดดูไดเรกทอรี examples/ ของโปรเจกต์และบทแนะนำตัวอย่าง

หนึ่ง ภาพรวมสถาปัตยกรรมและปรัชญาการออกแบบ

แนวคิดการออกแบบหลักของ CubeSandbox สามารถสรุปได้ว่า: การแยกส่วนเป็นชั้น การตัดทอนให้เหลือน้อยที่สุด

ทั้งระบบแบ่งออกเป็นหกคอมโพเนนต์หลักจากบนลงล่าง สร้างเป็นลำดับการประมวลผลแบบเต็มรูปแบบตั้งแต่คำขอ HTTP ไปจนถึงการทำงานของโปรเซสภายใน MicroVM:

| คอมโพเนนต์ | ภาษา | หน้าที่ |
| :— | :— | :— |
| CubeAPI | Rust (Axum) | ให้ API Gateway แบบ REST ที่เข้ากันได้กับ E2B |
| CubeMaster | Go | Cluster Orchestrator และ Scheduler รับผิดชอบการจัดการทรัพยากรและสถานะ |
| CubeProxy | OpenResty/Lua | Reverse Proxy กำหนดเส้นทางคำขอไปยัง sandbox เป้าหมาย |
| Cubelet | Go | จัดการวงจรชีวิตของ sandbox ในโหนดเดียว |
| CubeVS | eBPF/C | Virtual Switch ใน Kernel Mode ดำเนินการแยกเครือข่าย |
| CubeRuntime | Rust | Runtime ที่รวม Shim, Hypervisor และ Agent |

สถาปัตยกรรมนี้ได้รับแรงบันดาลใจจากรูปแบบ Master-Node ของ Kubernetes อย่างจงใจ (CubeMaster ตรงกับ kube-apiserver และ scheduler, Cubelet ตรงกับ kubelet) แต่ ไม่ขึ้นกับ Kubernetes รองรับการติดตั้งและทำงานแบบเครื่องเดียวด้วยคำสั่งเดียว

นี่เป็นการตัดสินใจด้านผลิตภัณฑ์ที่สำคัญ: ในสถานการณ์การพัฒนา AI Agent นักพัฒนามักไม่ต้องการดูแลคลัสเตอร์ K8s แบบเต็ม แต่ต้องการสภาพแวดล้อม sandbox ที่ปลอดภัยพร้อมใช้งานทันทีมากกว่า

1.1 วงจรชีวิตเต็มรูปแบบของคำขอ

ขั้นตอนทั่วไปของการสร้าง sandbox มีดังนี้:

1. ผู้ใช้ส่งคำขอ POST /sandboxes ผ่าน E2B SDK
2. CubeAPI รับคำขอและส่งต่อไปยัง CubeMaster
3. CubeMaster จัดตารางงานไปยังโหนด Cubelet ที่เหมาะสม
4. Cubelet เรียก CubeShim ผ่าน containerd (ตามโปรโตคอล Shim v2)
5. CubeShim ขอให้ Hypervisor เริ่มต้น MicroVM บนพื้นฐาน KVM
6. cube-agent ภายใน MicroVM พร้อมใช้งาน sandbox เข้าสู่สถานะพร้อมใช้

ด้วยการเตรียมพูลทรัพยากรและเทคโนโลยีโคลนจากสแนปช็อต เวลาตอบสนอง end-to-end ของลำดับทั้งหมดนี้สามารถควบคุมได้ภายใน 60 มิลลิวินาที ข้ามขั้นตอนการบูตที่ยาวนานของ Virtual Machine แบบดั้งเดิม

สอง CubeAPI: API Gateway บนพื้นฐาน Rust

CubeAPI ในฐานะจุดเข้าใช้งานของระบบ มีภารกิจพิเศษ: ทำให้ผู้ใช้ไม่ต้องแก้ไขโค้ดธุรกิจใดๆ ก็สามารถย้ายจากบริการคลาวด์ E2B ไปยังสภาพแวดล้อม sandbox ที่โฮสต์เองได้อย่างราบรื่น เพียงเปลี่ยนตัวแปรสภาพแวดล้อม E2B_API_URL การเรียกทั้งหมดที่ส่งผ่าน Python SDK อย่างเป็นทางการของ E2B จะถูก CubeAPI รับช่วงต่ออย่างโปร่งใส

2.1 การลงทะเบียนเส้นทางและ Middleware Stack

CubeAPI สร้างบนเฟรมเวิร์ก Axum การออกแบบเลเยอร์เส้นทางมีความชัดเจน:

rust
// ที่มา: CubeAPI/src/routes.rs
pub fn build_router(state: AppState) -> Router {
let sandbox_routes = Router::new()
.route(“/sandboxes”, get(sandboxes::list_sandboxes))
.route(“/sandboxes”, post(sandboxes::create_sandbox))
.route(“/v2/sandboxes”, get(sandboxes::list_sandboxes_v2))
.route(“/sandboxes/:sandboxID”, get(sandboxes::get_sandbox))
.route(“/sandboxes/:sandboxID”, delete(sandboxes::kill_sandbox))
.route(“/sandboxes/:sandboxID/pause”, post(sandboxes::pause_sandbox))
.route(“/sandboxes/:sandboxID/resume”, post(sandboxes::resume_sandbox))
.route(“/sandboxes/:sandboxID/connect”, post(sandboxes::connect_sandbox));

// Global Middleware: RequestID, Tracing, Timeout, Compression, CORS
Router::new()
    .route("/health", get(health::health))
    .merge(sandbox_routes)
    .with_state(state)
    .layer(
        ServiceBuilder::new()
            .layer(SetRequestIdLayer::x_request_id(MakeRequestUuid))
            .layer(TraceLayer::new_for_http())
            .layer(TimeoutLayer::new(Duration::from_secs(30)))
            .layer(CompressionLayer::new())
            .layer(CorsLayer::permissive()),
    )

}

การตัดสินใจการออกแบบที่สำคัญบางประการ ได้แก่:

• การรับรองความถูกต้องเป็นทางเลือก: จะเปิดใช้งาน middleware การรับรองความถูกต้องและจำกัดอัตราเฉพาะเมื่อกำหนดค่า auth_callback_url เท่านั้น ในสถานการณ์การพัฒนาภายในเครื่อง ตั้งค่า E2B_API_KEY=dummy ก็ผ่านได้
• เส้นทางเวอร์ชัน V1/V2 อยู่ร่วมกัน: เปิดเผยเส้น
  

  ---

  ⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง

  ☕ สนับสนุนค่ากาแฟทีมงาน

  หากคุณชอบบทความนี้ สามารถสนับสนุนเราได้ผ่าน PromptPay

  

  SCAN TO PAY WITH ANY BANK

  本文来自网络搜集，不代表คลื่นสร้างอนาคต立场，如有侵权，联系删除。转载请注明出处：http://www.itsolotime.com/th/archives/30794