Update docker-orchestration

tutorial/docker-orchestration/rendu.md

@@ -1,3 +1,16 @@
+\newpage
+
+Projet et rendu
+===============
+
+Projet
+------
+
+À partir du `docker-compose.yml` écrit dans la partie précédente, ajoutez des
+contraintes de déploiement pour avoir 1 `telegraf` par nœud, rapportant à la
+même base `influx`. N'oubliez pas de définir les `restart_policy`.
+
+
 Modalités de rendu
 ------------------
 
@@ -13,9 +26,6 @@ et exclusivement à celle-ci que vous devez envoyer vos rendus. Tout rendu
 envoyé à une autre adresse et/ou non signé et/ou reçu après la correction ne
 sera pas pris en compte.
 
-Par ailleurs, n'oubliez pas de répondre à
-[l'évaluation du cours](https://www.epitaf.fr/moodle/mod/quiz/view.php?id=33).
-
 
 Tarball
 -------
@@ -28,7 +38,9 @@ cela dépendra de votre avancée dans le projet) :
 
 <div lang="en-US">
 ```
-    login_x-TP2/tp/docker-compose.yml
+    login_x-TP2/
-    login_x-TP2/tp/mymonitoring-stack.yml
+    login_x-TP2/mymonitoring-stack.yml
 ```
 </div>
+
+Utilisez la même tarball pour le rendu que pour les parties précédentes.

tutorial/docker-orchestration/stack.md

@@ -26,26 +26,32 @@ un serveur web, qui sera bien plus représentatif de ce que l'on pourra obtenir.
 
 Précédemment, nous lancions notre serveur web favori avec :
 
+<div lang="en-US">
 ```shell
     docker container run --name mywebs -d nginx
 ```
+</div>
 
 La même commande, mais déployée à partir d'un nœud manager, vers un nœud
 *workers*, est :
 
+<div lang="en-US">
 ```shell
     docker service create --name myWebS nginx
 ```
+</div>
 
 Allons-y, essayons !
 
 On peut consulter l'état du service avec, comme d'habitude `ls` :
 
+<div lang="en-US">
 ```shell
     42sh$ docker service ls
     ID              NAME        MODE          REPLICAS    IMAGE         PORTS
     iyue3rgd0ohs    myWebS      replicated    1/1         nginx:latest
 ```
+</div>
 
 Vous pouvez constater que sur l'un des nœuds, sur lequel votre serveur aura été
 déployé, le tâche apparaît dans la liste des conteneurs !
@@ -55,9 +61,11 @@ Rien de très excitant pour le moment, car nous ne pouvons pas vraiment accéder
 à notre serveur. Essayons de modifier sa configuration en direct, afin
 d'ajouter une redirection de port :
 
+<div lang="en-US">
 ```shell
     docker service update --publish-add 80 myWebS
 ```
+</div>
 
 À chaque modification de configuration, les conteneurs lancés au sein du
 service sont stoppés puis, le manager voyant que le service n'est pas dans
@@ -82,7 +90,7 @@ Lorsque plusieurs tâches s'exécutent pour ce service, le nœud d'entrée chois
 selon un round-robin à quelle tâche il va diriger la requête. C'est grâce à ce
 mécanisme qu'il est possible faire une répartition de charge très simplement.
 
-\\
+\vspace{1.5em}
 
 Cette méthode n'est pas la seule permettant d'exposer des ports. Mais c'est
 sans doute la plus intuitive. Si vous souhaitez en apprendre plus, vous deviez
@@ -100,15 +108,19 @@ physique différentes.
 Ce qui se fait souvent avec beaucoup de douleur hors de Docker, se résume ici à
 :
 
+<div lang="en-US">
 ```shell
     docker service update --replicas 3 myWebS
 ```
+</div>
 
 Roulement de tambours .......
 
+<div lang="en-US">
 ```shell
     docker service ps myWebS
 ```
+</div>
 
 nous montre bien, a priori 3 tâches en cours d'exécution pour ce service !
 
@@ -126,15 +138,18 @@ son ensemble : frontend, API, base de données, ...
 Notre système de monitoring est une *stack* lui aussi, d'ailleurs, nous pouvons
 la lancer grâce à notre `docker-compose.yml` :
 
+<div lang="en-US">
 ```shell
     docker stack deploy --compose-file docker-compose.yml tic
 ```
+</div>
 
 ### Règle de déploiement
 
 Par rapport à `docker-compose`, nous pouvons indiquer dans ce fichier des
 paramètres qui ne serviront qu'au déploiement de notre tâche.
 
+<div lang="en-US">
 ```yaml
     version: '3'
     services:
@@ -154,6 +169,7 @@ paramètres qui ne serviront qu'au déploiement de notre tâche.
     	  resources:
     	    memory: 50M
 ```
+</div>
 
 Certaines informations comme les ressources, permettent à l'orchestrateur de
 mieux choisir le *workers* de destination, en fonction de certaines de ses

tutorial/docker-orchestration/swarm.md

@@ -35,18 +35,18 @@ répartir au mieux les conteneurs sur les différentes machines disponibles.
 Ce sujet fait l'objet de très nombreuses thèse depuis plusieurs années (avant
 les conteneurs, c'était pour répartir les machines virtuelles entre différents
 hôtes), et autant de projets disponibles. Citons par exemple
-[Apache Mesos](https://mesos.apache.org/),
+[Google Kubernetes](https://kubernetes.io),
 [Hashicorp Nomad](https://www.nomadproject.io/) ou encore
-[Google Kubernetes](https://kubernetes.io), ...
+[Apache Mesos](https://mesos.apache.org/), ...
 
 Le point commun entre la plupart des orchestrateurs, c'est généralement leur
 extrême complexité de mise en œuvre. Dans le cadre de notre TP, nous allons
 plutôt utiliser l'orchestrateur intégré à Docker, dont la caractéristique
 principale est sa simplicité[^dockerconEU2017].
 
-[^dockerconEU2017]: À noter qu'une annonce faite à la Docker Con EU 2017 (mardi
+[^dockerconEU2017]: À noter qu'une annonce faite à la Docker Con EU
-    dernier) indique le début du support de Kubernetes au sein de Docker,
+    2017 indique le début du support de Kubernetes au sein de Docker
-    pouvant être utilisé en symbiose avec Swarm.
+    EE, pouvant être utilisé en symbiose avec Swarm.
 
 
 ### Concepts clefs