Docker Multi-Stage Build: Perkecil Image Node.js Hingga 80%

Image Docker yang gemuk memperlambat deployment, menghabiskan bandwidth, dan memperbesar permukaan serangan. Penyebab umumnya sederhana: compiler, devDependencies, dan source code ikut terbawa ke image produksi. **Multi-stage build** menyelesaikannya dengan memisahkan tahap *build* dari tahap *runtime*. ## Konsep dasarnya Satu Dockerfile boleh punya beberapa `FROM`. Setiap `FROM` memulai tahap baru, dan Anda hanya menyalin artefak yang dibutuhkan ke tahap akhir. Semua yang tidak disalin akan dibuang. ## Contoh untuk aplikasi Node.js + TypeScript ```dockerfile # Tahap 1: build FROM node:22-alpine AS build WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . RUN npm run build # Tahap 2: runtime FROM node:22-alpine WORKDIR /app ENV NODE_ENV=production COPY package*.json ./ RUN npm ci --omit=dev COPY --from=build /app/dist ./dist USER node CMD ["node", "dist/index.js"] ``` ## Kenapa urutannya penting - **`COPY package*.json` sebelum `COPY . .`** membuat layer `npm ci` ter-cache selama dependensi tidak berubah. Build ulang jadi jauh lebih cepat. - **`npm ci --omit=dev`** di tahap akhir membuang devDependencies. - **`USER node`** menjalankan proses sebagai non-root, sehingga dampak kerentanan lebih terbatas. ## Jangan lupa `.dockerignore` ``` node_modules .git .env dist ``` File `.env` yang ikut ter-copy ke image adalah kebocoran rahasia yang sangat umum. Selalu kecualikan, dan berikan konfigurasi lewat environment variable saat runtime. ## Hasil yang realistis Image tunggal berbasis `node:22` penuh dengan source dan devDependencies sering mencapai ratusan MB. Dengan Alpine dan multi-stage, ukurannya biasanya turun drastis. Angka pastinya bergantung pada aplikasi, jadi ukur dengan `docker image ls` sebelum dan sesudah. ## Kesimpulan Multi-stage build hanya butuh beberapa baris tambahan, tetapi hasilnya langsung terasa pada kecepatan CI/CD dan keamanan. Terapkan sebagai standar di semua layanan Anda.