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:49] – [Problématique] qduchemitechnique:docker:good_practices:init [2020/10/13 16:03] (Version actuelle) – qduchemi
Ligne 1: Ligne 1:
 +{{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 7: 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 24: 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*.
Ligne 31: Ligne 34:
  
 Compose, depuis la version 3.7, adresse ce problème avec une directive très simple : Compose, depuis la version 3.7, adresse ce problème avec une directive très simple :
-```+```yaml
 services: services:
   exemple:   exemple:
Ligne 41: Ligne 44:
 Tini va :  Tini va : 
  
 +* S'exécuter en premier plan.
 * S'assurer qu'il n'y a pas de [processus zombie](https://en.wikipedia.org/wiki/Zombie_process), qui peuvent à forcer remplir la table des processus sur l'hôte. * S'assurer qu'il n'y a pas de [processus zombie](https://en.wikipedia.org/wiki/Zombie_process), qui peuvent à forcer remplir la table des processus sur l'hôte.
 * Transmettre les signaux aux enfants : comme ils n'ont pas le PID 1, alors le fonctionnement par défaut (à savoir tuer le processus s'il n'a pas installé de *handler*) fonctionne. * Transmettre les signaux aux enfants : comme ils n'ont pas le PID 1, alors le fonctionnement par défaut (à savoir tuer le processus s'il n'a pas installé de *handler*) fonctionne.
 +* Attendre la terminaison de son enfant pour terminer, même si celui-ci s'exécute en arrière plan.
 * Terminer avec le code de retour de son enfant, ce qui permet de savoir s'il y a eu une erreur ou non. * Terminer avec le code de retour de son enfant, ce qui permet de savoir s'il y a eu une erreur ou non.
  
 <bootnote>Un rôle subsidiaire du processus `init`, sur les systèmes Linux, est justement de faire le ménage dans les processus zombie.</bootnote> <bootnote>Un rôle subsidiaire du processus `init`, sur les systèmes Linux, est justement de faire le ménage dans les processus zombie.</bootnote>
  • technique/docker/good_practices/init.1602593352.txt.gz
  • de qduchemi