ما الفرق بين ENTRYPOINT و CMD؟

Question

Accepted Answer

**ENTRYPOINT** و **CMD** كلاهما يحدد ما يتم تشغيله عند بدء الحاوية، لكنهما يلعبان أدوارًا مختلفة ويتفاعلان بطرق محددة. فهم الفرق (والشكلان — exec مقابل shell) مهم لكتابة Dockerfiles التي تتصرف بشكل صحيح.

## CMD — الأمر الافتراضي (قابل للتجاوز)

```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` يوفر **الأمر الافتراضي**، والذي يتم **تجاوزه بالكامل** بواسطة أي أمر مُعطى على `docker run`.

## ENTRYPOINT — المُنفّذ الثابت

```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` يحدد **مُنفّذًا ثابتًا** يعمل دائمًا؛ وتُضاف وسائط وقت التشغيل **كحجج له** بدلاً من استبداله.

## استخدامهما معًا (النمط الشائع)

```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 مقابل شكل shell

```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
```

## لماذا هذا مهم

فهم الفرق بين ENTRYPOINT و CMD مهم لـ **كتابة Dockerfiles التي تتصرف بشكل صحيح**، لذلك فهو معرفة عملية قيّمة وموضوع يُساء فهمه بشكل شائع.

التمييز في السلوك مهم: **CMD** يوفر أمرًا افتراضيًا يتم **تجاوزه بالكامل** بواسطة أي أمر يُمرر إلى `docker run`، بينما **ENTRYPOINT** يحدد مُنفّذًا ثابتًا يعمل دائمًا مع وسائط وقت التشغيل **مُلحقة** به — سلوكيات مختلفة تؤثر على كيفية استجابة الحاوية لوسائط وقت التشغيل.

فهم **النمط الشائع لاستخدامهما معًا** (`ENTRYPOINT` كالأمر و `CMD` كوسائط افتراضية قابلة للتجاوز) هو نهج نظيف وواضح يجعل الحاويات تتصرف مثل المُنفّذات القابلة للتكوين — وهي تقنية مستخدمة على نطاق واسع تستحق المعرفة.

بشكل حاسم، فهم **شكل exec مقابل شكل shell** مهم للصحة: **شكل exec** (مصفوفة JSON، مثل `CMD ["node", "server.js"]`) هو الشكل المفضل لأنه ينفذ المُنفّذ **مباشرة كـ PID 1**، لذا فإنه **يستقبل الإشارات مثل SIGTERM** بشكل صحيح، مما يتيح **الإيقاف الرقيق** — بينما **شكل shell** (`CMD node server.js`) يعمل عبر shell يصبح PID 1، مما غالبًا ما يؤدي إلى **عدم استقبال التطبيق إشارات الإيقاف بشكل صحيح** (مما يؤدي إلى إنهاء غير لطيف، أو فقدان العمل قيد الطيران، أو توقفات بطيئة).

هذه المشكلة المتعلقة بمعالجة الإشارات والإيقاف الرقيق هي مشكلة حقيقية ودقيقة يتجنبها شكل exec.

بما أن تحديد ما يعمل عند بدء الحاوية أساسي لكل Dockerfile، وبما أن التمييز ENTRYPOINT/CMD (وقلق معالجة الإشارات exec-vs-shell-form) يؤثر مباشرة على سلوك وصحة الحاوية (معالجة الوسائط، الإيقاف الرقيق)، فإن فهم ENTRYPOINT مقابل CMD — أدوارهما، وكيفية دمجهما، وممارسة exec-form-for-signals المهمة — هو معرفة Docker عملية وقيّمة، وموضوع يُساء فهمه بشكل شائع حيث يمنع فهم الاختلافات أخطاء سلوكية وإيقاف حقيقية.