\newpage

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

Cependant, notons une différence de taille entre notre environnement de
développement sur nos machines locales et la production : les clients ! Pour
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 cette répartition
de la charge à la main : le nombre de critères à prendre en compte est beaucoup
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 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

### Initialisation du cluster

La première chose à faire, est d'initialiser un cluster swarm. Pour se faire,
ce n'est pas plus compliqué que de faire :

<div lang="en-US">
```shell
    docker swarm init
```
</div>

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.


### Rejoindre le cluster

Pour rejoindre un cluster, il est nécessaire d'avoir le jeton associé à ce
cluster.

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.
