Ci-dessous, les différences entre deux révisions de la page.
| Les deux révisions précédentes Révision précédente | Dernière révisionLes deux révisions suivantes |
| technique:docker:good_practices:multi [2020/10/13 16:01] – [Entrypoint qui lance plusieurs services] qduchemi | technique:docker:good_practices:multi [2020/10/13 16:02] – [Entrypoint qui lance plusieurs services] qduchemi |
|---|
| <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>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 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> | <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 ? | ## Est-ce-que c'est suffisant ? |