technique:docker:good_practices:init

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision		 Révision précédente
technique:docker:good_practices:init [2020/10/13 14:51] – qduchemitechnique:docker:good_practices:init [2020/10/13 16:03] (Version actuelle) – qduchemi
Ligne 1: Ligne 1:
 {{indexmenu_n>25}} {{indexmenu_n>25}}
 # Utiliser un système d'initialisation # Utiliser un système d'initialisation
 +
 +<bootnote warning>Si vous utilisez un script shell comme entrypoint, la documentation sur [[technique:docker:good_practices:multi|les entrypoints et les processus multiples]] sera utile en premier lieu.</bootnote>
  
 ## Problématique ## Problématique
Ligne 13: Ligne 15:
  
 <bootnote> <bootnote>
-Un peu d'explications : un **signal**, au sens Linux, est une sorte de notifications asynchrone que l'on peut envoyer à un processus. Il existe de nombreux signaux, par exemple :+Un peu d'explications : un **signal**, au sens Linux, est une sorte de notification asynchrone que l'on peut envoyer à un processus. Il existe de nombreux signaux, par exemple :
    * `SIGTERM`, pour demander à un processus de se terminer    * `SIGTERM`, pour demander à un processus de se terminer
    * `SIGINT`, envoyé avec un `Ctrl+C`, par exemple    * `SIGINT`, envoyé avec un `Ctrl+C`, par exemple
Ligne 25: Ligne 27:
 Sauf... pour le processus de PID 1. Dans ce cas, il n'y a pas de comportement par défaut. Sauf... pour le processus de PID 1. Dans ce cas, il n'y a pas de comportement par défaut.
  
-<bootnote important>Concrètement, lorsque l'on fait un `docker stop`, un `SIGTERM` est envoyé au processus de PID 1. Si celui-ci n'a pas de *handler* pour `SIGTERM`, il ne se passe rien, et au bout d'un timeout assez long (~30 secondes), Docker envoie un `SIGKILL`.</bootnote>+<bootnote important>Concrètement, lorsque l'on fait un `docker stop`, un `SIGTERM` est envoyé au processus de PID 1. Si celui-ci n'a pas de *handler* pour `SIGTERM`, il ne se passe rien car il n'y a pas de comportement par défaut, et au bout d'un timeout assez long (~30 secondes), Docker envoie un `SIGKILL`.</bootnote>
  
 Or, la plupart des applications lancées avec le PID 1 (par exemple Python) n'ont pas de *handlers*. Or, la plupart des applications lancées avec le PID 1 (par exemple Python) n'ont pas de *handlers*.
  • technique/docker/good_practices/init.1602593463.txt.gz
  • de qduchemi