ENTRYPOINT ve CMD arasındaki fark nedir?

Question

Accepted Answer

**ENTRYPOINT** ve **CMD** her ikisi de konteyner başladığında ne çalışacağını tanımlar, ancak farklı roller oynarlar ve belirli şekillerde etkileşim halindedirler. Aralarındaki farkı anlama (ve iki form — exec vs shell) — Dockerfiles yazarken doğru davranması için önemlidir.

## CMD — varsayılan komut (geçersiz kılınabilir)

```dockerfile
CMD ["node", "server.js"]
# → the DEFAULT command when the container starts
# → but it's REPLACED if you pass a command at run time:
#   docker run myapp echo hello   → runs "echo hello" INSTEAD of node server.js
```

`CMD` **varsayılan komutu** sağlar; bu komut `docker run` ile verilen herhangi bir komut tarafından **tamamen geçersiz kılınır**.

## ENTRYPOINT — sabit yürütülebilir

```dockerfile
ENTRYPOINT ["node", "server.js"]
# → ALWAYS runs; run-time arguments are APPENDED (not replacing it):
#   docker run myapp --port 8080   → runs "node server.js --port 8080"
# → makes the container behave like a specific executable
```

`ENTRYPOINT` her zaman çalışan **sabit bir yürütülebilir** ayarlar; çalışma zamanı argümanları onu **değiştirmek yerine** argümanları olarak **eklenir**.

## Onları birlikte kullanma (yaygın model)

```dockerfile
ENTRYPOINT ["node", "server.js"]   # the fixed command
CMD ["--port", "3000"]              # DEFAULT arguments (overridable)
# docker run myapp                  → node server.js --port 3000 (defaults)
# docker run myapp --port 8080      → node server.js --port 8080 (CMD overridden)
→ ENTRYPOINT = the command; CMD = default arguments you can override. A clean pattern.
```

## Exec form vs shell form

```text
EXEC form  → CMD ["node", "server.js"]  (JSON array) — PREFERRED:
  runs the executable DIRECTLY (PID 1) → receives signals (SIGTERM) → graceful shutdown
SHELL form → CMD node server.js  → runs via /bin/sh -c → the shell is PID 1,
  the app may NOT receive signals properly (shutdown issues) → avoid for the main process
```

## Neden önemli

ENTRYPOINT ve CMD arasındaki farkı anlamak, **doğru davranış gösteren Dockerfiles yazma** için önemlidir ve bu değerli pratik bilgidir ve sık karıştırılan bir konudur.

Davranıştaki ayırım önemlidir: **CMD** **tamamen geçersiz kılınan** `docker run` ile geçirilen herhangi bir komut tarafından sağlanan varsayılan bir komut sağlarken, **ENTRYPOINT** çalışma zamanı argümanlarının kendisine **eklenmesi** ile her zaman çalışan sabit bir yürütülebilir ayarlar — konteyner çalışma zamanı argümanlarına nasıl yanıt verecek seçer davranışlar.

Onları birlikte kullanmanın **yaygın modelini anlama** (ENTRYPOINT komut olarak ve CMD geçersiz kılınabilir varsayılan argümanlar olarak) konteynerları yapılandırılabilir yürütülebilirler gibi davranacak şekilde yapan temiz, deyimsel bir yaklaşımdır — yaygın kullanılan ve bilmeye değer bir tekniktir.

Kritik olarak, **exec form vs shell form** anlaması doğruluk için önemlidir: **exec form** (JSON dizisi, örneğin `CMD ["node", "server.js"]`) tercih edilir çünkü yürütülebilir dosyayı **doğrudan PID 1 olarak çalıştırır**, bu nedenle **SIGTERM gibi sinyalleri alır** doğru şekilde, **zarif kapatma** sağlayarak — whereas **shell form** (`CMD node server.js`) PID 1 haline gelen bir kabuk aracılığıyla çalışır, genellikle uygulamanın **kapatma sinyallerini doğru şekilde almamasına** neden olur (kibar olmayan sonlandırma, kayıp havayolcu çalışması veya yavaş durdurma içinde sonuçlanır).

Bu sinyal işleme/zarif kapatma sorunu, exec form'un önlediği gerçek, ince bir sorundur.

Her Dockerfile'de ne çalışacağını tanımlamak temel olduğundan ve ENTRYPOINT/CMD ayırımı (ve exec-vs-shell-form sinyal işleme endişesi) konteyner davranışını ve doğruluğunu doğrudan etkilediğinden (argüman işleme, zarif kapatma), ENTRYPOINT vs CMD anlamı — rolleri, nasıl birleştiği ve sinyaller için exec-form-uygulaması pratik — değerli, pratik olarak ilgili Docker bilgisidir, farkları anlama gerçek davranışsal ve kapatma hatalarını önler, yaygın olarak yanlış anlaşılan bir konu.