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:50] – [Solution] 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 8: Ligne 10:
 Autre problème, même si la commande s'exécute en premier plan, elle porte le PID 1. Autre problème, même si la commande s'exécute en premier plan, elle porte le PID 1.
  
-<bootnote>Le premier processus d'un conteneur (de PID 1) est souvent référence comme `init`, en référence [aux systèmes Unix](https://fr.wikipedia.org/wiki/Init).</bootnote>+<bootnote>Le premier processus d'un conteneur (de PID 1) est souvent référencé comme `init`, en référence [aux systèmes Unix](https://fr.wikipedia.org/wiki/Init).</bootnote>
  
 Ce processus est le parent de tous les autres, et doit transmettre les signaux qu'il reçoit à ses enfants (par exemple, un signal de terminaison). Ce processus est le parent de tous les autres, et doit transmettre les signaux qu'il reçoit à ses enfants (par exemple, un signal de terminaison).
  
 <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.1602593435.txt.gz
  • de qduchemi