ستون حاوية على خادم واحد
صندوق معادن عارية واحد يشغل عشرات إلى مئات حاويات Hoody. يجعل KSM و BTRFS dedup التكلفة الإضافية قريبة من الصفر.
الحاويات·اللقطات
النوعمفتوحالمرحلةأسطولمستوى الصعوبةمعتدلالمهمةتحسين التكلفةلDevOps والبنية التحتيةلفرق التطويرالخدماتPipeالخدماتالحاوياتلماذا HoodyHTTP-nativeلماذا Hoodyاقتصاديات الحاوية
النوعمفتوحالمرحلةأسطولمستوى الصعوبةمعتدلالمهمةتحسين التكلفةلDevOps والبنية التحتيةلفرق التطويرالخدماتPipeالخدماتالحاوياتلماذا HoodyHTTP-nativeلماذا Hoodyاقتصاديات الحاوية
use-cases / a-ci-cache-thats-just-two-curl-commands / hero
PIPE · CI · تحسين تكلفة
ذاكرة مؤقّتة لـ CI ليست سوى أمرَي curl
أوّل مهمّة في خطّ الأنابيب تضع node_modules في tar وتُمرِّرها إلى رابط Hoody. عشرون مهمّة لاحقة تطلب نفس الرابط وتفكّ tar. مع ?n=20 المُنتِج ينتظر اتّصال كل العشرين عاملاً، ثم يبثّ مرّة واحدة — مُتفرِّعاً إلى كلّهم. لا دلو S3، لا cache action، لا فاتورة خروج.
ci · job-build
$tarcnode_modules|zstd|curl -T -hoody.com/pipe/cache
ينتظر 20 مستقبِلاً · الرفع محتجز
pipe/cache?n=20
800 ميجابايت · يُبثّ مرّة واحدةci · عمّال الاختبار
20 / 20 متّصلونjob-01
curl … | zstd -d | tar xjob-02
curl … | zstd -d | tar xjob-03
curl … | zstd -d | tar xjob-04
curl … | zstd -d | tar xjob-05
curl … | zstd -d | tar xjob-06
curl … | zstd -d | tar xjob-07
curl … | zstd -d | tar xjob-08
curl … | zstd -d | tar xjob-09
curl … | zstd -d | tar xjob-10
curl … | zstd -d | tar xjob-11
curl … | zstd -d | tar xjob-12
curl … | zstd -d | tar xjob-13
curl … | zstd -d | tar xjob-14
curl … | zstd -d | tar xjob-15
curl … | zstd -d | tar xjob-16
curl … | zstd -d | tar xjob-17
curl … | zstd -d | tar xjob-18
curl … | zstd -d | tar xjob-19
curl … | zstd -d | tar xjob-20
curl … | zstd -d | tar xuse-cases / a-ci-cache-thats-just-two-curl-commands / flow
كل الميكانيكا في سطرَي صَدفة
لا مكتبة عميل، لا خَدَم، لا SDK. المُنتِج يبثّ ملف tar إلى PUT /pipe/cache?n=20. كل عامل يبثّه عائداً من GET /pipe/cache?n=20. الأنبوب يحتفظ بالبايتات فقط أثناء طيرانها — لا على القرص أبداً.
PUT · المُنتِجيُشغَّل مرّة لكل بناء
أنتج الذاكرة
$tar c node_modules|zstd|curl -T -
https://hoody.com/pipe/cache?n=20
# blocks until 20 receivers connect, then streams once
tar يحزم node_modules؛ zstd يضغط أثناء الطيران؛ curl يُرسل البايتات بـ PUT مباشرةً إلى مسار الأنبوب. لا ملف مؤقّت، لا خطوة upload-artifact، لا بيانات اعتماد دلو.
GET · المستهلِكيُشغَّل على كل عامل
استهلك الذاكرة
$curlhttps://hoody.com/pipe/cache?n=20
| zstd -d | tar x
# توزيع: كل عامل يحصل على نسخة متطابقة
كل عامل اختبار يطلب نفس الرابط بـ GET، يفكّ الضغط، ويفكّ tar إلى دليل عمله. العمّال البطيئون يُطبّقون ضغطاً عكسياً على المُنتِج لكنّهم لا يحجبون الأسرع.
كامل سطح التنسيق
?n=20مُعامل استعلام واحد. المُنتِج والمستهلِك يتّفقان على نفس n. الأنبوب يحتفظ بالرفع حتى يتّصل ذلك العدد بالضبط، ثم يفتح البوّابات.
use-cases / a-ci-cache-thats-just-two-curl-commands / relief
ما تتوقّف عن دفعه
ذاكرة CI كانت ضريبة: تخزين ستكتب فوقه غداً، خروج كل مرّة يسحب فيها عامل، وقت هندسي على غرابات cache action. الأنبوب يحذف البنود الثلاثة دفعةً واحدة.
لا دلو. لا فاتورة خروج.
لا دلو S3 لأنّه لا تخزين. الأنبوب ينسى البايتات لحظة انتهاء النقل، فلا شيء يُتقاضى عنه لكل جيجابايت-شهر أو لكل جيجابايت-خروج. الذاكرة تتوقّف عن كونها بنداً.
لا غرابات cache action
لا مفاتيح بصيغة yaml، لا تقسيم save-cache / restore-cache، لا تنقيح لماذا لم تحدث ضربة ذاكرة على المُشغِّل الصحيح. فقط curl. السطران ذاتهما يعملان على GitHub Actions وBuildKite وJenkins وحاسوبك المحمول وحاوية cron.
لا تصادمات مفاتيح عبر الفروع
الفروع تستخدم مسارات مختلفة فحسب. /pipe/cache/main، /pipe/cache/feat-x، /pipe/cache/PR-742. لا شيء يجب إبطاله. لا شيء يجب طرده. حين يموت الفرع، يتوقّف مساره عن كونه مطلوباً وذاك هو كامل دورة الحياة.
use-cases / a-ci-cache-thats-just-two-curl-commands / compare
شكل التكلفة، قبل وبعد
على عبء عمل حقيقي — node_modules بحجم 800 ميجابايت تقريباً، عشرون عامل اختبار متوازياً، مئة تشغيل CI يومياً — معظم الفاتورة خروج، لا تخزين.
S3 + ذاكرة GH ACTIONS
خروج 20×
كلٌّ من العشرين عاملاً يسحب الذاكرة من S3. عشرون تنزيلاً لملف tar بحجم 800 ميجابايت يساوي 16 جيجابايت خروج لكل تشغيل CI. الدلو نفسه هو الجزء السهل — الخروج هو ما يتراكم.
VS
HOODY PIPE · ?n=20
نقل 1×
المُنتِج يبثّ 800 ميجابايت مرّةً واحدة. الأنبوب يفرّع البايتات إلى كل العشرين مستقبِلاً في الطيران. نقل واحد عبر السلك، لا مضاعف لكل مستقبِل، لا فاتورة تخزين.
الأرقام توضيحيّة لذاكرة monorepo Node نموذجيّة. الوفر الفعلي يعتمد على حجم tar وتفرّع العمّال وسعر الخروج الذي يتقاضاه مزوّدك من منطقة الذاكرة. الشكل — خطّي مقابل ثابت بعدد العمّال — لا يتغيّر.
use-cases / a-ci-cache-thats-just-two-curl-commands / punchline
طبقة الذاكرة هي HTTP. كانت كذلك دائماً. لم نلاحظ فقط.
الذواكر لم تكن قطّ عن التخزين. كانت عن إيصال نفس البايتات إلى N عاملاً دون إعادة بناء. HTTP يفعل ذلك أصلاً — حالما تسمح لرابط بأن يتفرّع إلى عدد معروف من المستقبِلين. الدلو كان حلاً التفافياً للتفرّع الذي لم يكن لدينا.
بايتات
ابثّ مرّة، تفرّع
PUT واحد، n GETs، بايتات متطابقة. الضغط العكسي لكل مستقبِل فلا يُبطئ العامل البطيء السريعين.
PUT /pipe/cache?n=20وقت
يحيا فقط في الطيران
الأنبوب يحتفظ بالبايتات للنقل وينساها عند انتهائه. لا شيء يجب طرده، لا دورة حياة، لا نسخ احتياطيّة.
TTL ≤ 5 دقائق · ثم يُطردمسار
الفروع مسارات
كل فرع يختار مساره. لا فضاء مفاتيح مشترك، لا تصادمات. المسار هو مفتاح الذاكرة والرابط في آن.
/pipe/cache/[branch]use-cases / a-ci-cache-thats-just-two-curl-commands / replaces
ما يستبدله هذا
معظم ذواكر CI تحلّ المشكلة نفسها: إيصال نفس tar إلى N عاملاً. تفعل ذلك عبر التخزين والخروج. الأنبوب يفعله عبر السلك.
- AWS S3 (دلو ذاكرة + خروج)تخزين ستكتب فوقه غداً + خروج لكل سحبة
- ذاكرة GitHub Actionsمفاتيح Yaml، غرابات خاصّة بالمُشغِّل، سقف 10 جيجابايت
- ذواكر BuildJet / Garnix CIأسرع، مع ذلك لكل بائع، مع ذلك لكل بايت
- ذاكرة Bazel البعيدةممتازة إن كنت كاملاً على Bazel؛ ثقيلة إن لم تكن
- ذاكرة Turborepo البعيدةمستضافة من Vercel، شكل monorepo، ذات رأي
- ذاكرة Earthly satelliteخَدَم آخر، دلو آخر، فاتورة أخرى
- ذواكر rsync مُخصّصةصندوق NFS ومفتاح SSH ينسى الجميع تدويره
use-cases / a-ci-cache-thats-just-two-curl-commands / cta
أمرا curl. رابط واحد. عشرون عاملاً مُتغذِّياً.
use-cases / a-ci-cache-thats-just-two-curl-commands / related
اقرأ الآخرين
