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 ?
À priori non.
Voici un Dockerfile avec un entrypoint qui est une boucle infinie :
FROM alpine:3.11ENTRYPOINT while :; do sleep 1; done
docker build -t loop .
CID=`docker run --rm -d loop`
docker exec -it $CID sh
/ #
build du conteneur
lancer le conteneur et récupérer son ID
exec dans le conteneur en lançant sh
Si l'entrypoint n'était pas overridé on ne pourrait pas.
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.
Je dois pas faire assez de java en conteneur alors, car je ne le vois (quasiment) jamais.
Si l'application ne gère pas les signaux c'est un problème, mais ça devrait être corrigé dans l'application et non par l'adjonction d'un init.
[^] # Re: up
Posté par CrEv (site web personnel) . En réponse au journal docker multi-stage build. Évalué à 4.
À priori non.
Voici un
Dockerfileavec un entrypoint qui est une boucle infinie :execdans le conteneur en lançantshSi l'entrypoint n'était pas overridé on ne pourrait pas.
Je dois pas faire assez de java en conteneur alors, car je ne le vois (quasiment) jamais.
Si l'application ne gère pas les signaux c'est un problème, mais ça devrait être corrigé dans l'application et non par l'adjonction d'un init.