Swarm part done

tutorial/docker-orchestration/machine.md

@@ -5,12 +5,24 @@ Création du cluster
 
 ## Le provisionnement de machine
 
-Pour travailler sur un cluster, il faut avoir plusieurs machines. Au moins plus
+Pour travailler sur un cluster, il faut avoir plusieurs machines ... au moins
-d'une !
+plus d'une !
 
-TODO parler du clustering et du provisionning
+Mais qui dit plusieurs machines, dit généralement de nombreuses installations à
+faire, de nombreuses configurations à partager, etc. Tout ce qu'un
+administrateur système redoute : du travail !
 
-TODO parler des concurrents
+Évidemment, de nombreuses solutions existent pour travailler moins, tout en
+déployant plus et de manière plus fiable ! On peut parler
+d'[`ansible`](https://www.ansible.com/), de
+[`chef`](https://docs.chef.io/provisioning.html), ou encore de
+[`puppet`](https://puppet.com/products/capabilities/automated-provisioning),
+... Toutes ces solutions permettent d'obtenir des configurations finement
+personnalisées, mais nécessitent une phase d'apprentissage plutôt lourde.
+
+Comme nous voulons lancer des conteneurs, les machines à provisionner n'ont pas
+besoin de configuration bien particulière et les seuls paquets importants sont
+une version récente de `docker` et ses dépendances.
 
 
 ## Provisionner des machines ...

tutorial/docker-orchestration/project.md

@@ -8,6 +8,45 @@ Rendu
 Écrivez le `docker-compose.yml` permettant de lancer facilement une
 instance de serveur du FIC.
 
+### Stage 1 : `Dockerfile`
+
+* admin
+* backend
+* frontend
+
+
+### Stage 2 : `docker-compose.yml` simple
+
+* admin
+* backend
+* frontend
+* mysql
+
+
+### Stage 2 (bis) : `docker-compose.yml` avec autentification
+
+* admin
+* backend
+* frontend
+* mysql
+* nginx (auth)
+
+
+### Stage 3 : `fic-server.yml` sécurisé
+
+* admin
+* backend
+* frontend
+* mysql
+* nginx (auth)
+
+Utilisant `docker secrets` et `docker config`.
+
+
+### Stage 4 : `fic-server.yml` production ready
+
+ssh between back and front et sur deux machines distinctes
+
 
 ## Modalité de rendu
 

tutorial/docker-orchestration/swarm.md

@@ -1,34 +1,158 @@
 \newpage
 
-Cluster Swarm
+Déploiement de conteneurs
-=============
+=========================
+
+Historiquement, le passage d'une application en production ou simplement dans
+un environnement de qualification, n'est pas toujours aisé. Parfois d'ailleurs,
+on ne teste pas, on fait les modifications en production ... et à chaque
+déploiement, on prie pour ne pas écraser une modification qui faisait que notre
+projet tombait en marche dans cet environnement.
+
+Déployer des conteneurs sur sa propre machine, c'est extrêmement simple
+grâce. Et mieux encore, tout l'environnement étant contenu dans l'image, il
+suffit de suivre les bonnes pratiques pour que le déploiement en production se
+fasse de manière transparente.
+
 
 ## L'orchestration
 
-Déployer des conteneurs sur sa propre machine, c'est extrêmement simple grâce à
+Cependant, notons une différence de taille entre notre environnement de
-Docker. Mais souvent, le passage d'une application en production ou simplement
+développement sur nos machines locales et la production : les clients ! Pour
-dans un environnement de qualification, n'est pas toujours aisé.
+répondre de manière adéquate, il convient de dimensionner correctement les
+machines, le nombre de conteneurs que chacune peut exécuter, en fonction de
+caractéristiques (on privilégiera les machines avec des SSD pour les serveurs
+de base de données par exemple), ...
 
-Il n'est pas question pour un administrateur système de faire la répartition de
+Il n'est pas question pour un administrateur système de faire cette répartition
-la charge à la main : afin de ne pas trop charger un serveur qui pourrait
+de la charge à la main : le nombre de critères à prendre en compte est beaucoup
-recevoir des pics, alors que d'autres serveurs attendent des calculs.
+trop grand, évolue sans cesse ; cela serait trop long s'il y a beaucoup de
+conteneurs et de variété de machines.
 
 Ce processus d'optimisation s'appelle l'*orchestration*. Il s'agit de réussir à
-répartir au mieux les conteneurs dans notre environnement de production
+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/),
+[Hashicorp Nomad](https://www.nomadproject.io/) ou encore
+[Google Kubernetes](https://kubernetes.io), ...
+
+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
+    dernier) indique le début du support de Kubernetes au sein de Docker,
+    pouvant être utilisé en symbiose avec Swarm.
+
+
+### Concepts clefs
+
+Regroupés au sein d'un cluster (on parle de *swarm* pour Docker), chaque
+*Docker engine* représente un nœud (*node*) dans lequel on va déployer des
+*services*.
+
+Certain nœud ont un rôle de *manager*, parmi ceux-ci, un seul est élu leader et
+prendra les décisions d'orchestration. Les autres sont là pour prendre le
+relais en cas de dysfonctionnement sur le manager élu.
+
+Les services sont un groupe de tâches (typiquement une image avec sa ligne de
+commande à lancer) que le `manager` va conserver à l'état désiré. Le service va
+indiquer par exemple le nombre d'instances que l'on désire avoir dans le
+cluster. En cas de crash d'un manager ou d'un *worker*, le (nouveau) manager
+fera en sorte de redéployer les conteneurs perdus, afin de toujours maintenir
+le cluster dans l'état désiré.
+
+En terme de cluster, des tâches sont l'équivalent des conteneurs, hors de Swarm.
+
 
 ## Création du cluster Swarm
 
-`docker swarm`
+### Initialisation du cluster
 
-### Le maître
+La première chose à faire, est d'initialiser un cluster swarm. Pour se faire,
+ce n'est pas plus compliqué que de faire :
 
-#### Initialisation du cluster
+<div lang="en-US">
+```shell
+docker swarm init
+```
+</div>
 
-#### Présentation des mécanismes de sécurité
+Cela va créer un cluster mono-nœud, sur la machine courante (celle pointée par
+la variable `DOCKER_HOST`). Ce nœud est automatiquement passé *manager* du
+cluster, afin de pouvoir lancer des tâches ... au moins sur lui-même en
+attendant d'autres nœuds.
 
 
-### Les nodes
+### Rejoindre le cluster
 
-#### Enregistrement d'un esclave
+Pour rejoindre un cluster, il est nécessaire d'avoir le jeton associé à ce
+cluster.
 
-#### Multi-maître
+La commande pour rejoindre le cluster et contenant le jeton, est indiquée
+lorsque vous initialisez le cluster. Si vous avez raté la sortie de la
+commande, vous pouvez retrouver le jeton avec :
+
+<div lang="en-US">
+```shell
+docker swarm join-token worker
+```
+</div>
+
+Lançons maintenant la commande `join` indiquée, sur une autre machine, en
+utilisant `docker-machine`.
+
+**Pro tips:** envoyez votre commande `join` à votre voisin qui a réussi à
+  provisionner plusieurs machines Docker (via `docker-machine` ou manuellement,
+  peu importe du moment que les VMs ont bien accès au même réseau que votre
+  *Swarm*[^avertVM]). Et soyez fair-play, attendez un peu avant de lancer
+  l'image `embano1/cpuburn` ;)
+
+[^avertVM]: Si vous utilisez Docker dans une VM, il faut que celle-ci soit
+    configurée en mode bridge pour qu'elle soit sur le même sous-réseau. Il n'y
+    a pas de problème à avoir des nœuds *workers* derrière un NAT, mais il est
+    primordial que les managers soient joignables. Vous pouvez tenter de faire
+    des redirections de ports, mais le résultat n'est pas garanti !
+
+<div lang="en-US">
+```shell
+eval $(docker-machine env echinoidea)
+docker swarm join --token SWMTKN-1-...-... 10.10.10.42:2377
+```
+</div>
+
+Une fois rejoint, vous devriez voir apparaître un nouveau nœud *worker* dans :
+
+<div lang="en-US">
+```shell
+42sh$ eval $(docker-machine env -u)
+42sh$ docker node ls
+ID                         HOSTNAME    STATUS  AVAILABILITY  MANAGER STATUS
+y9skzvuf989hjrkciu8mnsy    echinoidea  Ready   Active
+ovgh6r32kgcbswb2we48br1 *  wales       Ready   Active        Leader
+```
+</div>
+
+
+### Rejoindre en tant que manager
+
+Lorsqu'il est nécessaire d'avoir de la haute-disponibilité, on définit
+plusieurs managers. Cela permet qu'en cas de dysfonctionnement du manager, un
+nouveau manager soit élu.
+
+Nous n'allons pas faire rejoindre de manager supplémentaire durant ce TP, mais
+vous pouvez facilement expérimenter la chose en lançant 5 machines virtuelles
+et en définissant trois des cinq machines comme étant managers.
+
+Pour que l'algorithme de consensus fonctionne de manière optimale, il convient
+toujours un nombre impair de managers, Docker en recommande 3 ou 5. La pire
+configuration est avec deux managers, car si un tombe, il ne peut pas savoir si
+c'est lui qui est isolé (auquel cas il attendrait d'être à nouveau en ligne
+avant de se proclamer leader) ou si c'est l'autre manager qui est tombé. Avec
+trois managers, en cas de perte d'un manager, les deux restants peuvent
+considérer qu'ils ont perdu le troisième et peuvent élire le nouveau manager
+entre-eux et continuer à faire vivre le cluster.