تراجع. تشعيب. مشاركة. نموذج الحالة تحت كل حاوية.
خمسة أوليات لنظام الملفات وطبقة BTRFS copy-on-write تجعل حالة الحاوية تنجو وتسافر عبر الزمن وتُشارك.
/hoody/storage · /hoody/databases · /ramdisk · /hoody/shares · لقطات BTRFS
/ ├── hoody/ │ ├── storage/ ← persistent, per-container │ ├── databases/ ← concurrent-safe SQLite (FUSE) │ └── shares/ ← inter-container directory mounts ├── ramdisk/ ← RAM-backed, 50% of container memory └── ... ← standard Linux FS (ext4, POSIX)
خريطة نظام الملفات.
لكل مسار قصة استمرارية وتزامن مختلفة. اختيار المسار الصحيح هو التفكير الكامل.
/hoody/storage
مجلد مستمر لكل حاوية. ينجو من إعادة التشغيل؛ اللقطات تلتقطه. مجلد ext4 عادي — لا FUSE، لا أمان تزامن إضافي على ما يوفره تطبيقك.
/hoody/databases
تحميل FUSE. عمليات وحاويات متعددة (نفس الخادم) يمكنها كتابة SQLite بأمان دون «قاعدة البيانات مقفولة». تغيير المسار فقط: انقل الملف من /app/data.db إلى /hoody/databases/data.db. على مستوى المضيف — لا يُنسخ عبر الخوادم.
/ramdisk
tmpfs مدعوم بـ RAM بسرعة 10-20 جيجابايت/ثانية، زمن استجابة أقل من ميكروثانية. سقف 50% من ذاكرة الحاوية.
/hoody/shares
تحميل مجلدات بين الحاويات عبر Storage Shares API. للقراءة فقط أو للقراءة والكتابة، 1 إلى 1 أو على مستوى المشروع. المشاركات عبر الخوادم تستخدم NFS تلقائياً — لا إعداد تحميل. دورة الحياة (قبول / رفض / تحميل / إلغاء) تعيش على /platform/control-plane.
/ (ext4)
نظام ملفات Linux القياسي في كل مكان آخر. POSIX، ext4، دلالات كاملة.
BTRFS تحت الكل
طبقة نسخ عند الكتابة تحت المسارات المدعومة بالقرص. لقطات على مستوى الكتل، إزالة تكرار عبر الحاويات.
نسخ عند الكتابة، على مستوى الكتل، فوري.
BTRFS تخزّن فقط الكتل التي تغيّرت منذ نقطة اللقطة. إنشاء لقطة يضيف علامة في شجرة الـ B+، لا نسخ.
t0 — لقطة A
نظام ملفات الحاوية له كتل a، b، c. اللقطة A تشير إلى الثلاثة.
t1 — الكتلة b تتغير
الكتابة-التعديل تنسخ b إلى b'. الـ b الأصلي لا يزال مُشاراً إليه من اللقطة A. الحاوية ترى الآن a، b'، c.
t2 — لقطة B
اللقطة B تلتقط a، b'، c. A وB يشتركان في a وc. فقط b/b' يتباعدان. الإجمالي: 4 كتل، بلا تكرار.
جارية أو متوقفة — حالة الحاوية تختار نوع اللقطة.
التقط لقطة أثناء التشغيل وستحصل على العمليات والذاكرة وسجل الطرفية وعلامات تبويب المتصفح والاتصالات الشبكية مع نظام الملفات. التقطها وهي متوقفة وستحصل على نظام الملفات فقط. استدعاء API واحد في الحالتين؛ النوع يُحدَّد تلقائياً.
جارية → حية
الحالة الكاملة للجهاز، مجمّدة.
- +نظام الملفات (كل شيء في / بما فيه /hoody/*)
- +العمليات الجارية (PIDs، علاقات الوالد)
- +الذاكرة + تفريغ RAM
- +سجل الطرفية والجلسات المفتوحة
- +علامات تبويب المتصفح ومحتوى العرض النشط
- +حالة اتصال قاعدة البيانات
- +اتصالات الشبكة (sockets، TCP المثبَّتة)
- +الملفات المفتوحة (جداول fd)
- +متغيرات البيئة
متوقفة → بدون حالة
نظام الملفات فقط. الاستعادة = بداية جديدة من نظام الملفات هذا.
- ·نظام الملفات فقط
- ·بلا عمليات — الاستعادة تشغّل حاوية باردة
- ·بلا ذاكرة — بلا تفريغ RAM في اللقطة
- ·بلا حالة شبكة — الاتصالات يجب إعادة إنشائها
— الاستعادة مدمّرة: تستبدل الحالة الحية الحالية. إذا أردت الاحتفاظ بالوضع الحالي، التقط لقطة أولاً.
دع الوكيل يجرّب. احتفظ بزر التراجع.
نماذج اللغة التي تلمس middleware المصادقة أو ترحيل قواعد البيانات أو إعادة الهيكلة الشاملة تستفيد أكثر من نقطة لقطة قبل التشغيل.
بدون لقطات
- 1.الوكيل يعيد هيكلة middleware المصادقة. أول اختبارات الدخان تنجح.
- 2.تدمج وتنشر. كل شيء يبدو جيداً لأيام.
- 3.الجلسات تبدأ في الإسقاط بصمت في الإنتاج.
- 4.تقسيم طلبات الوكيل الأخيرة يستغرق ساعات — التغيير مدفون في فرق كبير.
- 5.التراجع يعني إعادة كل PR وكيل مدموج يدوياً وإعادة النشر.
مع لقطات Hoody
- 1.التقط لقطة قبل تشغيل الوكيل. أعطها اسماً مستعاراً مثل pre-auth-refactor.
- 2.دع الوكيل يعمل. يعدّل الملفات، يعيد تشغيل الخدمات، يشغّل اختبارات الدخان.
- 3.شيء يبدو خاطئاً في الإنتاج بعد أسبوع.
- 4.PATCH /snapshots/pre-auth-refactor — the container restores to the pre-agent state in 5–15s.
- 5.مع استعادة الخدمة من اللقطة، يمكنك التقاط لقطة جديدة من الحالة المعطوبة للتحقيق.
نمط شبكة الأمان هو سبب كل سير عمل بمساعدة الذكاء الاصطناعي — توليد الكود، إعادة هيكلة البنية التحتية.
سير العمل هو رسم بياني التزام للآلات الكاملة.
التقط لقطة قبل تغيير محفوف بالمخاطر. كرّر. إذا كانت النتيجة جيدة، استمر — اللقطة رخيصة وتبقى.
t0 — الخط الأساسي
POST /snapshots — tagged v1.4.0-pre
t1 — عمل محفوف بالمخاطر
وكيل الذكاء الاصطناعي يعيد الهيكلة، ترحيل يعمل، خدمات تعيد التشغيل
t2 — شيء انكسر
اختبارات الدخان تفشل. نحتاج للعودة.
t3 — استعادة
PATCH /snapshots/v1.4.0-pre — 5–15s restore
t4 — مطابق لـ t0
RAM والعمليات ونظام الملفات كلها تطابق t0. بلا انجراف.
PATCH /api/v1/containers/ID/snapshots/v1.4.0-preعندما يكون SSD هو عنق الزجاجة، /ramdisk هو الجواب.
نصف ذاكرة الحاوية، متاحة كـ /ramdisk، تُخصَّص عند الطلب. موجودة عند الاستخدام، غير محسوبة عند الإلغاء.
⚠ استخدام /ramdisk يُحسب ضد ذاكرة الحاوية. إذا كانت الحاوية 4 جيجابايت وتمسك /ramdisk 3 جيجابايت، تبقى جيجابايت واحد لكل شيء آخر.
خمس استراتيجيات لقطات تستخدمها الفرق فعلاً.
اختر واحدة ويصبح انضباط حالتك قراراً بسطر واحد. معظم الفرق تشغّل اثنتين.
1 · أمان ما قبل العملية
التقط لقطة قبل أي شيء مدمّر: ترحيل، توليد كود الذكاء الاصطناعي، الاستجابة للحوادث، hotfix يدوي.
2 · معالم ذات إصدارات
اسمِ اللقطات عند نقاط الإصدار — v1.4.0، v1.5.0-rc. انتهاء الصلاحية بعد أسابيع. تراجع فوري لأي اسم.
3 · يومي تلقائي
لقطة Cron مع انتهاء صلاحية تلقائي = محفوظات تُقطَّص ذاتياً. سبعة أيام من الأمس، ثلاثون يوماً من آخر أسبوع.
4 · تفريع بأسلوب Git
لقطة + نسخة حاوية = مسار بديل على مشروع أو خادم مختلف. جرّب مساراً محفوفاً بالمخاطر في موازٍ.
5 · قوالب الصورة الذهبية
زرع لقطة، نسخ منها لكل حاوية مطور جديدة. التأهيل يصبح استدعاء POST واحد.
مكافأة · الحفظ الجنائي
عندما يتعرض الإنتاج للاختراق: التقط لقطة للحالة المخترقة للتحقيق، استعِد الإنتاج من اللقطة الأخيرة السليمة.
ما كنت ستخيط معاً.
التراجع، الالتقاط الحي، SQLite آمن للتزامن، مشاركة بين الحاويات، scratch مدعوم بـ RAM — كل هذا مدمج.
| المشكلة | Hoody البيانات والحالة | الحزمة التقليدية |
|---|---|---|
| التراجع بجهاز كامل | PATCH /containers/ID/snapshots/NAME | Tarball + إعادة نشر يدوي + التمني |
| التقاط حالة الذاكرة الجارية | Stateful snapshot (automatic) | VMware suspend + أدوات مخصصة |
| مشاركة مجلد بين الحاويات | /hoody/shares + Shares API | تشغيل خادم NFS أو SMB بنفسك |
| كتابات SQLite متزامنة | /hoody/databases (FUSE mount) | إعادة كتابة طبقة بياناتك على Postgres |
| مساحة scratch مدعومة بـ RAM | /ramdisk (ceiling 50% memory) | tmpfs + ulimits دقيقة |
| إزالة تكرار التخزين عبر حاويات مماثلة | BTRFS copy-on-write (built in) | rsync --link-dest، سياسة يدوية |
| نسخ الحالة بين الخوادم | POST /containers/ID/copy + /sync | حلقات rsync DIY + إعادة تشغيل الخدمة |
إذا كنت بالفعل على نظام لقطات VM مُدار لعبء عمل محدد، ابقَ هناك لذلك العبء. نموذج حالة Hoody يستحق مكانه حين تكون العملية التي تريدها فعلاً سفراً زمنياً على مستوى الحاوية.
حالتك بالفعل رسم بياني التزام. تعلّم كيف تستخدمه.
نظام الملفات موجود بالفعل. اللقطات موجودة بالفعل. التحميلات موجودة بالفعل. أنشئ جهازاً وجرّب.
انظر أيضاً — /platform/control-plane لـ APIs اللقطات والنسخ/المزامنة، /kit/files لخلفيات السحابة.