Multi-stage build คืออะไร และทำไมจึงควรใช้?

Question

Accepted Answer

**Multi-stage build** ใช้หลาย stage `FROM` ในหนึ่ง Dockerfile — โดย build แอปพลิเคชันใน stage หนึ่ง (พร้อม build tool ทั้งหมด) แล้วคัดลอกเฉพาะ artifact สุดท้ายเข้าไปใน stage สุดท้ายที่สะอาดและเล็กที่สุด วิธีนี้สร้าง image สำหรับ production ที่ **เล็กกว่าและปลอดภัยกว่ามาก**

## ปัญหา: build tool ทำให้ image อ้วน

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

## Multi-stage build

```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` คัดลอก artifact จาก build stage เข้าไปใน image สุดท้าย image สุดท้าย **ไม่รวมทุกอย่างจาก build stage ยกเว้นสิ่งที่คุณคัดลอกอย่างชัดเจน** — ดังนั้น build tool, dev dependency และ source code จึงไม่ไปลงเอยใน production

## ประโยชน์

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

## ทำไมจึงสำคัญ

การเข้าใจ multi-stage build มีคุณค่าต่อการ **สร้าง image สำหรับ production ที่เล็กและปลอดภัย** จึงเป็นความรู้ปฏิบัติที่สำคัญสำหรับการ build Docker image ระดับ production

ปัญหาที่มันแก้เป็นเรื่องจริงและพบบ่อย: การ build แอปพลิเคชันต้องใช้ **build tool** (compiler, SDK, dev dependency) ที่ **image สำหรับ production สุดท้ายไม่ควรมี** — การรวมพวกมันทำให้ image อ้วน (ขนาดใหญ่ขึ้น, deploy และ pull ช้าลง) และเพิ่ม **พื้นที่โจมตี** (ซอฟต์แวร์ที่ติดตั้งมากขึ้นหมายถึงช่องโหว่ที่อาจเกิดมากขึ้น) **Multi-stage build** แก้ปัญหานี้อย่างสง่างามด้วยการใช้หลาย stage `FROM`: build แอปพลิเคชันใน stage ที่มีเครื่องมือทั้งหมด แล้ว **คัดลอกเฉพาะ artifact สุดท้าย** (`--from=build`) เข้าไปใน stage สุดท้ายที่สะอาดและเล็กที่สุดซึ่งไม่รวมทุกอย่างอื่น

วิธีนี้สร้าง image ที่ **เล็กลงอย่างมาก** (มักเล็กลง 10 เท่าขึ้นไป — เหลือเพียง runtime และ artifact) และ **ปลอดภัยกว่า** (ไม่มี build tool หรือ package ที่ไม่จำเป็นให้โจมตี) ในขณะที่เก็บทุกอย่างไว้ใน Dockerfile เดียว (ไม่ต้องมี build script แยกต่างหาก)

รูปแบบนี้เป็นมาตรฐานสำหรับภาษาที่ต้อง compile (Go, Rust, Java ที่ไม่ต้องใช้ compiler ตอน runtime) และสำหรับการ build แบบ frontend/Node (ที่ build tool และ source code ไม่จำเป็นใน production)

เนื่องจาก image สำหรับ production ที่เล็กและปลอดภัยมีความสำคัญต่อความเร็วในการ deploy, พื้นที่จัดเก็บ และความปลอดภัย และเนื่องจาก multi-stage build เป็นเทคนิคมาตรฐานที่มีประสิทธิภาพในการบรรลุสิ่งเหล่านี้ (แยกสภาพแวดล้อม build ออกจาก image runtime ที่กระชับ) การเข้าใจ multi-stage build — ปัญหาความอ้วน/ความปลอดภัยที่มันแก้, วิธีการทำงาน และประโยชน์ — จึงเป็นความรู้ที่มีคุณค่าและนำไปใช้บ่อยสำหรับการ build Docker image ระดับ production เป็น best practice ที่ใช้กันอย่างแพร่หลายใน Dockerfile ในโลกจริง และเป็นทักษะสำคัญในการสร้างแอปพลิเคชันที่ทำเป็น container ที่มีประสิทธิภาพและปลอดภัย