Multi-stage build là gì và tại sao nên dùng chúng?

Question

Accepted Answer

**Multi-stage build** dùng nhiều stage `FROM` trong một Dockerfile — build ứng dụng trong một stage (với tất cả các công cụ build) và chỉ copy các artifact cuối cùng vào một stage cuối sạch sẽ, tối thiểu. Điều này tạo ra các image production **nhỏ hơn, an toàn hơn nhiều**.

## Vấn đề: các công cụ build làm phình image

```text
Build một ứng dụng cần các công cụ build (compiler, dev dependency, SDK), nhưng image
CUỐI CÙNG không nên bao gồm chúng:
  → chúng làm phình image (kích thước lớn hơn, triển khai chậm hơn)
  → chúng tăng bề mặt tấn công (nhiều phần mềm hơn = nhiều lỗ hổng hơn)
→ Bạn chỉ muốn artifact đã build + runtime của nó trong image cuối cùng.
```

## Multi-stage build

```dockerfile
# STAGE 1: "build" — có tất cả các công cụ build (biên dịch/đóng gói ứng dụng)
FROM node:20 AS build
WORKDIR /app
COPY package*.json ./
RUN npm install              # bao gồm dev dependency, công cụ build
COPY . .
RUN npm run build            # tạo ra /app/dist

# STAGE 2: cuối — một image sạch, tối thiểu CHỈ với artifact đã build
FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html   # chỉ copy output của build
# → image cuối KHÔNG có công cụ build, không dev dependency — chỉ nginx + các tệp đã build
```

`--from=build` copy các artifact từ stage build vào image cuối. Image cuối **loại trừ mọi thứ từ stage build trừ những gì bạn copy rõ ràng** — nên các công cụ build, dev dependency và mã nguồn không kết thúc trong production.

## Các lợi ích

```text
✓ Image NHỎ HƠN — chỉ runtime + artifact (thường nhỏ hơn 10x+)
✓ AN TOÀN hơn — ít gói hơn = bề mặt tấn công nhỏ hơn (không compiler/công cụ build)
✓ Triển khai/pull nhanh hơn (image nhỏ hơn truyền nhanh hơn)
✓ Một Dockerfile — build và image cuối cùng với nhau (không cần script build riêng)
→ Phổ biến cho các ngôn ngữ biên dịch (Go, Rust, Java) và các build Node/frontend.
```

## Tại sao điều này quan trọng

Hiểu multi-stage build là có giá trị để **tạo ra các image production nhỏ, an toàn**, vì vậy đó là kiến thức thực tế quan trọng để build các image Docker chất lượng production.

Vấn đề nó giải quyết là có thật và phổ biến: build một ứng dụng đòi hỏi các **công cụ build** (compiler, SDK, dev dependency) mà image **production cuối cùng không nên chứa** — bao gồm chúng làm phình image (kích thước lớn hơn, triển khai và pull chậm hơn) và tăng **bề mặt tấn công** (nhiều phần mềm được cài đặt hơn nghĩa là nhiều lỗ hổng tiềm năng hơn). **Multi-stage build** giải quyết điều này một cách thanh lịch bằng cách dùng nhiều stage `FROM`: build ứng dụng trong một stage với tất cả các công cụ, sau đó **chỉ copy các artifact cuối cùng** (`--from=build`) vào một stage cuối sạch sẽ, tối thiểu loại trừ mọi thứ khác.

Điều này tạo ra các image **nhỏ hơn đáng kể** (thường nhỏ hơn 10x+ — chỉ runtime và artifact) và **an toàn hơn** (không có công cụ build hoặc gói không cần thiết để khai thác), trong khi giữ mọi thứ trong một Dockerfile duy nhất (không cần script build riêng).

Mẫu này là chuẩn cho các ngôn ngữ biên dịch (Go, Rust, Java, nơi compiler không cần thiết tại runtime) và cho các build frontend/Node (nơi công cụ build và mã nguồn không cần thiết trong production).

Vì các image production nhỏ, an toàn quan trọng cho tốc độ triển khai, lưu trữ và bảo mật, và vì multi-stage build là kỹ thuật chuẩn, hiệu quả để đạt được chúng (tách môi trường build khỏi image runtime gọn nhẹ), hiểu multi-stage build — vấn đề phình/bảo mật mà chúng giải quyết, cách chúng hoạt động, và các lợi ích của chúng — là kiến thức có giá trị, thường được áp dụng để build các image Docker chất lượng production, một thực hành tốt nhất được dùng rộng rãi trong các Dockerfile thực tế và một kỹ năng chính để tạo ra các ứng dụng container hóa hiệu quả, an toàn.