teach/virli
1
0
Fork 0
Code Issues Pull requests Releases Activity

docker-internals: Tuto done

Browse source
This commit is contained in:
nemunaire 2022-11-27 10:56:56 +01:00
commit 13a617ffe0
6 changed files with 56 additions and 40 deletions
Download patch file Download diff file Expand all files Collapse all files

30
tutorial/docker-internals/tini.md
View file

@ -45,7 +45,7 @@ génère beaucoup de zombies, qui vont finir par rendre la machine instable, car
le système sera à court de PID à distribuer.
On peut citer notamment la JVM, ou encore les conteneurs de construction de
logiciels (Jenkins, Drone, ...). En effet, si l'on peut blâmer les programmeurs
logiciels (Jenkins, Drone, ...). En effet, si l'on peut blâmer les programmeurs
qui oublient de `wait(2)` leurs fils directs, il peut arriver régulièrement
qu'une erreur de programmation crée des zombies dans les conteneurs de
construction. Sans processus pour les arrêter, chaque *build* risque d'ajouter
@ -82,14 +82,14 @@ d'extinction du conteneur (généralement `SIGTERM`), lorsque l'on fait un
::::: {.question}
### Ne pourrait-on pas simplement ajouter un *thread* dans Jenkins/DroneCI/... ? {-}
#### Ne pourrait-on pas simplement ajouter un *thread* dans Jenkins/DroneCI/... qui s'occupe de gérer les zombies ? {-}
\
Alors ce n'est pas vraiment une solution idéale... si Jenkins s'exécute en tant
que PID 1, il est paraît difficile de différencier les processus qui ont été
que PID 1, il paraît difficile de différencier les processus qui ont été
re-parentés à Jenkins (et sur lesquels il faut `wait(2)` directement) et ceux
qui ont été créés par Jenkins et pour lequel le code de retour est attendu par
ailleurs.
d'autres portions du code.
:::::
@ -105,7 +105,7 @@ reçoit un `SIGTERM`, celui-ci ne sera tout simplement pas traité et encore
moins transmis à ses fils, à moins d'avoir programmé un tel comportement en
shell.
Voici donc une raison supplémentaire de préférer `tini` à `bash` (ou rien du
Voici donc une raison supplémentaire de préférer `tini` à `bash` (ou à rien du
tout). D'autant plus qu'à moins d'avoir préparé la fin d'exécution, `bash` ne
retournera pas le code d'erreur de la commande que l'on a lancé, mais plutôt 0.
@ -117,3 +117,23 @@ application qui ne `fork(2)` pas n'a pas besoin de processus `init`. De même,
une image contenant un binaire qui gère correctement ses fils et qui n'a pas de
petit enfant n'aura pas besoin de `tini`. Par contre dans les autres cas, il
semble particulièrement indiqué.
L'utilisation par le paramètre `--init` du `run` n'est pas recommandée et
devrait se limiter aux cas où l'image a été construite par quelqu'un qui
n'avait pas en tête ces contraintes. Lorsque l'on sait que des zombies ne vont
pas être géré par leurs parents, le mainteneur se doit d'ajouter `tini` dans
son `Dockerfile`. La méthode recommandée est de l'installer par les paquets de
la distribution (`apt-get install tini`, `apk add tini`, ...). Néanmoins, dans
le cas d'une distribution qui ne possèderait pas le paquet, il convient
d'ajouter ces quelques lignes :
<div lang="en-US">
```
# Install tini for signal processing and zombie killing
ENV TINI_VERSION v0.18.0
RUN wget -O /usr/local/bin/tini "https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini" && \
chmod +x /usr/local/bin/tini && \
tini --version
ENTRYPOINT ["/usr/local/bin/tini", ...]
```
</div>