107 lines
3.8 KiB
Markdown
107 lines
3.8 KiB
Markdown
\newpage
|
||
|
||
Déploiement de conteneurs
|
||
-------------------------
|
||
|
||
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œuds 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 termes 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">
|
||
```bash
|
||
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 un cluster
|
||
|
||
Pour rejoindre un cluster, il est nécessaire d'avoir le jeton associé à ce
|
||
cluster.
|
||
|
||
La commande pour rejoindre un cluster et contenant le jeton est iniqué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">
|
||
```bash
|
||
docker swarm join-token worker
|
||
```
|
||
</div>
|
||
|
||
Lançons maintenant la commande `join` indiquée, sur une autre machine, en
|
||
utilisant `docker-machine`.
|
||
|
||
[^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">
|
||
```bash
|
||
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">
|
||
```
|
||
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 à ce stade, 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
|
||
de toujours avoir un nombre impair de managers : Docker en recommande 3
|
||
ou 5. La pire configuration est avec deux managers, car si l'un des deux 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 procalmer leader) ou si c'est l'autre 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.
|