אירוח עצמי של Dormice עבור ארגזי חול לסוכני AI

מהו Dormice ומה הוא אינו

Dormice הוא ארגז חול (sandbox) לסוכנים (agents) באירוח עצמי: daemon אחד על שרת VPS בבעלותכם, שאליו קוד הסוכן שלכם פונה באמצעות HTTP כדי להריץ קוד לא מהימן בתוך מכולה מבודדת. התוכנית שלכם מבקשת ארגז חול לפי שם, מקבלת בחזרה את אותו ארגז חול ללא קשר למצבו הקודם, מריצה בתוכו פקודה וקוראת את הפלט. ארגז החול הוא משאב תכנותי, לא מכונה שאליה מתחברים ב-SSH.

זהו מודל שונה ממתן מחשב שלם לסוכן. מכונה וירטואלית חד-פעמית עבור סוכן קידוד היא סביבה שאליה מתחברים ב-SSH, מאפשרים לסוכן להרוס אותה, ואז מוחקים אותה. Dormice נמצא רמה אחת מתחת: זהו API לביצוע פקודות שהתוכנית שלכם קוראת לו כאשר כבר יש לה קוד והיא זקוקה למקום בטוח להרצתו. השתמשו במכונה וירטואלית חד-פעמית כאשר יחידת העבודה היא מחשב שלם. השתמשו ב-Dormice כאשר יחידת העבודה היא קריאת exec בודדת, ואתם מעוניינים לבצע מאות כאלו ביום מבלי להקים מאות מכונות וירטואליות.

הפרויקט מגדיר את עצמו כתואם E2B. E2B הוא שירות ארגז חול מנוהל שספריות הלקוח שלו כבר מוטמעות בפריימוורקים רבים של סוכנים. Dormice מגיש את אותו פרוטוקול תחת קידומות URL משלו, כך שיישום שנכתב מול חבילת ה-e2b הרשמית ימשיך לעבוד כאשר תפנו אותו לשרת שלכם. קוד היישום אינו משתנה. רק שני כתובות URL וקידומת אחת של מפתח API משתנים.

מה המשמעות של "ה-SQLite של ארגזי החול לסוכנים" בפועל

SQLite הוא מסד נתונים שמשלבים בתוך היישום במקום להפעיל כשירות נפרד, ו-Dormice שואלת את ההשוואה הזו ישירות. תהליך רקע (daemon) אחד, קובץ SQLite אחד עבור הרישום (ledger), ופורט TCP אחד. ללא Kubernetes, ללא מסד נתונים נפרד וללא מתזמן. ה-daemon נועל קובץ לצד ה-ledger שלו ומסרב לעלות אם ה-ledger והמכונה שבה הוא נמצא אינם תואמים, כך שפיצול מוח (split brain) לא יכול להתרחש בשקט. התכנון מבוסס על מכונה אחת. אם אתם זקוקים לצי שרתים על פני מארחים רבים, ה-README מנחה אתכם בבירור לבחור פתרון אחר, וכדאי להישמע להנחיה זו.

החלק השני של הרעיון נוגע לעלות. ארגז חול מנוהל (hosted sandbox) מחייב תשלום על כל שנייה של פעילות, ולכן ארגזי חול כאלו מתוכננים להיות חד-פעמיים. Dormice רץ על חומרה שאתם כבר משלמים עליה, לכן ארגזי החול שלו הם קבועים והופכים לזולים יותר ככל שהם נשארים במצב סטטי. ארגז חול "מתקרר" בשלבים: פעיל, קפוא (frozen), עצור, וארכיוני. כל פעולת גישה (acquire) מחזירה אותו למעלה מכל שלב שאליו הגיע.

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

[
  {
    "label": "Active, holding 1 GiB",
    "resident_memory_mib": 1024,
    "wake_ms": 0
  },
  {
    "label": "Frozen",
    "resident_memory_mib": 5,
    "wake_ms": 50
  }
]

ארגז חול במצב המתנה המחזיק 1024 MiB של זיכרון יורד ל-5 MiB בזיכרון ה-resident לאחר הקפאה, וחוזר לפעילות תוך כ-50 ms. תהליכים מושהים ומתחדשים באותו מצב, כך שסוכן בעל זמן חיים ארוך שומר על מצב ה-shell שלו ועל עבודה שלא הושלמה לאורך תהליך ההקפאה. בצעו שכפול של תרחיש זה על המארח שלכם לפני שתתכננו את קיבולת המערכת סביבו.

דרישות קדם להתקנה על המארח

המארח חייב להריץ Ubuntu או Debian בארכיטקטורת x86_64, והמתקין דורש הרשאות root. ה-daemon שומר על הרשאות root בזמן הריצה כיוון שהוא מבצע loop mounts וכותב ל-cgroups.

סביבות מבודדות (sandboxes) רצות תחת Docker עם gVisor (סביבת הרצה של מכולות המציבה ליבת userspace בין המכולה לבין ליבת המארח), אשר מספקת את ה-runsc שכל sandbox משתמש בו. ה-daemon דורש Node 22 ומעלה, והמתקין מביא עמו עותק עצמאי, כך שגרסת ה-Node המותקנת במערכת שלכם אינה מושפעת.

חובה להגדיר Swap, וערך ה-vm.swappiness חייב להיות 100. זו אינה המלצת כוונון, אלא דרישה תפקודית. פעולת ה-freezing מתבצעת על ידי דחיפת הזיכרון של sandbox לא פעיל אל ה-swap; מכיוון ש-gVisor מחזיק את זיכרון ה-sandbox כזיכרון משותף (shared memory), הליבה לא תבצע swap לזיכרון משותף בערך ה-swappiness המוגדר כברירת מחדל. הפרויקט מדד 0 בתים שפונו בערך ברירת המחדל, לעומת 99.5 אחוזים שפונו בערך 100. בדקו את הערך שהליבה משתמשת בו בפועל, שכן תמונות מערכת מסוימות בענן כוללות את vm.swappiness = 0 בקובץ שלעולם לא תחשבו לקרוא.

sysctl vm.swappiness
swapon --show

הפקודה sysctl vm.swappiness צריכה להדפיס vm.swappiness = 100, והפקודה swapon --show צריכה להציג קובץ swap. אם ה-swappiness מציג 0, כל פעולת freeze תהיה חסרת משמעות ותשאיר אתכם משלמים על מלוא צריכת הזיכרון עבור כל sandbox לא פעיל.

התקנת Dormice על Ubuntu

התקנה המתועדת מבוצעת באמצעות צינור (pipe) אחד לתוך bash:

curl -fsSL https://raw.githubusercontent.com/BitMiracle-AI/Dormice/main/deploy/install.sh | bash

הורידו את הסקריפט ועיינו בו לפני ההרצה. סקריפט זה רץ כ-root ומבצע שינויים במערכת המארחת: הוא מתקין את Docker אם הוא חסר, מוריד את gVisor ואת Caddy עם אימות checksum, יוצר swapfile, כותב יחידות systemd ומוסיף חוקי firewall.

curl -fsSL https://raw.githubusercontent.com/BitMiracle-AI/Dormice/main/deploy/install.sh -o dormice-install.sh
less dormice-install.sh
sudo bash dormice-install.sh --swap-gb 8

המשתנה --swap-gb קובע את גודל ה-swapfile, כאשר ברירת המחדל היא 16, כמות משמעותית של שטח דיסק בשרת VPS קטן. המשתנה --mirror cn מעביר את ההורדות לשרתי מראה הנגישים מסין היבשתית. הרצה חוזרת של המתקין מעדכנת את הקוד ומתקנת סטיות בתצורה, והיא לעולם אינה מחליפה את ה-API token שלכם.

הקוד מותקן ב-/opt/dormice, התצורה ב-/etc/dormice/env, נתוני ה-sandbox ב-/var/lib/dormice, והפקודות dormice ו-dor נמצאות ב-/usr/local/bin. המתקין מייצר את ה-API token במהלך ההתקנה וכותב אותו ל-/etc/dormice/env עם הרשאות 600.

לא קיימת גרסה מתויגת (tagged release) להתקנה. נכון ל-4 באוגוסט 2026, המאגר אינו כולל תגיות git או גרסאות GitHub, לכן המתקין מבצע clone ל-main ואתם מקבלים את הקוד העדכני ביותר לאותו בוקר. קיבוע גרסה (pinning) מחייב לכן תיעוד של ה-commit הספציפי שהותקן.

git -C /opt/dormice rev-parse HEAD

שמרו את ה-hash הזה יחד עם הערות הפריסה שלכם. כאשר עדכון גורם לתקלה, ה-commit הזה הוא הדרך היחידה שלכם לחזור לאחור, כיוון שאין מספר גרסה שניתן לבקש.

המתקין מסיים בהרצת dor doctor, בדיקת מארח לקריאה בלבד שמפעילה מכולות gVisor אמיתיות כדי לוודא שסביבת הריצה תקינה, במקום להסתמך על רשימת חבילות. הריצו פקודה זו שוב בכל פעם שה-daemon אינו מתפקד כראוי.

sudo dor doctor
systemctl is-active dormice

הפקודה systemctl is-active dormice אמורה להדפיס active. אם היא מדפיסה failed, הקובץ journalctl -u dormice -n 50 מכיל את הסיבה לכך; כשל בהפעלה נובע בדרך כלל מדרישות קדם של swap או gVisor ולא מה-daemon עצמו.

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

sudo ss -lntp

ה-daemon מאזין ב-127.0.0.1:3676 ואין הגדרה לשינוי התנהגות זו, כחלק מהתכנון. גישה אליו מהמחשב האישי שלכם היא פעולה מכוונת, והדרך הפשוטה ביותר היא באמצעות מנהרת SSH.

ssh -L 3676:127.0.0.1:3676 root@your-server

כאשר המנהרה פתוחה, http://127.0.0.1:3676/console במחשב שלכם הוא ממשק הניהול. היכנסו עם ה-token פעם אחת והוא יהפוך ל-httpOnly session cookie, כך שה-token עצמו לעולם לא נשמר במקום שבו הדף יכול לקרוא אותו. דף ה-Connect שם מציג קטעי קוד להעתקה עבור הלקוח, המופנים כבר לנקודת הקצה שלכם.

יצירת ארגז חול (sandbox) והרצת קוד בתוכו

פעולה אחת יוצרת ארגז חול: acquire. פעולה זו היא אידמפוטנטית, לכן אותו מפתח תמיד יחזיר את אותו ארגז חול, תוך יצירה, השכמה, הפעלה או שחזור שלו לפי הצורך. כל פועל אחר יחזיר שגיאת 404 עבור מפתח שטרם הוכר. ב־CLI של dor אין פועל acquire, לכן ארגז החול הראשון שלכם ייווצר דרך ה-console או דרך ספריית לקוח.

השימוש ב-console הוא הדרך המהירה ביותר. פתחו את /console דרך ה-tunnel וצרו ארגז חול בשם my-agent. לאחר מכן, ה-CLI יעבוד מולו.

sudo grep DORMICE_API_TOKEN /etc/dormice/env
export DORMICE_ENDPOINT=http://127.0.0.1:3676
export DORMICE_API_TOKEN=paste-the-value-here
dor sandbox ls
dor sandbox exec my-agent 'python3 --version'

הפקודה dor sandbox ls מציגה רשימה של כל ארגזי החול ומצב מחזור החיים שלהם; כך ניתן לעקוב אחר המעבר של ארגז חול ממצב פעיל (active) למצב קפוא (frozen). הפקודה dor sandbox exec מדפיסה גרסת Python 3.12, כיוון שה-image הבסיסי הוא Ubuntu 24.04 הכולל מראש את Python 3.12, Node 24, git ו-ripgrep. שגיאת אימות (authentication error) מעידה על כך ששורת ה-token שהעתקתם כללה גם את שם המשתנה.

העברת קבצים מתבצעת באמצעות dor sandbox push my-agent ./script.py, המציב אותם ב-/home/user/script.py, בעוד ש-dor sandbox pull my-agent notes.txt מחזיר קובץ חזרה. פקודות הקבצים המובנות מוגבלות ל-16 MiB לקובץ, בעוד ש-file surface של E2B תומך ב-streaming ומאפשר למכסת הדיסק של ארגז החול להיות המגבלה היחידה.

מחיקה (destroying) היא הפעולה היחידה שגורמת לאובדן נתונים, והיא גם דוגמה טובה לגילו של הפרויקט: ה-README הראשי וה-agent skill המצורף מתעדים שניהם את dor sandbox destroy <key>, בעוד שה-README של חבילת ה-CLI מתעד את dor sandbox release <key>. הריצו את dor sandbox --help על ה-build שלכם והסתמכו עליו.

הפניית קוד E2B קיים לשרת שלכם

זו הסיבה לכך שזה חשוב. חבילת ה-e2b הרשמית מ-npm, ללא שינויים, מתקשרת עם Dormice. הריצו זאת מהמחשב הנייד שלכם כשה-SSH tunnel פתוח, כך ששום דבר חדש לא יאזין בשרת.

npm init -y
npm i e2b tsx

import { Sandbox } from 'e2b';

const sbx = await Sandbox.create({
  apiKey: `e2b_${process.env.DORMICE_API_TOKEN}`,
  apiUrl: 'http://127.0.0.1:3676/e2b/api',
  sandboxUrl: 'http://127.0.0.1:3676/e2b/envd',
});

const result = await sbx.commands.run('python3 -c "print(6 * 7)"');
console.log(result.exitCode, result.stdout);

await sbx.kill();

DORMICE_API_TOKEN=paste-the-value-here npx tsx index.ts

הרצה תקינה תציג קוד יציאה 0 ו-42. ה-API key הוא ה-token שלכם מ-Dormice עם קידומת e2b_ לפניו, שכן זהו הפורמט ששכבת התאימות מצפה לו.

שכבת התאימות אינה רק ממשק ריק. הזרמת stdout ו-stderr, פקודות ברקע, PTY אינטראקטיבי, כתובות URL חתומות להעלאה והורדה, ניטור ספריות ו-port proxy – כולם מופעלים דרך החבילה הרשמית מול Docker ו-gVisor אמיתיים על ידי חבילת הבדיקות מקצה-לקצה של הפרויקט. ישנם כמה הבדלים שחשוב להכיר לפני העברת עומסי עבודה אמיתיים:

• בניית תבניות (Template builds) אינה ממומשת. תבנית היא image של Docker שאתם בונים בעצמכם ורושמים באמצעות dor template add, ו-Sandbox.create('name') פותר את השם שלה. שם שלא נרשם יחזיר שגיאת 404 במקום לבצע פעולה מדומה.
• סביבות מבודדות (sandboxes) שנוצרות דרך הממשק של E2B מקבלות דדליינים אמיתיים, כיוון שהסמנטיקה של E2B מחייבת זאת. דדליינים לעולם אינם נאכפים על סביבות שנוצרות דרך ה-API המקורי.
• סביבה מוקפאת (frozen sandbox) שומרת על התהליכים שלה ומחדשת אותם מאותה נקודה, לכן פעולות השהיה (pause) וחידוש (resume) כאן אינן דומות לעצירה והפעלה מחדש (cold start) שאולי אתם רגילים אליהן.

מה ה-sandbox עוצר, ומה לא

gVisor מיירט את קריאות המערכת של ה-container במרחב המשתמש (userspace) ומטפל בהן בעצמו, כך שהקוד שבתוך ה-sandbox אינו מתקשר ישירות עם ה-kernel של המארח. בתוך ה-sandbox, הכל רץ כמשתמש ללא הרשאות, uid 1000. שילוב זה מטפל במקרים רגילים: סקריפט שנוצר ומריץ rm -rf /, ממלא את הדיסק, או מבצע fork עד לקריסת המערכת, פוגע רק ב-sandbox של עצמו ונעצר שם.

להלן מה שהוא אינו עוצר. כל אחד מאלו הוא באחריותך.

• ל-sandbox יש גישה לרשת חיצונית. קוד שנוצר יכול להוריד כל מה שירצה ולשלוח החוצה כל מה שימצא. הקשחת הרשת של ה-installer מכסה שני דברים ספציפיים: היא חוסמת תעבורת container לשירות ה-metadata של הענן בכתובת 169.254.0.0/16, המקום שבו ספק הענן מספק אישורי גישה לכל מי שיכול להגיע אליו, והיא מכבה תעבורה בין-containers באמצעות "icc": false בתוך ה-daemon.json של Docker. שום דבר אחר אינו חסום. קרא את sudo iptables -S DOCKER-USER והוסף חוקי DROP משלך עבור טווחי כתובות פרטיים שאין ל-sandbox שום סיבה להגיע אליהם.
• Docker מחדיר חוקים משלו לפני ה-firewall שלך, כך שפורט של container שפורסם יכול להגיב מהאינטרנט גם אם ufw מציג אותו כסגור. קרא את איך Docker מפרסם פורטים מעבר ל-ufw ואת יסודות ה-firewall מסוג ufw עבור VPS לפני שאתה חושף משהו במארח זה.
• gVisor הוא kernel במרחב המשתמש, לא hypervisor. זו פשרה מכוונת, כיוון שביצוע הקפאה (freezing) מחייב שה-sandboxes יהיו תהליכים, ודרישה ל-KVM הייתה מונעת את התקנת המערכת במקומות רבים. אם מודל האיומים שלך דורש וירטואליזציה ברמת החומרה, השתמש בבידוד מסוג Firecracker וקבל את העלות התפעולית הנלווית לכך.
• ה-API token הוא כל גבול האבטחה בצד הלקוח. כל מי שמחזיק ב-DORMICE_API_TOKEN יכול ליצור, לקרוא ולהשמיד כל sandbox במכונה. תן לתהליך ה-agent משתמש בעל הרשאות מינימליות ב-VPS והתייחס ל-token כפי שאתה מתייחס ל-SSH key. ההרגלים מ-הרצת Claude Code בצורה בטוחה על VPS תקפים ישירות גם כאן.

ה-daemon עצמו רץ כ-root על המארח שלך. gVisor מגן על המארח מפני הקוד שבתוך ה-sandbox, אך שום דבר לא מגן על המארח מפני ה-daemon או מפני מי שמחזיק ב-token שלו. לכן, המכונה שמריצה את Dormice צריכה להיות מכונה שמבצעת רק את המשימה הזו. אם ה-agent שלך ניגש גם לכלים דרך MCP (model context protocol), שמור את שרתי ה-MCP על VPS נפרד מאותה סיבה.

כמה סביבות sandbox נכנסות ב-4 GB וב-8 GB?

שני גורמים צורכים זיכרון: בסיס המערכת של המארח, וסט העבודה של כל sandbox שפעיל כרגע. הקצו כ-1 GB עבור Ubuntu, Docker וה-daemon, ולאחר מכן חלקו את היתרה בכמות הזיכרון שסביבת sandbox אחת באמת צורכת. סביבת sandbox שמריצה סקריפט Python שקורא כמה קבצים צורכת בין 200 ל-300 MiB. סביבה שמריצה מהדר או חבילת בדיקות מלאה יכולה לעבור את ה-gibibyte.

[
  {
    "host": "4 GB VPS",
    "active_at_512_mib": 6,
    "active_at_1_gib": 3,
    "frozen_on_16gb_swap": 16
  },
  {
    "host": "8 GB VPS",
    "active_at_512_mib": 14,
    "active_at_1_gib": 7,
    "frozen_on_16gb_swap": 16
  }
]

שרת VPS עם 4 GB יכול להחזיק כ-6 סביבות sandbox פעילות בו-זמנית אם כל אחת צורכת 512 MiB, או 3 אם כל אחת צורכת gibibyte מלא. שרת VPS עם 8 GB מעלה את המספרים ל-14 ו-7. אלו הם גבולות עליונים לעבודה בו-זמנית, והם מבוססים על חישוב אריתמטי ולא על מדד ביצועים, לכן יש לנטר את free -m בזמן שהעומס שלכם רץ.

סביבות sandbox קפואות (frozen) מוגבלות על ידי ה-swap ולא על ידי ה-RAM, וזו כל מטרת התכנון. סביבת sandbox קפואה שהחזיקה gibibyte שומרת בערך כמות כזו ב-swap וכמעט שום דבר בזיכרון ה-resident, לכן קובץ ה-swap המוגדר כברירת מחדל על ידי המתקין בגודל 16 GB יכול להכיל כ-16 מהן. מעבר לכך, הן צריכות להגיע למצב עצירה (stopped), שבו הן תופסות מקום בדיסק בלבד. הדיסק הוא המגבלה האמיתית לטווח ארוך כאן: כל sandbox שומרת את מערכת הקבצים שלה, וכמה עשרות סוכנים שכל אחד מהם נושא ספריית node_modules ימלאו נפח אחסון קטן הרבה לפני שהזיכרון יהפוך לבעיה מעניינת.

הקפאה, עצירה, ארכוב: כפתורי מחזור החיים

ברירת המחדל היא הקפאה לאחר 10 דקות של חוסר פעילות, עצירה לאחר 3 ימים, וארכוב לאחר 7 ימים כאשר הארכוב מוגדר. הגדרת stopAfterSeconds לערך null תעניק לכם סוכן תושב (resident agent): הוא עשוי לקפוא בזמן חוסר פעילות, אך לעולם לא יבצע cold start.

ארכוב הוא אופציונלי, וה-daemon מדווח על כך בשקיפות. הגדירו את ארבעת משתני ה-DORMICE_S3_*, והדיסק של ה-sandbox העצור יידחס באמצעות tar ו-zstd, יישלח לכל bucket תואם S3, וישוחרר מקומית. ה-bucket הזה יכול להיות bucket של MinIO שאתם מארחים בעצמכם על מכונה אחרת שלכם. השאירו את המשתנים ללא הגדרה, וה-sandboxes יישארו במצב עצור לצמיתות; מדיניות המבקשת לבצע ארכוב תידחה במקום שתתעלם בשקט. שחזורים הם גלויים ולא שקטים: פעולת ה-acquire הבאה תשיב מיד עם סטטוס של שחזור וערך התקדמות, ולאחר מכן תעבור למצב ready ברגע שהדיסק יחזור.

האם כדאי להסתמך על זה כבר עכשיו?

תשובה ישירה: לא עבור שום דבר שאינכם יכולים לבנות מחדש. ה-commit הראשון במאגר מתוארך ל-8 ביולי 2026. נכון ל-4 באוגוסט 2026, הפרויקט מציג 446 כוכבים, 37 פיצולים (forks), רישיון Apache-2.0, וללא אף גרסה מתויגת (tagged release). שורת הסטטוס ב-README עצמו מציינת ששום דבר שם אינו מוכן לסביבת ייצור.

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

מה שהופך את הסיכון לנסבל הוא התאימות ל-E2B. היישום שלכם מדבר עם פרוטוקול שיש מאחוריו מימוש מאוחסן, כך שאם Dormice ייתקע, תוכלו לשנות שני כתובות URL ולהמשיך לעבוד. כתבו את ה-agent שלכם מול הממשק של E2B במקום מול ה-API המקורי, וכך תשמרו לעצמכם את נתיב היציאה הזה. חבילת ה-@dormice/sdk המקורית גם היא אינה נמצאת ב-npm עדיין, לכן שימוש בה מחייב בנייה מהמאגר, וזו סיבה שנייה להתחיל עם הנתיב התואם.

הריצו את זה במקום שבו אתם יכולים להרשות לעצמכם לאבד את המידע. בנו את ה-host מחדש מתוך סקריפט, הרחיקו את ה-token מכל prompt ומכל commit, ומשכו כל דבר ששווה לשמור מתוך ה-sandboxes לפי לוח זמני גיבוי משלכם.

FAQ

האם Dormice מוכן לשימוש בסביבת ייצור?

לא, והפרויקט מצהיר על כך בעצמו. שורת הסטטוס ב-README מציינת ששום דבר שם אינו מוכן עדיין לסביבת ייצור, ונכון ל-4 באוגוסט 2026 המאגר קיים כארבעה שבועות בלבד ללא תגיות git וללא releases, כך שאין מספר גרסה שאפשר לקבע. תוכנית ההתקנה משכפלת (clones) את הענף main, מה שאומר שכל הרצה מספקת לך את ה-commit העדכני ביותר. תעדו את git -C /opt/dormice rev-parse HEAD לאחר כל התקנה, ושמרו כל מידע בעל ערך מחוץ ל-sandboxes.

במה שונה Dormice ממתן VM זמני לסוכן שלי?

VM זמני הוא מכונה עם SSH שיוצרים עבור סשן ומוחקים לאחר מכן. Dormice הוא API לביצוע (execution): התוכנית שלכם קוראת ל-acquire, לאחר מכן ל-exec, ומקבלת בחזרה stdout וקוד יציאה, ללא סשן shell בתווך. ה-VM מתאים לאדם או לסוכן שרוצה מחשב שלם לזמן מה. Dormice מתאים ליישום שמריץ קוד שנוצר פעמים רבות ביום ואינו רוצה את התקורה של הקמה ופירוק מכונה סביב כל הרצה.

האם ה-SDK הרשמי של E2B באמת עובד ללא שינויי קוד?

כן, עם שינויי הגדרה. כוונו את apiUrl ואת sandboxUrl אל /e2b/api ואל /e2b/envd ב-daemon שלכם, והעבירו את ה-token של Dormice עם תחילית e2b_ בתור ה-API key. הרצת פקודות, סשני PTY, העברת קבצים, כתובות URL חתומות ו-port proxy – כולם מכוסים על ידי חבילת הבדיקות מקצה לקצה של הפרויקט שרצה דרך החבילה הרשמית. בניית תבניות (templates) היא הפער הבולט: e2b template build אינו ממומש, לכן תבנית היא image של Docker שאתם בונים ורושמים באמצעות dor template add.

כמה sandboxes נכנסים ב-VPS של 4 GB?

בערך 6 פעילים בו-זמנית אם כל sandbox צורך 512 MiB, או 3 אם כל אחד צורך גיביבייט מלא, לאחר שמשריינים בערך 1 GB עבור מערכת ההפעלה, Docker וה-daemon. ה-sandboxes הקפואים (frozen) מוגבלים על ידי ה-swap במקום זאת, לכן קובץ ה-swap המוגדר כברירת מחדל בהתקנה בגודל 16 GB מאחסן בערך 16 sandboxes שכל אחד מהם תפס גיביבייט. מדדו את הצריכה שלכם עם free -m תחת עומס אמיתי, כיוון ש-sandbox שמריץ חבילת בדיקות צורך פי כמה מאשר אחד שמריץ סקריפט קטן.

מדוע Dormice דורש ש-vm.swappiness יוגדר ל-100?

הקפאת sandbox משמעותה דחיקת הזיכרון הלא פעיל שלו אל ה-swap. gVisor מחזיק את זיכרון ה-sandbox כזיכרון משותף (shared memory), וליבת ה-Linux לא תבצע swap לזיכרון משותף בערך ה-swappiness המוגדר כברירת מחדל. לכן, בערך ברירת המחדל, הקפאה לא מפנה דבר וה-sandbox ממשיך לצרוך זיכרון מלא. הפרויקט מדד 0 בתים שפונו בערך ברירת המחדל ו-99.5 אחוזים שפונו בערך 100. בדקו את הערך האפקטיבי עם sysctl vm.swappiness במקום לקרוא קובצי הגדרה, כיוון שחלק מה-images בענן מגיעים עם ערך של 0.