Docker BuildKit Cache: ليه الـ build بياخد 10 دقايق وإزاي تخلّيه دقيقة

ده تحسّن أكتر من 80% لو بتعمل أكتر من build في اليوم. على فريق 5 مهندسين، بيفرق ساعة ونصف من وقت الانتظار يومياً.

apt-get: حكاية أصعب شوية

مع apt، محتاج configuration إضافي: مجلدين cache، وحذف ملف docker-clean الموجود default في الـ base images.

ملاحظات لازم تركز فيها:

• sharing=locked إجباري مع apt. الـ tool بياخد lock على الملفات، ومن غير الخاصية دي لو عندك build بيشتغلوا بالتوازي بيحصل corruption للـ cache.
• حذف /etc/apt/apt.conf.d/docker-clean ضروري. الملف ده موجود default في base images زي ubuntu و debian، وبيمسح الـ cache تلقائي بعد كل apt install، وبيلغي فايدة الـ mount.
• بدل ما تضيف rm -rf /var/lib/apt/lists/* زي ما كلنا بنعمل بالعادة، متضيفهوش لما تكون مستخدم cache mount، لأن الـ cache نفسه مش داخل الـ layer أصلاً.

الـ trap في GitHub Actions

الـ trade-off اللي مش كل الناس واعيه بيه: cache-from: type=gha و cache-to: type=gha في docker/build-push-action بتحفظ الـ image layers بس، مش بتحفظ محتوى الـ RUN --mount=type=cache. نتيجة: الـ build على الـ local بيبقى دقيقة، وعلى CI بيفضل 9 دقائق، ومش فاهم ليه.

الحل: استخدم action اسمه buildkit-cache-dance اللي بيـ export و import محتوى الـ cache mounts يدوياً قبل وبعد الـ build:

الـ trade-off هنا: الـ step ده بيضيف 15–30 ثانية لكل build (export/import للـ cache). في 90% من الحالات الوفر أكبر بكتير من التكلفة دي، لكن لو الـ cache حجمه أقل من 50MB، overhead مش مستحق.

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

cache mount بيضيف تعقيد بدون فايدة واضحة في الحالات دي:

• لو بتعمل build مرة واحدة في الأسبوع، الـ layer caching العادي كفاية.
• لو الـ dependencies صغيرة جداً (أقل من 20MB)، الفرق في الوقت هيكون ثواني.
• لو بتستخدم runners مؤقتة بتتعمل وتتمسح كل build (scale-to-zero)، الـ cache mount بيتمسح مع الـ runner نفسه. هتحتاج remote cache backend (S3 مثلاً).
• لو عندك npm ci في مشروع Node صغير، غالباً package-lock.json بيـ cache الـ layer بشكل كافي لو الـ COPY package*.json قبل الـ COPY . ..

الافتراضات اللي الشرح مبني عليها

الأرقام اللي فوق مبنية على: Docker 24.0+، مشروع Python بـ 47 dependency، و runner بـ 4 vCPU. لو عندك حجم مختلف (مثلاً 200 dependency أو runner بـ 1 vCPU)، النسب هتبقى قريبة لكن الأرقام المطلقة هتختلف.

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

افتح الـ Dockerfile الحالي عندك، ضيف # syntax=docker/dockerfile:1.7 في أول سطر، وحوّل أكبر RUN pip install أو RUN apt-get install لصيغة cache mount. قيس الـ build قبل وبعد بـ time docker build . مرتين متتاليتين. لو الفرق بين المرتين أقل من 40%، غالباً فيه sharing=locked ناقص، أو layer invalidation بيحصل قبل الـ RUN. لو حصل ده، ابعت مخرجات docker build --progress=plain وهنفهم السبب.

المصادر

• Docker Docs — Optimize cache usage in builds
• Docker Docs — GitHub Actions cache backend
• moby/buildkit Issue #3011 — cache-from gha doesn't persist mount caches
• Depot — How to use cache mounts to speed up Docker builds
• reproducible-containers/buildkit-cache-dance