Swarm part done

This commit is contained in:
nemunaire 2017-10-18 01:59:55 +02:00 committed by nemunaire
parent 13dadd8c59
commit 235cce6eb8
3 changed files with 195 additions and 20 deletions

View File

@ -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
d'une !
Pour travailler sur un cluster, il faut avoir plusieurs machines ... au moins
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 ...

View File

@ -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

View File

@ -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 à
Docker. Mais souvent, le passage d'une application en production ou simplement
dans un environnement de qualification, n'est pas toujours aisé.
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 la répartition de
la charge à la main : afin de ne pas trop charger un serveur qui pourrait
recevoir des pics, alors que d'autres serveurs attendent des calculs.
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 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.