Apa itu multi-stage builds dan mengapa menggunakannya?

Question

Accepted Answer

**Multi-stage builds** menggunakan beberapa stage `FROM` dalam satu Dockerfile — membangun aplikasi dalam satu stage (dengan semua build tools) dan menyalin hanya artifacts akhir ke stage akhir yang bersih dan minimal. Ini menghasilkan **image production yang jauh lebih kecil dan lebih aman**.

## Masalah: build tools membuat image membengkak

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

Flag `--from=build` menyalin artifacts dari build stage ke image akhir. Image akhir **mengecualikan segalanya dari build stage kecuali yang Anda salin secara eksplisit** — jadi build tools, dev dependencies, dan source tidak berakhir di production.

## Manfaat

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

## Mengapa ini penting

Memahami multi-stage builds sangat berharga untuk **menghasilkan image production yang kecil dan aman**, sehingga ini adalah pengetahuan praktis penting untuk membangun image Docker berkualitas production.

Masalah yang diselesaikannya nyata dan umum: membangun aplikasi memerlukan **build tools** (kompiler, SDK, dev dependencies) yang **seharusnya tidak ada di image production akhir** — memasukkannya membuat image membengkak (ukuran lebih besar, deployment dan pull lebih lambat) dan meningkatkan **attack surface** (lebih banyak software terinstal berarti lebih banyak potensi kerentanan). **Multi-stage builds** menyelesaikan ini dengan elegan dengan menggunakan beberapa stage `FROM`: membangun aplikasi dalam stage dengan semua tools, kemudian **menyalin hanya artifacts akhir** (`--from=build`) ke stage akhir yang bersih dan minimal yang mengecualikan segalanya yang lain.

Ini menghasilkan image yang **jauh lebih kecil** (sering 10x+ lebih kecil — hanya runtime dan artifacts) dan **lebih aman** (tidak ada build tools atau packages yang tidak perlu untuk dieksploitasi), sambil menjaga semuanya dalam satu Dockerfile (tidak ada script build terpisah).

Pola ini adalah standar untuk bahasa compiled (Go, Rust, Java, di mana compiler tidak diperlukan saat runtime) dan untuk frontend/Node builds (di mana build tooling dan source tidak diperlukan di production).

Karena image production yang kecil dan aman penting untuk kecepatan deployment, penyimpanan, dan keamanan, dan karena multi-stage builds adalah teknik standar dan efektif untuk mencapainya (memisahkan build environment dari image runtime yang lean), memahami multi-stage builds — masalah bloat/keamanan yang mereka selesaikan, cara kerjanya, dan manfaatnya — adalah pengetahuan yang berharga dan sering diterapkan untuk membangun image Docker berkualitas production, best practice yang banyak digunakan dalam real-world Dockerfiles dan skill kunci untuk menghasilkan containerized applications yang efisien dan aman.