Quelle est la différence entre CMD et ENTRYPOINT dans un Dockerfile ?

Question

Dans Dockerfiles, il y a deux commandes qui me semblent similaires : CMD et ENTRYPOINT . Mais je suppose qu'il y a une différence (subtile ?) entre les deux, sinon cela n'aurait aucun sens d'avoir deux commandes pour la même chose.

La documentation indique que pour CMD

L'objectif principal d'un CMD est de fournir des valeurs par défaut pour un conteneur en cours d'exécution.

et pour ENTRYPOINT :

Un ENTRYPOINT vous aide à configurer un conteneur que vous pouvez exécuter comme un exécutable.

Alors, quelle est la différence entre ces deux commandes ?

Answer 1

Différence entre CMD et ENTRYPOINT par intuition :

• ENTRYPOINT : commande à exécuter au démarrage du conteneur.
• CMD : commande à exécuter au démarrage du conteneur ou arguments à ENTRYPOINT si spécifié.

Oui, c'est déroutant.

Vous pouvez remplacer l'un d'entre eux lors de l'exécution de docker run.

Différence entre CMD et ENTRYPOINT par exemple :

docker run -it --rm yourcontainer /bin/bash            <-- /bin/bash overrides CMD
                                                       <-- /bin/bash does not override ENTRYPOINT
docker run -it --rm --entrypoint ls yourcontainer      <-- overrides ENTRYPOINT with ls
docker run -it --rm --entrypoint ls yourcontainer  -la  <-- overrides ENTRYPOINT with ls and overrides CMD with -la

En savoir plus sur la différence entre CMD et ENTRYPOINT :

Argument en faveur de docker run comme /bin/bash, remplace toute commande CMD que nous avons écrite dans Dockerfile.

ENTRYPOINT ne peut pas être remplacé au moment de l'exécution avec des commandes normales telles que docker run [args] . Le site args à la fin de docker run [args] sont fournis comme arguments à ENTRYPOINT. De cette façon, nous pouvons créer un container qui est comme un binaire normal tel que ls .

Ainsi, CMD peut agir en tant que paramètres par défaut pour ENTRYPOINT et ensuite nous pouvons remplacer les args de CMD par [args].

ENTRYPOINT peut être remplacé par --entrypoint .

Answer 2

Je vais ajouter ma réponse à titre d'exemple 1 qui pourrait vous aider à mieux comprendre la différence.

Supposons que nous voulions créer une image qui soit toujours exécuter une commande de mise en veille au démarrage. Nous allons créer notre propre image et spécifier une nouvelle commande :

FROM ubuntu
CMD sleep 10

Construire l'image :

docker build -t custom_sleep .
docker run custom_sleep
# sleeps for 10 seconds and exits

Et si nous voulons changer le nombre de secondes ? Nous devrions changer le Dockerfile puisque la valeur est codée en dur à cet endroit, ou remplacer la commande en fournissant une valeur différente :

docker run custom_sleep sleep 20

Bien que cela fonctionne, ce n'est pas une bonne solution, car nous avons une commande "sleep" redondante. Pourquoi redondante ? Parce que le conteneur a pour seul but de dormir Il est donc nécessaire de spécifier le sleep de manière explicite est un peu maladroite.

Essayons maintenant d'utiliser le ENTRYPOINT l'instruction :

FROM ubuntu
ENTRYPOINT sleep

Cette instruction spécifie le programme qui sera exécuté au démarrage du conteneur. .

Maintenant on peut courir :

docker run custom_sleep 20

Qu'en est-il d'une valeur par défaut ? Eh bien, vous avez bien deviné :

FROM ubuntu
ENTRYPOINT ["sleep"]
CMD ["10"]

Le site ENTRYPOINT est le programme qui sera exécuté, et la valeur passée au conteneur y sera ajoutée.

Le site ENTRYPOINT peuvent être remplacés en spécifiant un --entrypoint suivi du nouveau point d'entrée que vous souhaitez utiliser.

Pas la mienne, j'ai regardé une fois un tutoriel qui donnait cet exemple

Answer 3

Il y a de bonnes réponses à cela. Je veux l'expliquer par une démo par Doc

• CMD  définit les commandes et/ou les paramètres par défaut pour un conteneur. CMD est une instruction qu'il est préférable d'utiliser si vous avez besoin d'une commande par défaut que les utilisateurs peuvent facilement remplacer. Si un Dockerfile comporte plusieurs CMD, il applique uniquement les instructions de la dernière.
• ENTRYPOINT  est préférable lorsque vous souhaitez définir un conteneur avec un exécutable spécifique.

Vous ne pouvez pas remplacer une ENTRYPOINT  lors du démarrage d'un conteneur, sauf si vous ajoutez l'option  --entrypoint  drapeau.

1. CMD

Fichier Docker

  FROM centos:8.1.1911

  CMD ["echo", "Hello Docker"]

Résultat de la course

$ sudo docker run <image-id>
Hello Docker
$ sudo docker run <image-id> hostname   # hostname is exec to override CMD
244be5006f32

2. ENTRYPOINT

Fichier Docker

  FROM centos:8.1.1911

  ENTRYPOINT ["echo", "Hello Docker"]

Résultat de la course

$ sudo docker run <image-id>
Hello Docker
$ sudo docker run <image-id> hostname   # hostname as parameter to exec
Hello Docker hostname

3. Il existe de nombreuses situations dans lesquelles la combinaison de CMD et ENTRYPOINT serait la meilleure solution pour votre conteneur Docker. Dans de tels cas,  l'exécutable est défini avec ENTRYPOINT, tandis que CMD spécifie le paramètre par défaut.

Fichier Docker

  FROM centos:8.1.1911

  ENTRYPOINT ["echo", "Hello"]
  CMD ["Docker"]

Résultat de la course

$ sudo docker run <image-id>
Hello Docker
$ sudo docker run <image-id> Ben
Hello Ben

Answer 4

La réponse acceptée est fabuleuse pour expliquer l'histoire. Je trouve que ce tableau l'explique très bien de document officiel sur "l'interaction entre CMD et ENTRYPOINT". :

Answer 5

Je suis tombé sur ceci et au début j'ai trouvé cela vraiment déroutant pour être honnête et je pense que cette confusion vient de l'utilisation du mot "CMD" parce qu'en fait ce qui va là agit comme argument . Après avoir creusé un peu, j'ai compris comment cela fonctionne. En gros :

ENTRYPOINT --> Ce que vous spécifiez ici sera la commande à exécuter au démarrage du conteneur. Si vous omettez cette définition, docker utilisera /bin/sh -c bash pour exécuter votre conteneur.

CMD --> ce sont les arguments ajoutés à l'ENTRYPOINT sauf si l'utilisateur spécifie un argument personnalisé, c'est-à-dire docker run ubuntu <custom_cmd> dans ce cas, au lieu d'ajouter ce qui est spécifié sur l'image dans la section CMD, docker va exécuter ENTRYPOINT <custom_cmd> . Dans le cas où ENTRYPOINT n'a pas été spécifié, ce qui va ici sera transmis à /bin/sh -c agissant en fait comme la commande à exécuter lors du démarrage du conteneur.

Comme tout, il est préférable d'expliquer ce qui se passe par des exemples. Disons que je crée une image docker simple en utilisant les spécifications suivantes Dockerfile :

From ubuntu
ENTRYPOINT ["sleep"]

Ensuite, je le construis en exécutant ce qui suit :

docker build . -t testimg

Cela créera un conteneur qui dormira à chaque fois que vous l'exécuterez. Donc si je l'exécute comme suit :

docker run testimg

Je vais prendre ce qui suit :

sleep: missing operand
Try 'sleep --help' for more information.

Cela se produit parce que le point d'entrée est la commande "sleep" qui a besoin d'un argument. Donc pour résoudre ce problème, je vais juste fournir la quantité de sommeil :

docker run testimg 5

Ceci s'exécutera correctement et le conteneur sera lancé, dormira 5 secondes et sortira. Comme nous pouvons le voir dans cet exemple, docker a simplement ajouté ce qui suit le nom de l'image au binaire du point d'entrée. docker run testimg <my_cmd> . Que se passe-t-il si nous voulons passer une valeur par défaut (argument par défaut) au point d'entrée ? Dans ce cas, il suffit de le spécifier dans la balise CMD par exemple :

From ubuntu
ENTRYPOINT ["sleep"]
CMD ["10"]

Dans ce cas, si l'utilisateur ne passe aucun argument, le conteneur utilisera la valeur par défaut (10) et la passera au point d'entrée sleep.

Maintenant, utilisons simplement CMD et omettons la définition de ENTRYPOINT :

FROM ubuntu
CMD ["sleep", "5"]

Si nous reconstruisons et exécutons cette image, elle dormira pendant 5 secondes.

Donc, en résumé, vous pouvez utiliser ENTRYPOINT afin que votre conteneur agisse comme un exécutable. Vous pouvez utiliser CMD pour fournir des arguments par défaut à votre point d'entrée ou pour exécuter une commande personnalisée au démarrage de votre conteneur qui peut être remplacée par l'utilisateur depuis l'extérieur.