tutorial - tuto docker windows




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

C'est probablement la meilleure description que j'ai trouvée: https://www.ctl.io/developers/blog/post/dockerfile-entrypoint-vs-cmd/

J'ai eu un résumé ici mais les gens ont gardé downvoting sans donner une raison, donc j'ai supprimé.

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

Les états de documentation 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 en tant qu'exécutable.

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


CMD:

  • CMD ["executable","param1","param2"] : ["executable","param1","param2"] est le premier processus.
  • CMD command param1 param2 : /bin/sh -c CMD command param1 param2 est le premier processus. CMD command param1 param2 est dérivée du premier processus.
  • CMD ["param1","param2"] : Ce formulaire est utilisé pour fournir des arguments par défaut pour ENTRYPOINT .

ENTRYPOINT (La liste suivante ne considère pas le cas où CMD et ENTRYPOINT sont utilisés ensemble):

  • ENTRYPOINT ["executable", "param1", "param2"] : ["executable", "param1", "param2"] est le premier processus.
  • ENTRYPOINT command param1 param2 : /bin/sh -c command param1 param2 est le premier processus. command param1 param2 est forkée depuis le premier processus.

Comme l'a dit , CMD a été développé en premier. Alors ENTRYPOINT a été développé pour plus de personnalisation. Comme ils ne sont pas conçus ensemble, il existe des chevauchements de fonctionnalités entre CMD et ENTRYPOINT, ce qui souvent déroutent les gens.


Différence entre CMD et ENTRYPOINT par intuition :

  • ENTRYPOINT: commande à exécuter lorsque le conteneur démarre.
  • CMD: commande à exécuter lorsque le conteneur démarre ou arguments à ENTRYPOINT si spécifié.

Oui, ça se mélange.

Vous pouvez remplacer l'un d'entre eux lors de l'exécution du menu fixe.

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

Plus d'informations sur la différence entre CMD et ENTRYPOINT :

L'argument de l' docker run tel que / bin / bash remplace toute commande CMD que nous avons écrite dans Dockerfile.

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

Ainsi CMD peut agir comme paramètres par défaut à ENTRYPOINT et ensuite nous pouvons remplacer les arguments CMD de [args].

ENTRYPOINT peut être --entrypoint par --entrypoint .


Docker a un entrypoint par défaut qui est /bin/sh -c mais n'a pas de commande par défaut.

Lorsque vous exécutez docker comme ceci: docker run -i -t ubuntu bash l'entrypoint est la valeur par défaut /bin/sh -c , l'image est ubuntu et la commande est bash .

La commande est exécutée via l'entrypoint. c'est-à-dire que la chose qui est exécutée est /bin/sh -c bash . Cela a permis à Docker d'implémenter RUN rapidement en s'appuyant sur l'analyseur du shell.

Plus tard, les gens ont demandé à pouvoir personnaliser cela, donc ENTRYPOINT et -entrypoint ont été introduits.

Tout ce qui suit ubuntu dans l'exemple ci-dessus est la commande et est passé à l'entrypoint. Lorsque vous utilisez l'instruction CMD , c'est exactement comme si vous étiez en train d' docker run -i -t ubuntu <cmd> . <cmd> sera le paramètre de l'entrypoint.

Vous obtiendrez également le même résultat si vous tapez à la place cette commande docker run -i -t ubuntu . Vous allez toujours démarrer un shell bash dans le conteneur en raison du fichier Docker Ubuntu spécifié un CMD par défaut: CMD ["bash"]

Comme tout est passé à l'entrypoint, vous pouvez avoir un très bon comportement de vos images. L'exemple @Jiri est bon, il montre comment utiliser une image comme un "binaire". Lorsque vous utilisez ["/bin/cat"] comme entrypoint puis que vous docker run img /etc/passwd , vous l'obtenez, /etc/passwd est la commande et est transmise à l'entrypoint donc l'exécution du résultat final est simplement /bin/cat /etc/passwd .

Un autre exemple serait d'avoir n'importe quel cli comme entrypoint. Par exemple, si vous avez une image redis, au lieu d'exécuter docker run redisimg redis -H something -u toto get key , vous pouvez simplement avoir ENTRYPOINT ["redis", "-H", "something", "-u", "toto"] et exécutez ensuite comme ceci pour le même résultat: docker run redisimg get key .



Le ENTRYPOINT spécifie une commande qui sera toujours exécutée au démarrage du conteneur.

Le CMD spécifie les arguments qui seront ENTRYPOINT à ENTRYPOINT .

Si vous voulez créer une image dédiée à une commande spécifique, vous utiliserez ENTRYPOINT ["/path/dedicated_command"]

Sinon, si vous souhaitez créer une image à des fins générales, vous pouvez laisser ENTRYPOINT non spécifié et utiliser CMD ["/path/dedicated_command"] car vous pourrez remplacer le paramètre en fournissant des arguments à l' docker run .

Par exemple, si votre Dockerfile est:

FROM debian:wheezy
ENTRYPOINT ["/bin/ping"]
CMD ["localhost"]

L'exécution de l'image sans argument pingera l'hôte local:

$ docker run -it test
PING localhost (127.0.0.1): 48 data bytes
56 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.096 ms
56 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.088 ms
56 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.088 ms
^C--- localhost ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.088/0.091/0.096/0.000 ms

Maintenant, exécuter l'image avec un argument pingera l'argument:

$ docker run -it test google.com
PING google.com (173.194.45.70): 48 data bytes
56 bytes from 173.194.45.70: icmp_seq=0 ttl=55 time=32.583 ms
56 bytes from 173.194.45.70: icmp_seq=2 ttl=55 time=30.327 ms
56 bytes from 173.194.45.70: icmp_seq=4 ttl=55 time=46.379 ms
^C--- google.com ping statistics ---
5 packets transmitted, 3 packets received, 40% packet loss
round-trip min/avg/max/stddev = 30.327/36.430/46.379/7.095 ms

A titre de comparaison, si votre Dockerfile est:

FROM debian:wheezy
CMD ["/bin/ping", "localhost"]

L'exécution de l'image sans argument pingera l'hôte local:

$ docker run -it test
PING localhost (127.0.0.1): 48 data bytes
56 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.076 ms
56 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.087 ms
56 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.090 ms
^C--- localhost ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.076/0.084/0.090/0.000 ms

Mais exécuter l'image avec un argument lancera l'argument:

docker run -it test bash
[email protected]:/#

Voir cet article de Brian DeHamer pour encore plus de détails: https://www.ctl.io/developers/blog/post/dockerfile-entrypoint-vs-cmd/


Selon les documents docker ,

Les instructions CMD et ENTRYPOINT définissent la commande exécutée lors de l'exécution d'un conteneur. Il y a peu de règles qui décrivent leur coopération.

  1. Dockerfile doit spécifier au moins l'une des commandes CMD ou ENTRYPOINT .
  2. ENTRYPOINT doit être défini lors de l'utilisation du conteneur en tant qu'exécutable.
  3. CMD doit être utilisé pour définir des arguments par défaut pour une commande ENTRYPOINT ou pour exécuter une commande ad-hoc dans un conteneur.
  4. CMD sera remplacé lors de l'exécution du conteneur avec des arguments alternatifs.

Les tableaux ci-dessous montrent quelle commande est exécutée pour différentes combinaisons ENTRYPOINT / CMD :

- No ENTRYPOINT

╔════════════════════════════╦═════════════════════════════╗
║ No CMD                     ║ error, not allowed          ║
╟────────────────────────────╫─────────────────────────────╢
║ CMD [“exec_cmd”, “p1_cmd”] ║ exec_cmd p1_cmd             ║
╟────────────────────────────╫─────────────────────────────╢
║ CMD [“p1_cmd”, “p2_cmd”]   ║ p1_cmd p2_cmd               ║
╟────────────────────────────╫─────────────────────────────╢
║ CMD exec_cmd p1_cmd        ║ /bin/sh -c exec_cmd p1_cmd  ║
╚════════════════════════════╩═════════════════════════════╝

- ENTRYPOINT exec_entry p1_entry

╔════════════════════════════╦═══════════════════════════════════════════════════════════╗
║ No CMD                     ║ /bin/sh -c exec_entry p1_entry                            ║
╟────────────────────────────╫───────────────────────────────────────────────────────────╢
║ CMD [“exec_cmd”, “p1_cmd”] ║ /bin/sh -c exec_entry p1_entry exec_cmd p1_cmd            ║
╟────────────────────────────╫───────────────────────────────────────────────────────────╢
║ CMD [“p1_cmd”, “p2_cmd”]   ║ /bin/sh -c exec_entry p1_entry p1_cmd p2_cmd              ║
╟────────────────────────────╫───────────────────────────────────────────────────────────╢
║ CMD exec_cmd p1_cmd        ║ /bin/sh -c exec_entry p1_entry /bin/sh -c exec_cmd p1_cmd ║
╚════════════════════════════╩═══════════════════════════════════════════════════════════╝

- ENTRYPOINT [“exec_entry”, “p1_entry”]

╔════════════════════════════╦═════════════════════════════════════════════════╗
║ No CMD                     ║ exec_entry p1_entry                             ║
╟────────────────────────────╫─────────────────────────────────────────────────╢
║ CMD [“exec_cmd”, “p1_cmd”] ║ exec_entry p1_entry exec_cmd p1_cmd             ║
╟────────────────────────────╫─────────────────────────────────────────────────╢
║ CMD [“p1_cmd”, “p2_cmd”]   ║ exec_entry p1_entry p1_cmd p2_cmd               ║
╟────────────────────────────╫─────────────────────────────────────────────────╢
║ CMD exec_cmd p1_cmd        ║ exec_entry p1_entry /bin/sh -c exec_cmd p1_cmd  ║
╚════════════════════════════╩═════════════════════════════════════════════════╝




docker