Différences

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

--- technique:docker:good_practices:multi [2020/10/13 15:38] – [Entrypoint qui lance plusieurs services] qduchemi
+++ technique:docker:good_practices:multi [2022/05/24 20:58] (Version actuelle) – ppom
@@ Ligne 18: / Ligne 18: @@
 <bootnote question>
-Quel est le risque ?
+Quels sont les risques ?
 </bootnote>
@@ Ligne 87: / Ligne 87: @@
 L'entrypoint a été remplacé par nginx. Il reçoit correctement les signaux.
-<bootnote question>Est-ce-que c'est suffisant ?</bootnote>
-Ça ne règle pas tous les problèmes, car les processus qui ont un PID 1 sont traités spécialement. Voir la [[technique:docker:good_practices:init|documentation sur l'utilisation d'un système d'initialisation]] pour parfaire la configuration.
 ## Entrypoint qui lance plusieurs services
@@ Ligne 123: / Ligne 119: @@
 Ici, on se retrouve avec une problématique similaire : `nginx` va bien recevoir les signaux, mais ne les transmet pas à ses enfants. Et pour le coup, on ne peut pas ré-utiliser un `exec`, car `nginx` a toujours besoin de s'exécuter.
+Dans ce cas précis, il va falloir utiliser des astuces plus ou moins sales.
+<bootnote web>Docker propose une [documentation sur ce sujet](https://docs.docker.com/config/containers/multi-service_container/).</bootnote>
+En gros, il y a deux solutions :
+* Utiliser [supervisord](http://supervisord.org/). C'est plutôt la moyenne artillerie, mais ça permet de faire ce que l'on veut. `supervisord` est un processus d'initialisation, il va s'exécuter en tant que PID 1 et assumer toutes ses fonctions. C'est ce qui a été retenu pour [pica-nginx](https://gitlab.utc.fr/picasoft/projets/services/nginx).
+* Faire du cas par cas. Par exemple, si on sait qu'un processus enfant doit pouvoir recevoir un signal important, qu'on connaît à l'avance, on utilisera un `trap`.
+Les trap sont des *handlers* de signaux. On ne développe pas ce point, mais c'est la solution retenue pour [Mumble](https://gitlab.utc.fr/picasoft/projets/services/mumble).
+Voici un extrait de son entrypoint :
+```bash
+python3 /exporter.py &
+# Trap SIGUSR1 signal to reload certificates without restarting
+_reload() {
+  echo "Caught SIGUSR1 signal!"
+  /usr/bin/pkill -USR1 murmurd
+  wait
+}
+trap _reload SIGUSR1
+# Run murmur
+murmurd -v -ini $CONFIG_FILE
+wait
+```
+<bootnote>Ici, `python` et `murmurd` sont lancés en arrière plan. Le shell attend ensuite que les processus terminent. Dès qu'un signal `USR1` est reçu, il est capté par l'instruction `trap` et la fonction `_reload` s'exécute. Elle a pour effet de transmettre le signal à Murmur, puis on attend de nouveau. C'est un peu *hackish*, mais dans ce cas spécifique, c'est suffisant car on a pas réellement besoin de transmettre tous les signaux à Murmur.</bootnote>
+<bootnote warning>Dans ce cas, un `docker stop` terminera **quand même** en timeout puis en `SIGKILL`, car l'entrypoint ne fait rien du `SIGTERM`. On pourrait implémenter un *handler* pour `SIGTERM` qui l'envoie aux processus enfants, et ce serait même plus propre. C'est laissé à l'appréciation de chacun·e.</bootnote>
+## Est-ce-que c'est suffisant ?
+Dans cette page, nous avons montré comment faire en sorte que les processus d'un conteneur Docker reçoivent les signaux qui leur sont destinés.
+En revanche, ca ne règle pas tous les problèmes, car les processus qui ont un PID 1 sont traités spécialement.
+<bootnote warning>En particulier, un processus avec un PID de 1 n'a pas de comportement par défaut quand il reçoit un signal qu'il ne traite pas explicitement, ce qui peut être problématique. Voir la [[technique:docker:good_practices:init|documentation sur l'utilisation d'un système d'initialisation]] pour parfaire la configuration.</bootnote>