خفّض Docker Build في CI من 12 دقيقة لدقيقتين باستخدام BuildKit Cache

# syntax=docker/dockerfile:1.7
FROM node:20-alpine AS builder

WORKDIR /app

COPY package.json package-lock.json ./

# دي السطر المهم: كاش mount لـ npm
RUN --mount=type=cache,target=/root/.npm \
    npm ci --prefer-offline --no-audit

COPY . .
RUN npm run build

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/server.js"]

السطر الأول (# syntax=...) ضروري — من غيره، BuildKit مش هيتعرّف على الـ --mount directive. الـ --prefer-offline بيقول لـ npm: شوف الكاش الأول قبل ما تروح للـ registry.

2. ظبّط GitHub Actions يستخدم registry cache

الجزء الذكي هنا: cache-from وcache-to. الكاش بيتخزن كـ image منفصل في نفس الـ registry (هنا ghcr.io). أي runner في أي زمن بيقدر يسحب الكاش ده ويبدأ من حيث انتهى آخر build. mode=max بيخلي كل الـ intermediate layers تتحفظ، مش بس الـ final layer.

الأرقام الفعلية قبل وبعد

على مشروع Node.js حقيقي بـ 1,200 dependency في package.json، Dockerfile يحتوي 4 stages، وحجم نهائي 480MB:

• قبل: 12 دقيقة 40 ثانية (build بارد، ما فيش cache).
• بعد، أول build: 11 دقيقة 50 ثانية (نفس الزمن تقريبًا، لأن الكاش لسه بيتبني).
• بعد، builds تالية بتغيير في كود التطبيق فقط: 1 دقيقة 50 ثانية.
• بعد، builds تالية بتغيير في dependency واحدة: 3 دقايق 20 ثانية.

التحسن الفعلي: 6.8× في الحالة الشائعة (تغيير كود فقط). لاحظ إن أول build مش بيتحسن — الكاش بيتبني تدريجيًا.

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

كل قرار تقني له ثمن. هنا التكاليف اللي بتدفعها:

• تخزين في registry: الـ buildcache image ممكن يوصل لـ 2-3GB. على GitHub Container Registry للحسابات الشخصية ده مجاني، على Docker Hub Pro حوالي 10$/شهر زيادة.
• تعقيد إضافي في الـ Dockerfile: أي مطوّر جديد لازم يفهم الـ syntax directive والـ cache mounts. التوثيق ضروري.
• cache invalidation أصعب: لو في bug ناتج من dependency قديمة في الكاش، بيكون debugging أصعب. لازم تعرف تمسح الـ buildcache يدويًا (docker buildx prune أو حذف الـ image من الـ registry).
• وقت download للكاش نفسه: سحب 1.5GB cache من الـ registry بياخد 30-60 ثانية. لو الـ build الأصلي ما كانش بياخد أكتر من 4 دقايق، التحسن الصافي مش كبير.

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

الكاش مش حل سحري لكل الحالات. ابتعد عنه لو:

• الـ build الأصلي أقل من 3 دقايق — الفايدة مش هتغطي وقت setup الـ buildx والـ registry pull.
• عندك متطلبات أمنية صارمة (PCI-DSS، HIPAA) بتفرض إن كل build يبتدي من حالة نظيفة معروفة. الكاش بطبيعته بيخلّي state من build قديم في الجديد.
• المشروع بياخد npm install مرة واحدة كل أسبوع — الـ cache هيبقى cold دايمًا، ومش هيفيد.
• بتستخدم self-hosted runners — في الحالة دي استخدم local cache بدل registry cache. type=local,dest=/tmp/buildcache أسرع وأرخص.

المصادر

• Docker Docs — Cache backends
• Docker Docs — GitHub Actions cache
• Dockerfile reference — RUN --mount=type=cache
• docker/build-push-action — GitHub repository
• GitHub Docs — Caching dependencies

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

افتح أحدث Dockerfile بتاعك دلوقتي، وضيف # syntax=docker/dockerfile:1.7 في أول سطر، وحوّل أي سطر RUN npm install أو RUN pip install لاستخدام cache mount. شغّل الـ pipeline مرتين متتاليتين، وقارن الزمن في الـ Actions tab. لو الـ build التاني ما اتسرّعش بـ 3× على الأقل، المشكلة في ترتيب طبقات الـ Dockerfile — انقل COPY package.json قبل COPY . ..