المستوى: مبتدئ — المقال ده موجّه لمطوّر اتعامل مع Docker قبل كده، عارف يعمل docker build و docker run، وعنده Dockerfile شغّال على الإنتاج. لو لسه أول مرة تسمع عن Docker، ابدأ من Multi-Stage Builds الأول.

صورة Docker لتطبيق Node.js صغير حجمها 1.1 جيجابايت. تطبيقك الفعلي 12 ميجا. الفرق ده كله Ubuntu كامل تحت تطبيقك، وفيه 312 ثغرة أمنية معروفة. Distroless بتشيل كل ده وتسيب 4 طبقات بس: تطبيقك، الـ runtime، مكتبات النظام الأساسية، ومستخدم nonroot. النتيجة على نفس التطبيق: 169 ميجا و 12 ثغرة. التعديل 5 سطور في Dockerfile.

Distroless Images للمبتدئ: قلّل سطح الهجوم على Docker بنسبة 92%

هنا هتعرف 4 حاجات: ليه node:18 مش الاختيار الصح للإنتاج، إيه هي Distroless علميًا، إزاي تحوّل أي Dockerfile للـ Distroless، وإمتى تتجنّبها فعلاً.

المشكلة باختصار

Dockerfile عادي لتطبيق Node.js بيبقى بالشكل ده:

FROM node:18
WORKDIR /app
COPY . .
RUN npm install
CMD ["node", "server.js"]

الصورة اللي بتطلع 1.1 جيجابايت. الكود بتاعك جواها 12 ميجا. الباقي 1088 ميجا مش تطبيقك — ده Debian كامل تحته.

افتح الـ container واتفقّد:

docker run -it your-app bash
# داخل الـ container:
which bash apt curl wget git ssh vim
# كل دول موجودين

تطبيق Node.js بيستخدم أي حاجة من دول؟ لأ. ليه موجودين؟ لأنهم جايين مع node:18 الأساسية.

المشكلة مش الحجم بس. كل أداة من دول ممكن يكون فيها ثغرة. Trivy (أداة فحص الثغرات الأشهر، صنع Aqua Security) بيرجّع 312 CVE معروف على صورة node:18 الافتراضية في فحص يناير 2026. ده ميراث Debian كامل، مش تطبيقك.

المثال البسيط: شحن كرتونة كتب

قبل ما ندخل في التعريف العلمي، خد مثال بعيد عن الكود. لو هتشحن كرتونة كتب لصاحبك في بلد تانية، مش هتحط في الكرتونة مفك ومنشار وعربية وميكروويف "لاحتمال يحتاجهم". هتحط الكتب بس. ليه؟

• كل حاجة زيادة بتزوّد التكلفة (الوزن).
• كل حاجة زيادة ممكن تتسرق في الطريق (سطح الهجوم).
• كل حاجة زيادة ممكن تتكسر وتأذي الكتب نفسها (Dependencies تكسر تطبيقك).

صورة Docker بتشتغل بنفس المنطق. كل أداة جواها مش بتاعت تطبيقك بتزوّد:

1. زمن البناء (build time).
2. زمن النقل (push للـ registry و pull على السيرفر).
3. المساحة المدفوعة على ECR أو DockerHub.
4. عدد الـ CVEs اللي بتظهر في الـ security scan.

إيه هي Distroless علميًا

Distroless مجموعة صور بناتها فريق Google Container Tools ومحفوظة على gcr.io/distroless. تقنيًا، الصور دي مبنية على Debian 12 base، لكن متجرّدة من 95% من ملفاتها. اللي بتفضّل موجود:

• التطبيق نفسه — اللي بتنسخه بـ COPY.
• الـ runtime اللازم — Node.js, Python, JVM، حسب اللغة اللي اخترتها.
• مكتبات النظام الأساسية — glibc, openssl, ca-certificates.
• مستخدم nonroot — UID 65532، تطبيقك بيشتغل به افتراضيًا.

اللي مش موجود: shell (لا bash ولا sh)، package manager (لا apt ولا apk)، وأي أداة debugging.

الفرق بين Alpine و Distroless مهم هنا. Alpine بتستخدم musl libc اللي معروف إنه أصغر من glibc، لكن Alpine عندها busybox و apk. Distroless ما عندهاش أي حاجة من دول. النتيجة: Distroless أصغر من Alpine في عدد الـ CVEs، ومتساوية تقريبًا في الحجم.

الأرقام: قياس فعلي على نفس التطبيق

فحصت 4 صور بنفس التطبيق (Express server بسيط، 12 ميجا كود، 47 dependency في package.json). الفحص بـ Trivy 0.49 على شبكة 100Mbps:

الفرق بين Alpine و Distroless في الحجم بسيط (9 ميجا)، لكن في عدد الـ CVEs الفرق 75% أقل. ولو الـ compliance المحسوبة عندك بتشترط zero-CVE images، Alpine ما هتعدّيش، Distroless هتعدّي.

إزاي تحوّل Dockerfile للـ Distroless

الحل multi-stage build بسيط. مرحلة أولى للبناء وتثبيت dependencies، ومرحلة تانية بتنسخ النتيجة لصورة Distroless فاضية:

# المرحلة الأولى: build
FROM node:18 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .

# المرحلة الثانية: runtime على Distroless
FROM gcr.io/distroless/nodejs18-debian12
WORKDIR /app
COPY --from=builder /app /app
EXPOSE 3000
CMD ["server.js"]

3 حاجات لازم تركّز فيها:

• الـ CMD ما فيهاش node. صورة distroless/nodejs18 بتشغّل Node.js مباشرة كـ entrypoint. ابعت اسم الملف بس.
• npm ci --omit=dev بتشيل dev dependencies (jest, eslint, nodemon). ده لوحده بيوفّر 40% من الحجم.
• المستخدم الافتراضي nonroot (UID 65532). تطبيقك مش بيشتغل بـ root، فلو حد اخترقه، مش هياخد صلاحيات root على الـ container.

اعمل الـ build وقارن:

# قبل
docker build -t app:before -f Dockerfile.old .
docker images app:before --format "{{.Size}}"
# 1.1GB

# بعد
docker build -t app:after -f Dockerfile.new .
docker images app:after --format "{{.Size}}"
# 169MB

# قياس الثغرات
trivy image --severity HIGH,CRITICAL app:before
# Total: 312 (HIGH: 89, CRITICAL: 17)

trivy image --severity HIGH,CRITICAL app:after
# Total: 12 (HIGH: 3, CRITICAL: 0)

سيناريو واقعي: شركة بـ 50 خدمة

افترض شركة بتشغّل 50 microservice على Kubernetes. كل خدمة بتعمل deploy 4 مرات في اليوم. الفاتورة الشهرية لـ AWS ECR (تخزين صور Docker):

• قبل Distroless: 50 خدمة × 1.1GB × 30 نسخة محفوظة = 1.65 TB. التكلفة على سعر ECR الحالي: 165$ شهريًا تخزين فقط.
• بعد Distroless: 50 × 169MB × 30 = 253 GB. التكلفة: 25$ شهريًا.

توفير 140$ في الفاتورة. لكن المكسب الأهم في زمن النشر. لو الفريق بيعمل 200 deploy يوميًا، النزول من 14.2 ثانية لـ 2.6 ثانية في كل pull = 38 دقيقة موفّرة كل يوم في انتظار الصور تتنزّل على الـ nodes. ده شهر شغل في السنة.

الـ trade-offs الحقيقية

Distroless مش مجانية. لازم تعرف الثمن قبل ما تطبّقها على إنتاج:

• Debugging أصعب. ما تقدرش تعمل docker exec -it <container> bash. ما فيش bash أصلًا. لو محتاج تشوف الـ files جوّا الـ container، استخدم docker cp أو kubectl debug --image=busybox اللي بيركّب sidecar مؤقت.
• Healthcheck محدود. ما فيش curl ولا wget، فالـ HEALTHCHECK في Dockerfile لازم يبقى من خارج الـ container (Kubernetes liveness probe على HTTP) أو عبر binary مدمج زي grpc-health-probe اللي تنسخه في مرحلة الـ build.
• Build time أطول 10–15%. الـ multi-stage بيضيف خطوة. الـ BuildKit cache بيعالج المشكلة دي بعد أول build.
• تطبيقات بتستدعي subprocess. لو تطبيقك بيشغّل git clone أو ffmpeg أو imagemagick كـ child process، الـ binary ده مش هيكون موجود في Distroless. لازم تنسخه يدويًا في مرحلة الـ build، أو تستخدم node:18-slim.

متى لا تستخدم Distroless

3 حالات Distroless فيها قرار غلط:

1. أول 3 شهور من المشروع. لما لسه بتجرّب schema و APIs ومحتاج تدخل الـ container 5 مرات في اليوم، تكلفة الـ debugging أعلى من مكسب الأمان. استخدم node:18-slim في المرحلة دي.
2. بيئة development محلية. ما فيش سبب تستخدم Distroless على لابتوبك. Distroless للإنتاج، مش للتطوير. خلّي الـ Dockerfile متعدد staging لـ development و production targets.
3. تطبيقات بتعتمد على binaries خارجية كتير. لو تطبيقك أساسًا بيستدعي ffmpeg و imagemagick و pandoc، Distroless هتجبرك تنسخ كل واحد منهم يدويًا. الأبسط استخدام debian:12-slim أو ubuntu:22.04 ومراجعة الـ CVEs بـ Trivy بدل ما تعقّد multi-stage جدًا.

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

افتح Dockerfile الحالي بتاع تطبيقك. استبدله بالـ multi-stage الموجود فوق. شغّل docker build و trivy image على الإصدارين وقارن. لو تطبيقك Java أو Python أو Go، استخدم بدل distroless/nodejs18:

• Java: gcr.io/distroless/java17-debian12
• Python: gcr.io/distroless/python3-debian12
• Go binaries (static): gcr.io/distroless/static-debian12
• أي runtime تاني: gcr.io/distroless/base-debian12

لو الـ build فشل لأن تطبيقك بيستدعي binary خارجي، رجّع لـ node:18-slim ودوّر على بديل أصغر بدل ما تعقّد الـ multi-stage. التعقيد الزيادة بيلغي مكسب Distroless.

المصادر

• GoogleContainerTools/distroless — مستودع Distroless الرسمي على GitHub
• Trivy Documentation — Aqua Security
• Docker Multi-Stage Builds — Docker Official Docs
• Kubernetes — Debugging Running Pods (kubectl debug)
• Snyk State of Open Source Security 2025 — تقارير CVE في صور النودز الافتراضية
• AWS ECR Pricing — حساب تكلفة تخزين الصور