BuildKit cache mounts: Docker build من 8 دقايق لدقيقة واحدة

npm

pip

apt

ملاحظة مهمة: apt مش بيدعم concurrent writes على نفس الـ cache، فلازم sharing=locked. وكمان محتاج تلغي الـ docker-clean الافتراضي علشان الملفات تفضل محفوظة:

Go

الأرقام: قبل وبعد

الأرقام دي من تجارب موثقة في Docker docs و Depot blog و PythonSpeed:

• مشروع Python بـ 50 dependency: pip install من 45 ثانية إلى 3 ثواني عند cache hit.
• مشروع Go بـ 300 dependency: build من 90 ثانية إلى 8 ثواني عند cache hit.
• CI pipeline شائع ورد في oneuptime blog: من 8 دقايق إلى حوالي دقيقة بعد تفعيل BuildKit cache.

الافتراض: المقارنة دي بتفترض إن الـ cache backend محفوظ بين الـ builds (persistent). لو شغّال على GitHub Actions مثلاً، محتاج تضيف cache-to: type=gha,mode=max في docker/build-push-action علشان الـ BuildKit cache يتنقل بين الـ runs. من غير ده، كل run هيبدأ من الصفر والأرقام دي مش هتتحقق.

Trade-offs اللي لازم تعرفها

• الـ CI runner لازم يحافظ على الـ cache. GitHub Actions بشكل افتراضي مش بيحفظ cache mounts جوا runner cache. محتاج حل زي cache-to: type=gha أو الـ buildkit-cache-dance trick.
• Space على الـ host. الـ cache بياكل disk. لو بتبني 10 image مختلفة، ممكن تلاقي 5–10GB مشغولة. شغّل docker buildx prune --keep-storage=10GB كل فترة.
• Builds متوازية. لو عندك CI بيبني كذا target في نفس الوقت، حدد sharing=locked للأدوات اللي مش بتدعم concurrent writes (أبرزها apt و composer).
• الـ cache ممكن يبوظ في حالات نادرة (corrupt wheel في pip مثلاً). الحل docker buildx prune --filter type=exec.cachemount.

متى لا تستخدم هذه الطريقة

مش كل build محتاج cache mount. تجنّبها في:

• Image فيها الـ cache نفسه مطلوب. الـ cache mount مش بيتحط في الـ image النهائية. لو محتاج الـ packages تفضل جوا الـ image كـ cache (مش عادي لكنه يحصل في use cases معينة)، مش هينفع.
• Single-shot builds. لو بتبني image مرة واحدة وخلاص، مفيش cache تستفيد منه. الـ overhead من ضبط BuildKit مش مبرّر.
• بيئات بدون BuildKit. لو شغّال على Docker إصدار أقدم من 18.09 أو على platform مش داعم، السطر هيتجاهل من غير ما يفيد.
• Dependencies بتتغيّر في كل build. لو الـ package.json بيتعدّل كل مرة بشكل جوهري، الـ cache hit rate هيكون منخفض والفايدة هامشية.

المصادر

• Docker Docs — Optimize cache usage in builds
• Depot — How to use cache mounts to speed up Docker builds
• PythonSpeed — Speed up pip downloads in Docker with BuildKit
• vsupalov.com — How to Speed Up Your Dockerfile with BuildKit Cache Mounts
• Docker Docs — Cache management with GitHub Actions

الخطوة التالية

افتح الـ Dockerfile الرئيسي بتاعك، وحدد السطر اللي فيه npm ci أو pip install أو apt-get install. ضيف قبل الأمر --mount=type=cache,target=<المسار المناسب> حسب الأمثلة فوق. شغّل الـ build مرتين على نفس المكنة وقارن الـ time. لو الثاني مش أسرع بشكل ملحوظ، ده معناه إن BuildKit مش شغّال أو الـ cache backend مش persistent — ابدأ من الشك ده قبل أي حاجة تانية.