மல்டி-ஸ்டேஜ் பில்ட்ஸ் என்றால் என்ன மற்றும் அவற்றை ஏன் பயன்படுத்த வேண்டும்?

மல்டி-ஸ்டேஜ் பில்ட்ஸ் ஒரே Dockerfile-ல் பல FROM ஸ்டேஜ்களைப் பயன்படுத்துகின்றன — அப்ளிகேஷனை ஒரு ஸ்டேஜில் (அனைத்து பில்ட் டூல்ஸுடன்) பின்னர் இறுதி கலைப்பொருட்களை மட்டுமே சுத்தமான, குறைந்தபட்ச இறுதி ஸ்டேஜில் நகலெடுக்கிறது. இது மிகவும் சிறிய, பாதுகாப்பான உৎপாதன images உற்பத்தி செய்கிறது.

சிக்கல்: பில்ட் டூல்ஸ் image-ஐ வீங்கச் செய்கிறது

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.

மல்டி-ஸ்டேஜ் பில்ட்

# 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 இறுதி image-க்கு நகலெடுக்கிறது. இறுதி image பில்ட் ஸ்டேஜிலிருந்து நீங்கள் வெளிப்படையாக நகலெடுக்கும் தவிர வேறு எதையும் விலக்குகிறது — எனவே பில்ட் டூல்ஸ், dev சார்பியல்கள் மற்றும் source உৎபாதனத்தில் உறுதியாகப் போகாது.

நன்மைகள்

✓ 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.

இது ஏன் முக்கியம்

மல்டி-ஸ்டேஜ் பில்ட்களைப் புரிந்துகொள்வது சிறிய, பாதுகாப்பான உৎபாதன images உற்பத்தி செய்ய மূல்யமானது, எனவே உৎபாதன-தரம் Docker images கட்டமைப்பதற்கான முக்கியமான நடைமுறை அறிவாகும்.

இது தீர்க்கும் சிக்கல் உண்மையான மற்றும் பொதுவான: ஒரு அப்ளிகேஷனை பில்ட் செய்ய பில்ட் டூல்ஸ் (compilers, SDKs, dev சார்பியல்கள்) தேவை, அவை இறுதி உৎபாதன image-ல் இருக்க வேண்டாது — அவற்றை உள்படுத்துவது image-ஐ வீங்கச் செய்கிறது (பெரிய அளவு, மெதுவான deployments மற்றும் pulls) மற்றும் தாக்குதல் மேற்பரப்பை அதிகரிக்கிறது (நிறுவப்பட்ட மென்பொருள் அதிகமாக இருந்தால் அதிக சாத்தியமான பாதுகாப்பு பற்றாக்குறைகள்). மல்டி-ஸ்டேஜ் பில்ட்ஸ் இதை நேர்த்தியாக தீர்க்கிறது, பல FROM ஸ்டேஜ்களைப் பயன்படுத்துவதன் மூலம்: அப்ளிகேஷனை அனைத்து டூல்ஸுடன் ஒரு ஸ்டேஜில் பின்னர் இறுதி கலைப்பொருட்களை மட்டுமே (--from=build) சுத்தமான, குறைந்தபட்ச இறுதி ஸ்டேஜில் நகலெடுப்பது மற்றும் மற்றெல்லாவற்றை விலக்குவது.

இது நாটகীয়ভাবে சிறிய images (பெரும்பாலும் 10 மடங்கு சிறியது — வெறுமே runtime மற்றும் கலைப்பொருட்கள்) மற்றும் பாதுகாப்பான (பில்ட் டூல்ஸ் அல்லது தேவையற்ற packages இல்லை சுரண்ட), ஒரே Dockerfile-ல் எல்லாவற்றையும் வைத்திருந்து (தனிப்பட்ட பில்ட் scripts இல்லை) உற்பத்தி செய்கிறது.

இந்த pattern compiled languages (Go, Rust, Java, இதில் compiler runtime-ல் தேவையில்லை) மற்றும் frontend/Node builds (build tooling மற்றும் source உற்பாதனத்தில் தேவையில்லை) க்கான standardஆகும்.

சிறிய, பாதுகாப்பான உற்பாதன images deployment வேகம், storage மற்றும் பாதுகாப்புக்கான முக்கியம், மற்றும் மல்டி-ஸ்டேஜ் பில்ட்ஸ் அவற்றை அடைய வேண்டிய standardஆகும், பயனுள்ள technique (lean runtime image-க்கு பில்ட் சூழலை பிரித்து), மல்டி-ஸ்టேஜ் பில்ட்களைப் புரிந்துகொள்வது — அவை தீர்க்கும் வீங்கல்/பாதுகாப்பு சிக்கல், அவை எவ்வாறு செயல்படுகின்றன, மற்றும் அவற்றின் நன்மைகள் — மூல்যமான, அடிக்கடி பயன்படுத்தப்படும் அறிவு உৎபாதன-தரம் Docker images கட்டமைப்பதற்கு, real-world Dockerfiles-ல் பரவலாக பயன்படுத்தப்படும் ஒரு best practice மற்றும் efficient, safe containerized applications உற்பாதனத்திற்கான முக்கிய skill.