ما هي البنايات متعددة المراحل ولماذا نستخدمها؟

Question

Accepted Answer

**البنايات متعددة المراحل** تستخدم عدة مراحل `FROM` في Dockerfile واحد — بناء التطبيق في مرحلة واحدة (مع جميع أدوات البناء) ونسخ المصنوعات النهائية فقط إلى مرحلة نهائية نظيفة وبسيطة. هذا ينتج صور إنتاجية **أصغر بكثير وأكثر أماناً**.

## المشكلة: أدوات البناء تنتفخ الصورة

```text
Building an app needs build tools (compilers, dev dependencies, SDKs), but the
FINAL image shouldn't include them:
  → they bloat the image (larger size, slower deploys)
  → they increase the attack surface (more software = more vulnerabilities)
→ You want only the built artifact + its runtime in the final image.
```

## البناء متعدد المراحل

```dockerfile
# STAGE 1: "build" — has all the build tools (compile/bundle the app)
FROM node:20 AS build
WORKDIR /app
COPY package*.json ./
RUN npm install              # includes dev dependencies, build tools
COPY . .
RUN npm run build            # produces /app/dist

# STAGE 2: final — a clean, minimal image with ONLY the built artifact
FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html   # copy ONLY the build output
# → the final image has NO build tools, no dev dependencies — just nginx + the built files
```

يقوم `--from=build` بنسخ المصنوعات من مرحلة البناء إلى الصورة النهائية. الصورة النهائية **تستبعد كل شيء من مرحلة البناء باستثناء ما تنسخه بشكل صريح** — لذا أدوات البناء والمكتبات الإنمائية والشفرة المصدرية لن تنتهي في الإنتاج.

## الفوائد

```text
✓ SMALLER images — only the runtime + artifacts (often 10x+ smaller)
✓ More SECURE — fewer packages = smaller attack surface (no compilers/build tools)
✓ Faster deploys/pulls (smaller images transfer faster)
✓ One Dockerfile — build and final image together (no separate build scripts)
→ Common for compiled languages (Go, Rust, Java) and Node/frontend builds.
```

## لماذا يهم

فهم البنايات متعددة المراحل ذو قيمة **لإنتاج صور إنتاجية صغيرة وآمنة**، لذلك فهو معرفة عملية مهمة لبناء صور Docker بجودة إنتاجية.

المشكلة التي يحلها حقيقية وشائعة: بناء تطبيق يتطلب **أدوات البناء** (المصرفات والمجموعات والمكتبات الإنمائية) التي **الصورة الإنتاجية النهائية لا يجب أن تحتويها** — إدراجها ينتفخ الصورة (حجم أكبر وعمليات نشر وسحب أبطأ) ويزيد **السطح القابل للهجوم** (المزيد من البرامج المثبتة تعني المزيد من الثغرات المحتملة). **البنايات متعددة المراحل** تحل هذا بأناقة باستخدام عدة مراحل `FROM`: بناء التطبيق في مرحلة مع جميع الأدوات، ثم **نسخ المصنوعات النهائية فقط** (`--from=build`) إلى مرحلة نهائية نظيفة وبسيطة تستبعد كل شيء آخر.

هذا ينتج صور **أصغر بشكل كبير** (غالباً 10 مرات أصغر أو أكثر — فقط وقت التشغيل والمصنوعات) و**أكثر أماناً** (بدون أدوات بناء أو حزم غير ضرورية للاستغلال)، مع الحفاظ على كل شيء في Dockerfile واحد (بدون نصوص بناء منفصلة).

هذا النمط قياسي للغات المترجمة (Go و Rust و Java حيث المصرف غير مطلوب في وقت التشغيل) ولبنايات frontend/Node (حيث أدوات البناء والشفرة المصدرية غير مطلوبة في الإنتاج).

لأن صور الإنتاج الصغيرة والآمنة مهمة لسرعة النشر والتخزين والأمان، ولأن البنايات متعددة المراحل هي التقنية القياسية والفعالة لتحقيقها (فصل بيئة البناء عن صورة التشغيل البسيطة)، فهم البنايات متعددة المراحل — مشكلة الانتفاخ والأمان التي تحلها وكيفية عملها وفوائدها — معرفة قيمة وكثيرة التطبيق لبناء صور Docker بجودة إنتاجية، ممارسة أفضل مستخدمة على نطاق واسع في Dockerfiles الحقيقية ومهارة أساسية لإنتاج تطبيقات محاكاة فعالة وآمنة.