Setup Docker Lokal yang Cepat Buat Development Harian

Daftar Isi

Kenapa Local Docker Sering Terasa Berat Dipakai Sehari-hari?
Optimasi 1: Tulis Dockerfile yang Efisien dengan Layer Caching
Optimasi 2: Multi-Stage Build untuk Image Lebih Ringan
Optimasi 3: Docker Compose Profile untuk Fleksibilitas Service
Optimasi 4: Volume dan Bind Mount yang Tepat Guna
Aktifkan Hot Reload agar Feedback Loop Secepat Native
Ukur dan Pantau Performa Container Lokal

Kenapa Local Docker Sering Terasa Berat Dipakai Sehari-hari?

Banyak tim yang sudah pakai Docker di production, tapi enggan memakainya untuk development harian karena dianggap:

Startup container lama.
Laptop cepat panas dan kipas berisik.
Perubahan kode terasa tidak secepat saat menjalankan aplikasi langsung di host.

Sering kali masalahnya bukan di Dockernya, tapi di:

Dockerfile yang tidak ramah caching → setiap perubahan kecil memicu build ulang penuh.
Image terlalu gemuk → banyak dependency build-time ikut terbawa ke runtime.
Compose yang terlalu banyak service → semua service dinyalakan terus padahal tidak semuanya dibutuhkan saat development.
Penggunaan volume/bind mount yang kurang tepat sehingga IO jadi bottleneck (terutama di macOS/Windows dengan VM).

Kabar baiknya: dengan beberapa pengaturan sederhana, kamu bisa membuat setup Docker lokal yang:

Start cukup cepat untuk dipakai harian.
Punya feedback loop hampir setara jalankan app langsung di host.
Lebih mirip environment production (lebih sedikit “works on my machine” moment).

Optimasi 1: Tulis Dockerfile yang Efisien dengan Layer Caching

Layer caching adalah “senjata rahasia” utama untuk mempercepat build. Prinsip utamanya: semakin jarang sebuah layer berubah, semakin sering dia bisa di-reuse.

Beberapa praktik yang membantu:

Pisahkan dependency install dari copy source code
Buruk:
```
COPY . .
RUN npm install
```
Lebih baik:
```
COPY package*.json ./
RUN npm install --production=false
COPY . .
```
Jadi, saat kamu hanya mengubah kode aplikasi, layer npm install masih bisa dipakai ulang.
Urutkan instruksi dari yang paling jarang berubah
Misalnya:
1. Set base image & env dasar.
2. Install dependency sistem.
3. Install dependency aplikasi.
4. Baru copy source code.
Gunakan .dockerignore dengan benar
Pastikan folder seperti node_modules, dist, .git, dan file besar lain tidak ikut terkirim ke context build. Ini mengurangi ukuran context dan mempercepat build.

Tools seperti dive bisa membantu kamu melihat layer mana yang paling besar dan sering invalid, lalu mengatur ulang Dockerfile berdasarkan insight itu.

Optimasi 2: Multi-Stage Build untuk Image Lebih Ringan

Multi-stage build memungkinkan kamu memakai satu Dockerfile untuk:

Tahap build (pakai image berat dengan compiler, dev tools, dsb).
Tahap runtime (image kecil yang hanya berisi artifact yang sudah jadi).

Contoh pola umum untuk app Node.js:

FROM node:22 AS build
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

FROM node:22-slim AS runtime
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/package*.json ./
RUN npm install --omit=dev
CMD ["node", "dist/index.js"]

Keuntungan:

Image runtime jadi lebih kecil dan lebih cepat di-pull.
Dependency build-time (compiler, tooling) tidak ikut terbawa ke production.
Lebih mudah menjaga permukaan serangan (attack surface) lebih kecil.

Untuk development lokal, kamu bisa:

Memakai stage build untuk proses dev (dengan volume bind mount dan hot reload).
Tetap punya stage runtime yang bersih untuk testing lebih dekat ke production.

Optimasi 3: Docker Compose Profile untuk Fleksibilitas Service

Sering kali kita menulis docker-compose.yml yang menjalankan semua service sekaligus, padahal untuk kerja harian kamu tidak butuh semuanya (misalnya job worker, scheduler, atau admin tool).

Dengan Compose profiles, kamu bisa mengelompokkan service:

services:
  api:
    profiles: ["default"]
    # ...
  web:
    profiles: ["default"]
    # ...
  worker:
    profiles: ["worker"]
    # ...
  admin:
    profiles: ["admin"]
    # ...

Lalu jalankan sesuai kebutuhan:

Development harian: docker compose up (hanya profile default).
Saat butuh testing worker: docker compose --profile worker up.
Saat debugging admin tool: docker compose --profile admin up.

Manfaatnya:

Laptop tidak dipaksa menjalankan semua service setiap saat.
Resource (CPU, RAM, disk IO) lebih terkontrol.
Developer punya preset environment sesuai aktivitasnya tanpa harus mengedit file Compose tiap kali.

Optimasi 4: Volume dan Bind Mount yang Tepat Guna

Volume dan bind mount sangat memengaruhi performa, terutama di OS yang menjalankan Docker di dalam VM.

Beberapa prinsip praktis:

Gunakan bind mount untuk source code yang sering berubah
Supaya hot reload bisa berjalan dan kamu tidak perlu rebuild image setiap perubahan file.
Gunakan named volume untuk data yang sifatnya internal container
Misalnya data database lokal, cache build, dsb. Ini biasanya lebih cepat dan stabil dibanding bind mount ke filesystem host.
Hindari bind mount ke folder besar yang tidak perlu
Misalnya mount seluruh root project padahal hanya butuh beberapa folder. Gunakan .dockerignore dan mount yang lebih spesifik.

Kalau performa filesystem terasa lambat:

Coba batasi file yang di-watch oleh dev server (misalnya lewat pengaturan watchOptions).
Pertimbangkan untuk menjalankan database berat (Postgres, Elasticsearch) di luar Docker untuk development, jika benar-benar mengganggu performa dan tidak butuh environment 100% identik production.

Aktifkan Hot Reload agar Feedback Loop Secepat Native

Salah satu alasan orang enggan pakai Docker untuk dev adalah feedback loop yang terasa lambat. Kuncinya adalah mengkombinasikan:

Bind mount untuk source code.
Dev server dengan hot reload / live reload.

Contoh pola umum:

Di Dockerfile untuk dev, jalankan command seperti npm run dev atau uvicorn --reload.
Mount folder project dari host ke container (.:/app) sehingga perubahan file langsung terlihat oleh dev server di dalam container.

Hal-hal yang perlu diperhatikan:

Pastikan path yang di-watch dev server sesuai dengan path di dalam container, bukan path host.
Batasi jumlah file yang di-watch untuk menghindari overhead berlebihan (exclude node_modules, build output, dsb).
Jika hot reload terlalu lambat, cek apakah masalahnya di:
- Volume/bind mount yang terlalu besar.
- Dev server yang mengompilasi terlalu banyak hal di setiap perubahan.

Targetnya: waktu dari “save” sampai perubahan muncul di browser/CLI tidak jauh beda dengan saat kamu menjalankan app langsung di host tanpa Docker.

Ukur dan Pantau Performa Container Lokal

Optimasi tanpa pengukuran sering berakhir di “feels faster” tanpa jelas bedanya. Beberapa metrik sederhana yang bisa kamu pantau:

Waktu startup: Berapa detik dari docker compose up sampai service utama siap menerima request?
Penggunaan resource: CPU, RAM, dan disk IO dari masing-masing container (bisa cek dengan docker stats atau tool lain).
Ukuran image: Apakah image semakin gemuk setiap minggu? Apakah masih wajar untuk developer tarik dari registry internal?

Alur iterasi yang disarankan:

Catat baseline (startup time, ukuran image, rpm kipas laptop).
Terapkan satu optimasi (misalnya perbaiki Dockerfile untuk caching).
Ukur ulang secara objektif.
Dokumentasikan perubahan yang benar-benar memberi efek.

Dengan cara ini, setup Docker lokal tim kamu akan terus membaik secara bertahap, dan developer akan lebih nyaman menjadikannya bagian default dari workflow harian, bukan hanya dipakai saat “butuh meniru production”.