كيف تقوم بتحسين حجم صورة Docker وأداء البناء؟

Question

Accepted Answer

يتضمن تحسين صور Docker تقليل **الحجم** (أصغر، أسرع، أكثر أماناً) وتحسين **أداء البناء** (بناء أسرع عبر التخزين المؤقت). تتضمن التقنيات صور أساسية بحد أدنى، بناء متعدد المراحل، تحسين الطبقات، BuildKit، وتصميم Dockerfile دقيق.

## تقليل حجم الصورة

```text
✓ MINIMAL base images:
  - alpine (tiny, ~5MB) — but musl libc can cause compatibility issues for some apps
  - slim variants (e.g. python:3.12-slim) — smaller than full, fewer compat issues
  - DISTROLESS — only the app + runtime, NO shell/package manager (smallest, most secure)
  - scratch — empty base (for static binaries, e.g. Go) → minimal image
✓ MULTI-STAGE builds — build with tools, ship only the artifact (huge size savings)
✓ Combine RUN layers + clean up IN the same layer:
  RUN apt-get update && apt-get install -y x && rm -rf /var/lib/apt/lists/*
  (cleanup in a SEPARATE layer doesn't shrink the image — the files are in the earlier layer)
✓ .dockerignore — keep junk out of the context/image
✓ Remove caches, temp files, dev dependencies in production images
```

## تحسين أداء البناء

```text
✓ LAYER CACHING — order Dockerfile so stable layers (deps) come before volatile (code)
✓ BUILDKIT (DOCKER_BUILDKIT=1 / default in modern Docker) — faster, parallel builds,
  better caching, build secrets, cache mounts
✓ CACHE MOUNTS — RUN --mount=type=cache,target=/root/.npm npm install
  → persist package-manager caches BETWEEN builds (don't re-download every time)
✓ Registry cache / --cache-from — reuse cached layers in CI (where the cache is cold)
```

## مثال على بناء متعدد المراحل + distroless

```dockerfile
FROM golang:1.22 AS build
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o app .

FROM gcr.io/distroless/static     # no shell, no OS — tiny and secure
COPY --from=build /app/app /app
ENTRYPOINT ["/app"]
# → final image is a few MB: just the static binary (vs ~800MB with the full golang image)
```

## لماذا يهم الأمر

تحسين حجم صورة Docker وأداء البناء هو معرفة قيمة على مستوى أعلى لأنه يؤثر مباشرة على **سرعة النشر، وتكاليف التخزين، والأمان، وإنتاجية المطورين**، لذلك فهو مهم عملياً للحاوية عالية الجودة في الإنتاج. **تقليل حجم الصورة** مهم لأن الصور الأصغر تُنشر وتُسحب بشكل أسرع، وتكلف أقل للتخزين، وهي **أكثر أماناً** (حزم أقل = سطح هجوم أصغر): استخدام **صور أساسية بحد أدنى** (alpine، slim، وخاصة **distroless** — التي تحتوي فقط على التطبيق والوقت التشغيلي بدون shell أو مدير حزم، الأصغر والأكثر أماناً — أو `scratch` للملفات الثنائية الثابتة)، **بناء متعدد المراحل** (نقل المخرجات فقط)، و**تحسين الطبقات** بعناية (دمج أوامر RUN مع التنظيف في *نفس* الطبقة، لأن التنظيف في طبقة منفصلة لا يقلل الصورة فعلياً — فهم خاطئ شائع) يمكن أن يقلل الصور بشكل كبير (على سبيل المثال من ~800MB إلى بضعة MB). **تحسين أداء البناء** مهم لأن البناء البطيء يضر إنتاجية المطورين وإنتاجية CI: الاستفادة من **تخزين طبقات مؤقتة** (الترتيب للثابت-قبل-المتغير)، **BuildKit** (بناء متوازي أسرع مع تخزين مؤقت أفضل)، وخاصة **تجهيزات التخزين المؤقت** (الاحتفاظ بتخزين مؤقت لمدير الحزم بين البناءات بحيث لا تُُحمل الاعتماديات كل مرة — تسريع كبير) وذاكرة تخزين مؤقتة للتسجيل بـ CI جميعها تجعل البناء أسرع.

فهم هذه التقنيات — والنقاط الدقيقة مثل سبب أهمية التنظيف في نفس الطبقة وكيفية تحسين distroless للحجم والأمان — يعكس العمق المطلوب لإنتاج صور محسّنة حقاً.

نظراً لأن حجم الصورة وسرعة البناء لهما تأثير حقيقي ومستمر على النشر والتكلفة والأمان والإنتاجية، وبما أن تقنيات التحسين هذه (القواعد الأساسية البحد الأدنى/distroless، البناء متعدد المراحل، تنظيف الطبقات الصحيح، تجهيزات التخزين المؤقت BuildKit) هي ما يحقق صور هزيلة وسريعة وآمنة، فإن فهم تحسين صور Docker والبناء هو معرفة قيمة على مستوى أعلى لحاويات الإنتاج، وهي مهارة أساسية تميز الاستخدام الاحترافي والمحسّن للبرنامج Docker وتعكس الخبرة المتوقعة لبناء صور حاويات فعالة وآمنة على نطاق واسع.