technique:docker:good_practices:multi

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
technique:docker:good_practices:multi [2020/10/13 16:02] – [Entrypoint qui lance plusieurs services] qduchemitechnique:docker:good_practices:multi [2022/05/24 20:58] (Version actuelle) – ppom
Ligne 1: Ligne 1:
 +{{indexmenu_n>30}}
 +# Gérer proprement son script d'entrypoint 
 +
 +Une pratique commune est d'utiliser un script shell en tant qu'`ENTRYPOINT`, qui va effectuer des opérations quelconques (injection de secrets, initialisation de base de données...), puis démarrer le service, sous forme d'un ou de plusieurs processus.
 +
 +## Entrypoint qui lance un unique processus
 +
 +### Situation
 +
 +Dans ce cas, le `Dockerfile` spécifie :
 +
 +* Une instruction `ENTRYPOINT` associée à un script shell
 +* Une instruction `CMD`, passée en arguments de l'entrypoint
 +
 +L'entrypoint est exécuté par un shell comme `/bin/sh` ou `/bin/bash`. C'est le premier processus exécuté dans le conteneur, il a donc le PID 1.
 +
 +Traditionnellement, ce script lance le service désigné par `CMD`. 
 +
 +<bootnote question>
 +Quels sont les risques ?
 +</bootnote>
 +
 +### Problématique
 +
 +Les scripts ne transmettent pas les signaux à leurs enfants (voir [[technique:docker:good_practices:init|explications ici]]).
 +
 +<bootnote important>Le processus désigné par `CMD` ne reçoit donc **jamais** les signaux qui sont envoyés au conteneur. Or, ces signaux peuvent être importants : signal de terminaison, signal de rechargement de configuration... De plus, un processus tué brutalement peut créer des situations indésirables, comme la corruption d'une base de données. Il est donc très important qu'il reçoive les signaux qui lui sont destinés.</bootnote>
 +
 +Supposons un Dockerfile du style :
 +
 +```
 +FROM debian:buster-slim
 +...
 +ENTRYPOINT [ "/entrypoint.sh" ]
 +# Notez qu'on lance nginx en premier plan
 +CMD [ "nginx", "-g", "daemon-off;" ]
 +```
 +
 +Avec un entrypoint du style :
 +
 +```bash
 +#!/bin/sh
 +
 +# Injection de secrets
 +sed [...]
 +
 +# Démarrage de nginx
 +$@
 +```
 +
 +<bootnote>`$@` désigne l'ensemble des arguments passés à l'entrypoint, c'est-à-dire le contenu du `CMD` du `Dockerfile`.</bootnote>
 +
 +Dans ce cas, la situation ressemble à ceci :
 +
 +```
 +NOM               PID
 +entrypoint.sh     1
 +  |__nginx        2
 +```
 +
 +Comme nous venons de le voir, tout signal envoyé au conteneur arrivera à l'entrypoint, qui n'en fera rien, ce qui conduira Docker à envoyer un `SIGKILL` au bout d'un moment.
 +
 +<bootnote question>Comment faire ?</bootnote>
 +
 +### Utiliser exec
 +
 +Le comportement désiré serait d'exécuter les instruction de l'entrypoint, puis de **remplacer** l'entrypoint par son processus enfant. C'est exactement le but de la commande [exec](https://linux.die.net/man/3/exec).
 +
 +On remplace l'entrypoint par :
 +
 +```bash
 +#!/bin/sh
 +
 +# Injection de secrets
 +sed [...]
 +
 +# Démarrage de nginx
 +exec $@
 +```
 +
 +Après exécution de l'entrypoint, les processus sont comme suit :
 +
 +```
 +NOM               PID
 +nginx             1
 +```
 +
 +L'entrypoint a été remplacé par nginx. Il reçoit correctement les signaux.
 +
 +## Entrypoint qui lance plusieurs services
 +
 +<bootnote warning>Attention, la philosophie Docker se résume généralement en : *un conteneur, un processus*. En réalité, c'est plutôt **un conteneur, un service**. Il y a donc des cas où il est légitime que plusieurs processus tournent simultanément, mais s'il s'agit de parties bien cloisonnées d'une application (*e.g.* serveur web et serveur applicatif), il est préférable de les faire tourner dans deux conteneurs séparés.</bootnote>
 +
 +Un entrypoint qui lance plusieurs services pourrait ressembler à ceci :
 +
 +```bash
 +#!/bin/sh
 +
 +# Injection de secrets
 +sed [...]
 +
 +# Lancement de PHP en arrière plan
 +php-fpm &
 +
 +# Lancement de nginx en premier plan
 +exec nginx -g 'daemon off;'
 +```
 +
 +Après lancement, la situation est la suivante :
 +
 +```
 +NOM               PID
 +nginx             1
 +  |__php-fpm      2
 +```
 +
 +Pourquoi ? Tout simplement parce que `nginx` s'est substitué au shell via `exec`, **mais** il a aussi hérité des processus enfants du shell, comme `php-fpm`.
 +
 +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>