Τι είναι τα multi-stage builds και γιατί να τα χρησιμοποιήσουμε;

Question

Accepted Answer

**Multi-stage builds** χρησιμοποιούν πολλαπλά `FROM` stages σε ένα Dockerfile — δημιουργώντας την εφαρμογή σε ένα stage (με όλα τα build tools) και αντιγράφοντας μόνο τα τελικά artifacts σε ένα καθαρό, ελάχιστο τελικό stage. Αυτό παράγει **πολύ μικρότερες, πιο ασφαλείς** εικόνες παραγωγής.

## The problem: build tools bloat the 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` αντιγράφει artifacts από το build stage στην τελική εικόνα. Η τελική εικόνα **εξαιρεί όλα τα στοιχεία από το build stage εκτός από αυτά που αντιγράφετε ρητά** — έτσι τα build tools, οι dev dependencies και ο source code δεν καταλήγουν στην παραγωγή.

## Benefits

```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 builds είναι πολύτιμη για την **παραγωγή μικρών, ασφαλών εικόνων παραγωγής**, οπότε είναι σημαντική πρακτική γνώση για τη δημιουργία Docker εικόνων παραγωγικής ποιότητας.

Το πρόβλημα που λύνει είναι πραγματικό και συνηθισμένο: η δημιουργία μιας εφαρμογής απαιτεί **build tools** (compilers, SDKs, dev dependencies) που η **τελική εικόνα παραγωγής δεν θα πρέπει να περιέχει** — η συμπερίληψή τους αυξάνει το μέγεθος της εικόνας (μεγαλύτερο μέγεθος, βραδύτερες αναπτύξεις και pulls) και αυξάνει την **επιφάνεια επίθεσης** (περισσότερο εγκατεστημένο λογισμικό σημαίνει περισσότερες πιθανές τρωτότητες). **Τα multi-stage builds** λύνουν αυτό το πρόβλημα κομψά χρησιμοποιώντας πολλαπλά `FROM` stages: δημιουργώντας την εφαρμογή σε ένα stage με όλα τα tools, στη συνέχεια **αντιγράφοντας μόνο τα τελικά artifacts** (`--from=build`) σε ένα καθαρό, ελάχιστο τελικό stage που εξαιρεί όλα τα άλλα.

Αυτό παράγει εικόνες που είναι **δραματικά μικρότερες** (συχνά 10x+ μικρότερες — μόνο το runtime και τα artifacts) και **πιο ασφαλείς** (χωρίς build tools ή περιττά πακέτα που μπορούν να εκμεταλλευτούν), ενώ διατηρούν όλα σε ένα μόνο Dockerfile (χωρίς ξεχωριστά build scripts).

Αυτό το pattern είναι σταθμό για compiled languages (Go, Rust, Java, όπου ο compiler δεν χρειάζεται κατά το runtime) και για frontend/Node builds (όπου τα build tooling και source δεν χρειάζονται στην παραγωγή).

Επειδή οι μικρές, ασφαλείς εικόνες παραγωγής έχουν σημασία για την ταχύτητα ανάπτυξης, τον αποθηκευτικό χώρο και την ασφάλεια, και επειδή τα multi-stage builds είναι η τυπική, αποτελεσματική τεχνική για την επίτευξή τους (διαχωρισμός του περιβάλλοντος δημιουργίας από την αδύναμη εικόνα runtime), η κατανόηση των multi-stage builds — το πρόβλημα bloat/security που λύνουν, πώς λειτουργούν και τα οφέλη τους — είναι πολύτιμη, συχνά εφαρμοζόμενη γνώση για τη δημιουργία Docker εικόνων παραγωγικής ποιότητας, μια best practice που χρησιμοποιείται ευρέως σε πραγματικές Dockerfiles και μια βασική δεξιότητα για την παραγωγή αποδοτικών, ασφαλών containerized εφαρμογών.