
ستون حاوية على خادم واحد
صندوق معادن عارية واحد يشغل عشرات إلى مئات حاويات Hoody. يجعل KSM و BTRFS dedup التكلفة الإضافية قريبة من الصفر.
تتيح SaaS الخاصّة بك لكلّ عميل جدولة توليد تقاريره. التصميم الساذج: مُجدوِل واحد مشترك، معرّف العميل في حمولة المهمّة، أصابع متشابكة لئلّا يجوّع أحدهم الآخر. تصميم Hoody يمنح كلّ مستأجر حاويته الخاصّة وخدمة hoody-cron الخاصّة به.
Three lifecycle states, one HTTP API. PROVISION adds entries, cron ticks run them, DELETE suspends. Each tenant's cron lives in its own container — no shared queue, no noisy-neighbor risk.
كلّ حاوية عميل تكشف API الـ HTTP لـ hoody-cron. لتحديد جدوله، تستبدل crontab بـ PUT واحد. لا طابور مشترك، لا مسار أولويّة، لا إعداد مُجدوِل تعيد نشره.
# POST managed entry for acme-corp tenant
POST acme-cron.hoody.com/users/root/entries
Content-Type: application/json
{
"schedule": "0 9 * * *",
"command": "/usr/local/bin/digest.sh",
"comment": "daily digest",
"enabled": true
}HTTP/1.1 201 Created
Content-Type: application/json
{
"id": "7d3f2a1b-8c4e-4f9a-b2d5",
"schedule": "0 9 * * *",
"schedule_human": "At 09:00",
"enabled": true,
"user": "root"
}تستبدل النقطة crontab بأكمله ذرّيّاً. تُعاد القيود المحذوفة في الردّ ليتمكّن مستوى التحكّم لديك من تدقيق الانحراف. cron كلّ مستأجر يعيش داخل حاويته الخاصّة؛ لا شيء من جدول acme-corp مرئيّ لـ globex-saas، ومهمّة هاربة في حاوية لا يمكنها تجويع المُجدوِل في أخرى.
ثلاث خصائص تنبثق من التصميم مجّاناً، لأنّ العزل هو الأساس، لا ميزة كتبتها.
When initech-inc's scrape.js hangs, acme-corp's 9am digest still fires. Different crontabs, different process trees, different filesystems.
POST a new entry and the tenant's hoody-cron service picks it up immediately. No central scheduler to reload, no broadcast to send.
When globex-saas asks why their 6pm rollup ran twice, you read one container's log — not a shared scheduler grep across nine machines.
ثلاثة محاور يفرض فيها التصميم القديم ضرائب على فريقك، ولا يفعل تصميم Hoody.
العمود القديم هو ما يكتبه كلّ فريق أوّل مرّة يشحن جدولة متعدّدة المستأجرين. العمود الجديد هو ما تشحنه حين تمنحك المنصّة لكلّ مستأجر حاويته افتراضيّاً.
ما يفعله صندوق معدن عارٍ واحد من Hoody حين يحصل كلّ عميل على crontab الخاصّ به.
ستّون حاوية عميل على عقدة معدن عارٍ واحدة، لكلّ منها خدمة hoody-cron تعمل. لا مُجدوِل مشترك يُشكّل عنق الزجاجة.
من طلب PUT حتى أوّل نبضة من الجدول الجديد، مُلاحظة عبر أسطول من 60 حاوية على عقدة 64-core نموذجيّة.
حرفيّاً لا يوجد طابور مشترك أو مسار أولويّة أو خيط مُجدوِل يتنافس عليه مستأجران. العزل هو الأساس.
أرقام السعة قيم نموذجيّة مُلاحظة على عقدة معدن عارٍ 64-core / 256GB تعمل بكثافة حاويات Hoody القياسيّة. السعة الفعليّة تتوقّف على ميزانيّات CPU والذاكرة لكلّ مستأجر وعلى ما تفعله كلّ مهمّة cron. الصفر في الطوابير العابرة للمستأجرين بنيويّ، ليس قياساً.
cron عميل لا يستطيع تجويع cron عميل آخر لأنّهما ليسا على نفس crontab.
البِنى التي تشيّدها الفرق لمشاركة crontab واحد بين المستأجرين. Hoody يضع كلّ مستأجر في crontab الخاصّ به — لا موجّه، لا طابور إنصاف، لا جار مزعج.
كفّ عن كتابة tenant_id في كلّ مكان. امنح كلّ عميل حاويته الخاصّة ودع cron يفعل ما يفعله cron دائماً، في عزلة.