D'après la doc :

don't confuse RUN with CMD.

RUN actually runs a command and commits the result;

CMD does not execute anything at build time, but specifies the intended command for the image.

An ENTRYPOINT helps you to configure a container that you can run as an executable. That is, when you specify an ENTRYPOINT, then the whole container runs as if it was just that executable.

Unlike the behavior of the CMD instruction, The ENTRYPOINT instruction adds an entry command that will not be overwritten when arguments are passed to docker run. This allows arguments to be passed to the entry point, i.e. docker run <image> -d will pass the -d argument to the entry point.

You can specify parameters either in the ENTRYPOINT JSON array (as in "like an exec" above), or by using a CMD instruction. Parameters in the ENTRYPOINT instruction will not be overridden by the docker run arguments, but parameters specified via a CMD instruction will be overridden by docker run arguments.

Le RUN sert à build l'image

Le CMD et l'ENTRYPOINT servent au moment du docker run
Donc au final, il vaut mieux avoir un ENTRYPOINT avec des paramètres qu'on ne peut pas écraser (non overridable)
Pourquoi pas un CMD avec des paramètres par défauts overridable

docker dispo sur le lab d'online

Use automated builds linked to Github-based Dockerfiles rather than pushing local image builds. Not only does this make the Dockerfile transparently available and provide a link to the repository where one can file issues, but it also helps ensure that the image available on the hub gets its base image (FROM entry) from the hub instead of whatever was available locally. This can help avoid various out-of-sync errors that might otherwise emerge.

via skunnyk

Interdasting

Un autre article prise en main

Quelques best practice concernant les Dockerfile
On peut se servir de Docker de plein de façon différentes, alors quelques repères ça ne fait pas mal