
ستون حاوية على خادم واحد
صندوق معادن عارية واحد يشغل عشرات إلى مئات حاويات Hoody. يجعل KSM و BTRFS dedup التكلفة الإضافية قريبة من الصفر.
أضف `.hoody/crontab` إلى المستودع بجانب مهامك. عندما يُشغّل سكربت النشر حاوية لـ `main` أو `feature/billing-v2` أو أي فرع معاينة، فإنه يرسل PUT لذلك الملف إلى Cron API الخاص بالحاوية الجديدة. الجدول يُشحن مع الفرع — ويختفي معه عند حذفه.
ملف واحد لكل فرع · المسار نفسه في كل مستودع · لا خادم cron مشترك
كل حاوية فرع تُشغّل Hoody Cron. سكربت النشر يقرأ ملف crontab المُودَع ويرسله بـ PUT إلى نقطة نهاية raw-crontab الخاصة بالحاوية الجديدة. الحاوية تُشغّل الجدول الذي يصفه الملف — لا أكثر ولا أقل.
#!/bin/sh
# زوّد حاوية جديدة لهذا الفرع.
BRANCH=$(git branch --show-current)
CTR=$(hoody containers create --from main-snapshot)
# استبدل crontab الحاوية بنسخة المستودع.
curl -X PUT --data-binary @.hoody/crontab \
-H "Content-Type: text/plain" \
https://$CTR-cron-1.hoody.com/users/root/crontab
# تم. جدول الفرع يعيش في حاويته.
echo "deployed $BRANCH → $CTR"# نقطة نهاية raw-crontab لـ Hoody Cron — تستبدل الملف بأكمله بشكل ذرّي.
PUT /users/root/crontab HTTP/1.1
Host: ctr_4d72b9-cron-1.hoody.com
Content-Type: text/plain
0 2 * * * /srv/jobs/billing-rollup-v2.sh
*/15 * * * * /srv/jobs/sync-stripe.py
@hourly curl -fsS http://localhost/healthz
*/5 * * * * /srv/jobs/diff-v1-v2.sh
HTTP/1.1 200 OK
# 200 OK: cron daemon يُعاد تحميله، الجدول نشط في أقل من ثانية.ملف crontab هو بيانات يشحنها الفرع، لا حالة يتذكرها خادم cron. احذف الحاوية، ولن يبقى أي إدخال للتنظيف — الملف ذهب مع القرص.
بمجرد أن يصبح الجدول ملفاً في المستودع، تختفي ثلاث فئات من العمل.
عندما تُغيّر `billing-rollup.sh` إلى الإصدار 2، يصل الجدول الجديد في نفس pull request. المراجع يرى سطر cron إلى جانب السكربت مباشرة. تراجع عن commit واحد ويتراجع الجدول معه.
حاويات الفروع عابرة. عندما تدمج الفرع أو تغلقه، تهدم الحاوية. ملف crontab كان يعيش داخلها، فيختفي الجدول دون حارس — لا يوجد خادم cron مشترك يحتفظ بإدخالات قديمة.
مهمة تجريبية كل ساعة على `experiment/llm-rollups` تعمل في حاويتها الخاصة بنظام ملفاتها الخاص. cron daemon في staging لا يراها أبداً؛ cron daemon في production لا يراها أبداً. لا حاجة لحراسات `if BRANCH_ENV` داخل المهام نفسها.
نموذج "crontab واحد تديره العمليات" القياسي والنموذج المرتبط بالفرع يفشلان في اتجاهين متعاكسين. نفس المهمة، ونصف قطر انفجار مختلف تماماً.
الفرق ليس ميزة — إنه أين يعيش الجدول. ملف يحمله الفرع، مقابل صفّ في جدول مشترك يستعير منه الفرع.
Cron لكل حاوية هو سطح REST حقيقي — ثلاث عائلات من نقاط النهاية، صياغة cron قياسية، عزل كامل لكل مستخدم. الأرقام من مواصفات Cron API، لا معايير مُختلَقة.
لكل حاوية فرع ملف crontab خاص بها لكل مستخدم. أرسل PUT للملف بأكمله، استرجعه بـ GET، استبدله بشكل ذرّي. لا جدول مواعيد مشترك خلف الكواليس.
crontab الخام (GET/PUT)، الإدخالات المُدارة (POST/PATCH/DELETE مع UUIDs و `expires_at`)، والقوائم لكل مستخدم. اختر ما يحتاجه سكربت النشر لديك.
صياغة `min hour day month dow` القياسية بالإضافة إلى الماكروهات: `@hourly`, `@daily`, `@weekly`, `@monthly`, `@yearly`. نفس الصياغة التي يستخدمها `.hoody/crontab` لديك بالفعل.
وفقاً لـ Hoody Cron API: GET/PUT /users/[user]/crontab و POST/PATCH/DELETE /users/[user]/entries على عنوان URL خدمة cron الخاصة بكل حاوية.
الجدول يعيش بجانب الكود الذي يعمل عليه، في الحاوية نفسها، على الفرع نفسه.
ستة أماكن كان جدول cron يعيش فيها، لا واحد منها بجانب الكود. crontab المرتبط بالفرع يجعلها كلها زائدة عن الحاجة.
توقّف عن مزامنة الجداول عبر الأنظمة. أودِع crontab. دع الفرع يحمله.