مولد ملفات Docker

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

يُثبّت ملف Docker البسيط سلسلة أدوات المترجم كاملة في الصورة النهائية. يمنحك البناء متعدد المراحل مرحلة “builder” تقوم بالترجمة ومرحلة نهائية تحمل الأثر المترجم فقط:

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
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
USER node
EXPOSE 3000
CMD ["node", "dist/index.js"]

تتخلص الصورة النهائية من كل تبعيات التطوير وملفات المصدر وذاكرة التخزين المؤقت للبناء، وغالبًا ما تقلص حجم الصورة بنسبة 60-80 بالمئة.

أصناف الصورة الأساسية

تستخدم القوالب صورًا slim أو alpine حيثما أمكن. إذا عدّلت الصورة الأساسية بنفسك، فهذه هي الخيارات النموذجية:

قواعد التخزين المؤقت للطبقات

يخزّن Docker كل سطر مؤقتًا؛ عندما تتغير طبقة، يُعاد بناء كل ما تحتها. الترتيب من الأقل إلى الأكثر تغيرًا:

1. صورة FROM الأساسية (نادرًا ما تتغير).
2. حزم النظام (apt-get install)، تغييرات نادرة.
3. ملفات التبعيات (package.json، requirements.txt، composer.json).
4. خطوة تثبيت التبعيات. تُنفَّذ فقط عند تغيّر ملف التبعيات.
5. نسخ الكود المصدري. الطبقة الأكثر نشاطًا؛ يُعاد بناء كل ما بعدها في كل commit.
6. الترجمة وCMD النهائي.

خرق هذا الترتيب هو السبب الأكثر شيوعًا لبطء عمليات بناء CI.

قائمة التحقق الأمنية

• شغّل كغير root. ضع USER appuser (أو USER 1000) قرب النهاية.
• ثبّت الإصدارات. python:3.12.7-slim أفضل من python:3.12، وهو أفضل من python:latest.
• حدد WORKDIR صريحًا بدلًا من الاعتماد على /.
• استخدم COPY لا ADD للملفات المحلية؛ لأن ADD له آثار جانبية لفك الضغط التلقائي.
• أضف HEALTHCHECK حتى تكتشف الأنظمة المنسقة العملية المتعثرة.
• نظّف مخابئ الحزم في سطر RUN نفسه: apt-get install ... && rm -rf /var/lib/apt/lists/*.