Rework TP2

tutorial/2/supervisor.md

@@ -4,21 +4,21 @@
 
 ## Script d'init
 
-Lors du dernier TP, nous avons vu que les conteneurs étaient détruits
-dès que le premier processus du conteneur (celui qui a le PID 1, à la
-place d'`init`) terminer son exécution, quelque soit le statut de ses
-éventuels fils.
+Lors du dernier TP, nous avons vu que les conteneurs étaient détruits dès que
+le premier processus du conteneur (celui qui a le PID 1, à la place d'`init`)
+terminer son exécution, quelque soit le statut de ses éventuels fils.
 
-Pour lancer tous nos daemon,
+Pour lancer tous nos daemon, nous allons donc besoin d'écrire un script qui
+lance puis attend que les deux deamons aient terminés de s'exécuter
 
 
 ## Autorestart
 
-L'avantage de détruire le conteneur à la mort du père, est que s'il
-s'agit de notre processus principal et qu'il est seul (par exemple
-`nginx` pour un conteneur qui délivre des pages web), il va être
-possible de redémarrer le conteneur automatiquement grâce à la
-*restart policy* que l'on peut définir au moment du `docker run` :
+L'avantage de détruire le conteneur à la mort du père, est que s'il s'agit de
+notre processus principal et qu'il est seul (par exemple `nginx` pour un
+conteneur qui délivre des pages web), il va être possible de redémarrer le
+conteneur automatiquement grâce à la *restart policy* que l'on peut définir au
+moment du `docker run` :
 
 ```
 docker run -d -p 80:80 --restart=on-failure nginx
@@ -26,28 +26,26 @@ docker run -d -p 80:80 --restart=on-failure nginx
 
 Il existe trois règles de redémarrage différentes :
 
-- **`no` :** il s'agit de la règle par défaut. Lorsque l'exécution du
-  conteneur se termine, il n'est pas redémarré.
-- **`on-failure[:max-retries]` :** redémarre uniquement si le code de
-  sortie du conteneur n'est pas 0. Il est possible de préciser pour
-  cette option le nombre maximum de redémarrage qui sera tenté.
-- **`always` :** redémarre le conteneur dans tous les cas, quelque
-  soit son code de sortie et indéfiniment.
+- **`no` :** il s'agit de la règle par défaut. Lorsque l'exécution du conteneur
+  se termine, il n'est pas redémarré.
+- **`on-failure[:max-retries]` :** redémarre uniquement si le code de sortie du
+  conteneur n'est pas 0. Il est possible de préciser pour cette option le
+  nombre maximum de redémarrage qui sera tenté.
+- **`always` :** redémarre le conteneur dans tous les cas, quelque soit son
+  code de sortie et indéfiniment.
 
-Le script d'init que vous avez réalisé ne tient sans doute pas compte
-de cela. Mais plein de gens ont cette problématique et `supervisor`
+Le script d'init que vous avez réalisé ne tient sans doute pas compte de
+cela. Mais plein de gens ont cette problématique et l'application `supervisor`
 répond parfaitement à notre problématique !
 
 
 ## `supervisor`
 
-Première étape : installer `supervisor`, le paquet se trouve dans les
-dépôts.
+Première étape : installer `supervisor`, le paquet se trouve dans les dépôts.
 
-L'étape suivante consiste à remplir puis copier le fichier de
-configuration dans le conteneur. Vous allez devoir écraser dans votre
-conteneur le fichier `/etc/supervisord.conf` pour démarrer à la fois
-`grafana` et `influxdb`.
+L'étape suivante consiste à remplir puis copier le fichier de configuration
+dans le conteneur. Vous allez devoir écraser dans votre conteneur le fichier
+`/etc/supervisord.conf` pour démarrer à la fois `grafana` et `influxdb`.
 
 Vous pouvez vous aider de la documentation disponible à :
 <http://supervisord.org/configuration.html>
@@ -55,6 +53,6 @@ Vous pouvez vous aider de la documentation disponible à :
 
 ## C'est parti !
 
-Votre conteneur doit maintenant être parfaitement fonctionnel : vous
-devriez pouvoir lancer votre script de monitoring et voir apparaître
-vos données dans Grafana !
+Votre conteneur doit maintenant être parfaitement fonctionnel : vous devriez
+pouvoir lancer votre script de monitoring et voir apparaître vos données dans
+Grafana !