أفضل سبب لاستخدام بناءات Docker متعددة المراحل ليس الجمالية. إنه الانضباط.
يجب أن تحتوي صور الإنتاج على التطبيق ووقت التشغيل الذي تحتاجه لتنفيذه. لا ينبغي عليها أيضًا أن تحتوي على:
- مصنفات
- ذاكرات مدير الحزم
- أدوات الاختبار
- ملفات المصدر التي تكون مفيدة فقط أثناء وقت البناء
تجعل البناءات متعددة المراحل هذا الفصل واضحًا.
النمط
ابنِ في مرحلة واحدة، واشغل في أخرى:
FROM node:22-bookworm AS build
WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN corepack enable && pnpm install --frozen-lockfile
COPY . .
RUN pnpm build
RUN pnpm prune --prod
FROM node:22-alpine AS runtime
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
COPY --from=build /app/package.json ./package.json
USER node
CMD ["node", "dist/server.js"]
ذلك يمنحك حدودًا نظيفة بين "ما هو مطلوب للبناء" و"ما هو مطلوب للتشغيل."
التحذير من ألبين
يمكن أن تكون ألبين صورة وقت تشغيل جيدة. لكنها ليست بالضرورة المناسبة تلقائيًا.
لا تزال بحاجة إلى التفكير في:
- التبعيات الأصلية
- توافق libc
- احتياجات التصحيح
- مصدر الصورة
أحيانًا تكون الصورة الرفيعة المعتمدة على ديبيان هي الخيار الأفضل من حيث التشغيل. المبدأ هو شحن أقل، وليس العبادة العمياء لصورة قاعدة محددة.
ما الذي تحققه لك
عندما تُعمل بشكل جيد، فإن البناءات متعددة المراحل تحسن:
- حجم الصورة
- وقت بدء التشغيل والسحب
- سطح الهجوم
- الوضوح حول تبعيات وقت التشغيل
لهذا السبب فإنها تستحق التنفيذ حتى عندما يكون الاختلاف في حجم الصورة معتدلاً.
قراءة إضافية