Depends On #

Dalam arsitektur berbasis container, aplikasi jarang berdiri sendiri. Hampir selalu ada dependensi: database, message broker, cache, atau service lain yang harus tersedia agar aplikasi dapat berjalan dengan benar. Docker Compose menyediakan fitur depends_on untuk mendefinisikan urutan ketergantungan antar service.

Namun, banyak kesalahpahaman umum terkait depends_on, terutama anggapan bahwa fitur ini menjamin service sudah siap digunakan. Artikel ini akan membahas secara mendalam apa itu depends_on, bagaimana cara kerjanya, keterbatasannya, serta best practice penggunaannya di lingkungan development hingga production.

Apa Itu depends_on? #

depends_on adalah directive di Docker Compose yang digunakan untuk menentukan service mana yang harus dijalankan terlebih dahulu sebelum service lain dijalankan.

Dengan kata lain:

• depends_on mengatur startup order
• Bukan readiness atau health secara otomatis (kecuali dikombinasikan dengan mekanisme tertentu)

Contoh sederhana:

version: "3.9"
services:
  app:
    image: my-app
    depends_on:
      - db

  db:
    image: postgres:16

Artinya:

• Docker Compose akan menjalankan container db lebih dulu
• Setelah itu baru menjalankan container app

Cara Kerja depends_on #

Secara internal, Docker Compose melakukan hal berikut:

1. Membaca dependency graph antar service
2. Menjalankan service tanpa dependency terlebih dahulu
3. Menjalankan service yang memiliki dependency setelah container dependency berstatus running

⚠️ Penting:

• Running ≠ Ready
• Database bisa saja masih melakukan initialization
• Service bisa hidup, tapi belum menerima koneksi

Evolusi depends_on: v2 vs v3 #

Docker Compose v2 (legacy) #

Pada Compose versi lama, depends_on hanya mendukung daftar service:

depends_on:
  - db
  - redis

Tidak ada mekanisme untuk mengecek kondisi service.

Docker Compose v2.1+ (condition) #

Compose memperkenalkan condition-based dependency:

depends_on:
  db:
    condition: service_healthy

Condition yang tersedia:

• service_started
• service_healthy
• service_completed_successfully

Namun:

• Fitur ini tidak didukung di Compose v3 (Swarm mode)
• Banyak user tidak menyadari perbedaan ini

depends_on di Docker Compose v3 #

Pada Compose v3 (umum dipakai saat ini):

• depends_on hanya mengatur urutan startup
• Tidak mendukung condition

Contoh valid v3:

depends_on:
  - db

Contoh tidak valid di v3:

depends_on:
  db:
    condition: service_healthy

Masalah Umum Jika Mengandalkan depends_on #

1. Aplikasi Gagal Start #

Service app mencoba koneksi ke database yang belum siap.

2. Race Condition #

Container berjalan cepat, tapi dependency lambat.

3. False Sense of Safety #

Developer mengira depends_on sudah cukup untuk production.

Menggabungkan depends_on dengan healthcheck #

Walaupun Compose v3 tidak mendukung condition, healthcheck tetap sangat penting.

Contoh Healthcheck Database #

services:
  db:
    image: postgres:16
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

Healthcheck ini:

• Tidak otomatis memblokir service lain
• Tapi bisa dimanfaatkan oleh script atau entrypoint

Best Practice: Wait-for Strategy #

Karena depends_on tidak menjamin readiness, solusi umum adalah menunggu dependency secara eksplisit.

1. Wait-for-it Script #

Aplikasi menunggu port tertentu sebelum start:

./wait-for-it.sh db:5432 -- ./app

2. Dockerize #

dockerize -wait tcp://db:5432 -timeout 30s ./app

3. Custom EntryPoint #

until nc -z db 5432; do
  echo "Waiting for database..."
  sleep 2
done

./app

Contoh Docker Compose yang Lebih Aman #

version: "3.9"
services:
  app:
    image: my-app
    depends_on:
      - db
    entrypoint: ["/wait-for-it.sh", "db:5432", "--", "./app"]

  db:
    image: postgres:16

Di sini:

• depends_on mengatur urutan
• Script memastikan database siap

depends_on untuk Development vs Production #

Development #

Cocok digunakan untuk:

• Local environment
• Demo
• Integration testing ringan

Production #

Tidak disarankan mengandalkan depends_on saja.

Di production:

• Gunakan orchestrator (Kubernetes, ECS, Nomad)
• Gunakan readiness & liveness probe
• Aplikasi harus resilient terhadap retry

Anti-Pattern yang Perlu Dihindari #

❌ Mengira depends_on = service ready

❌ Tidak ada retry logic di aplikasi

❌ Hard-coded sleep (sleep 30) tanpa check

❌ Menggunakan Compose sebagai orchestrator production skala besar

Decision Guide #

Gunakan depends_on jika:

• Ingin startup order jelas
• Lingkungan development atau CI

Tambahkan mekanisme tambahan jika:

• Ada database, broker, atau external service
• Ingin menghindari race condition

Penutup #

depends_on di Docker Compose adalah fitur penting, tetapi bukan solusi lengkap untuk dependency management.

Intinya:

• depends_on → urutan startup
• healthcheck → status container
• Wait-for / retry → readiness sesungguhnya

Memahami batasan ini akan membantu kamu membangun environment Docker yang lebih stabil, predictable, dan mendekati production-grade.