Docker BuildKit: Optimalkan Build Time dengan Cache Mounting dan Multi-Stage

Build pertama pakai Dockerfile yang kompleks bisa makan waktu 10-15 menit. Build kedua? Sama saja — 10-15 menit lagi. Kenapa? Karena Docker gak punya cara untuk cache dependency resolution di luar layer image.

Masalah umum di Docker build: nge-build container untuk project monorepo yang pakai 20+ dependencies. Setiap kali ubah satu baris kode, entire build ulang dari scratch. Solusinya ada di Docker BuildKit dengan fitur-fitur yang bisa kurangi build time hingga 70%.

Kenapa BuildKit?

BuildKit adalah build engine baru untuk Docker. Dibanding Docker build engine lama, BuildKit punya beberapa keunggulan kritis:

Feature	Docker Build (Legacy)	BuildKit
Parallel builds	Sequential	Parallel
Cache mounts	Tidak ada	--mount=type=cache
Secret mounts	Tidak ada	--mount=type=secret
SSH mounts	Tidak ada	--mount=type=ssh
Output formats	Image only	Image + registry + local

Untuk mengaktifkan BuildKit:

# Method 1: Environment variable
export DOCKER_BUILDKIT=1

# Method 2: Docker daemon config
# /etc/docker/daemon.json
{
  "features": {
    "buildkit": true
  }
}

# Method 3: Build command
docker buildx build --load -t myapp .

Cache Mounting: The Game Changer

Fitur paling powerful di BuildKit adalah cache mounting. Ini memungkinkan lo mount directory cache di luar Docker image, sehingga dependency resolution tidak perlu diulang setiap build.

Contoh nyata — ini Dockerfile gw sebelum dan sesudah pakai cache mounting:

SEBELUM (tanpa cache mounting):

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

Setiap kali ada perubahan kode, npm ci dijalankan ulang dari awal. Build time: ~8 menit.

SESUDAH (dengan cache mounting):

# syntax=docker/dockerfile:1.4
FROM node:20-alpine
WORKDIR /app

# Cache npm downloads di luar image layer
RUN --mount=type=cache,target=/root/.npm \
    --mount=type=cache,target=/app/node_modules \
    npm ci

COPY . .
RUN --mount=type=cache,target=/app/node_modules \
    --mount=type=cache,target=/root/.npm \
    npm run build

Build time: ~2 menit. Pengurangan 75%.

Multi-Stage Build: Minimal Image Size

Multi-stage build memungkinkan lo pakai image besar untuk build dan image kecil untuk runtime. Hasilnya image production yang lebih kecil dan lebih aman.

# syntax=docker/dockerfile:1.4

# Stage 1: Build
FROM node:20-alpine AS builder
WORKDIR /app

RUN --mount=type=cache,target=/root/.npm \
    --mount=type=cache,target=/app/node_modules \
    npm ci

COPY . .
RUN npm run build

# Stage 2: Production
FROM node:20-alpine AS production
WORKDIR /app

COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY package.json .

EXPOSE 3000
CMD ["node", "dist/index.js"]

Perbandingan size:

Image	Size	Vulnerabilities
node:20-alpine (single stage)	345MB	12
Multi-stage production	89MB	3

Real-World Benchmark

Gw benchmark di project monorepo dengan kondisi sebagai berikut:

Metric	Before	After BuildKit	Improvement
First build	12m 34s	12m 34s	0%
Cached build (no code change)	12m 34s	0m 45s	94%
Cached build (code change)	12m 34s	2m 15s	82%
Image size	512MB	128MB	75%
CI/CD pipeline (monthly)	$45	$12	73%

Secret Management dengan BuildKit

Fitur lain yang powerful: secret mounting. Lo bisa pakai secrets saat build tanpa menambahkannya ke image layer.

# syntax=docker/dockerfile:1.4
FROM node:20-alpine

# Secret hanya available saat build step ini
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc \
    npm ci

# TIDAK ada secret di image final
# TIDAK ada secret di layer history

Build dengan secret:

docker buildx build \
    --secret id=npmrc,src=$HOME/.npmrc \
    -t myapp .

Ini jauh lebih aman daripada pakai COPY .npmrc yang akan meninggalkan credentials di layer image.

Best Practices

• Always use --mount=type=cache untuk dependency managers (npm, pip, cargo)
• Copy lockfile first — package-lock.json atau Cargo.lock harus di-copy sebelum source code
• Use .dockerignore untuk exclude node_modules, .git, dan build artifacts
• Order layers by change frequency — yang jarang berubah di atas, yang sering berubah di bawah
• Multi-stage for everything — tidak ada alasan untuk pakai single stage di production

BuildKit bukan cuma upgrade — ini fundamental shift dalam cara approach Docker builds. Kalau lo masih pakai Docker build engine lama, saatnya upgrade. Untuk memahami bagaimana Docker container logging bekerja setelah build, cek juga perbandingan ELK vs Loki untuk monitoring container logs.