Ici avec l'entrypooint ça veut dire que tout ce que tu rajoutes au docker run sera envoyé dans cmd et entrypoint + cmd est executé.
De mémoire, l’entrypoint est aussi exécuté quand tu fais un docker exec (ce qui t’empêche de rentrer dans ton container pour le débuger), non ?
A partir du moment où on commence à rentrer des notions d'init dans les conteneurs faut se poser des questions sur ce qu'on fait et pourquoi. Il peut y avoir des cas où c'est nécessaire, mais plutôt rare et à éviter.
dumb-init n’est pas un init classique, il ne gère pas de service, il ne fait qu’exécuter une commande, lui passer les signaux qu’il reçoit et s’occuper du « reaping » de Zombie.
Il est utile dans tout les cas ou tu veux pouvoir envoyer un signal à ton application alors que celui-ci ne le « trap » pas explicitement et tous les cas où il peut y avoir des sous-processus. Presque tout le temps en fait.
Dans Kubernetes tu as un peu la même chose avec le container pause qui fait le même travail (mais comme l’espace de nom des PID n’est pas partagé par défaut entre les différent containers d’un pod, dumb-init reste quand même utile dans ce contexte).
[^] # Re: up
Posté par Anonyme . En réponse au journal docker multi-stage build. Évalué à 2.
De mémoire, l’entrypoint est aussi exécuté quand tu fais un
docker exec(ce qui t’empêche de rentrer dans ton container pour le débuger), non ?dumb-initn’est pas un init classique, il ne gère pas de service, il ne fait qu’exécuter une commande, lui passer les signaux qu’il reçoit et s’occuper du « reaping » de Zombie.Il est utile dans tout les cas ou tu veux pouvoir envoyer un signal à ton application alors que celui-ci ne le « trap » pas explicitement et tous les cas où il peut y avoir des sous-processus. Presque tout le temps en fait.
Dans Kubernetes tu as un peu la même chose avec le container
pausequi fait le même travail (mais comme l’espace de nom des PID n’est pas partagé par défaut entre les différent containers d’un pod,dumb-initreste quand même utile dans ce contexte).