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

hebergement à base de docker

Encore une discussion intéressante sur les perf de graphite. Ce qu'il faut retenir c'est que le botteneck peut se situer au niveau du CPU ou au niveau du disque (la RAM en général ce n'est pas un probleme, meme si bien sur, il faut la surveiller)

Pour connaitre l'utilisation du CPU de carbon-cache, une metric est envoyé par le daemon dans carbon.agents.graphite-x.cpuUsage

Pour connaitre l'utilisation du disk, on se sert de iostat -dmx 1 2 (merci arnaud)

Si le disque est trop haut (entre 50 et 75), il faut le soulager en baissant dans la conf de carbon le max update par seconde.

Ce qui aura pour effet d'augmenter la taille du cache et donc de faire plus travailler le CPU..

Au contraire si le CPU est chargé mais que le disque ne fait rien, il faut augmenter le max update par seconde.

En trouvant le bon équilibre on peut exploiter au maximum le hardware disponible

une liste de jeux, yen a surement des biens à tester

Encore des liens devops, toujours via arnaudb (https://arnaudb.net/)