2017-10-16 01:10:34 +00:00
|
|
|
|
\newpage
|
|
|
|
|
|
2017-10-17 23:59:55 +00:00
|
|
|
|
Déploiement de conteneurs
|
2022-02-24 19:43:43 +00:00
|
|
|
|
-------------------------
|
2017-10-17 23:59:55 +00:00
|
|
|
|
|
|
|
|
|
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*.
|
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
Certain nœuds ont un rôle de *manager*, parmi ceux-ci, un seul est élu leader et
|
2017-10-17 23:59:55 +00:00
|
|
|
|
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é.
|
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
En termes de cluster, des tâches sont l'équivalent des conteneurs, hors de
|
|
|
|
|
Swarm.
|
2017-10-17 23:59:55 +00:00
|
|
|
|
|
2017-10-16 01:10:34 +00:00
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
### Création du cluster Swarm
|
2017-10-16 01:10:34 +00:00
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
#### Initialisation du cluster
|
2017-10-17 23:59:55 +00:00
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
La première chose à faire est d'initialiser un cluster Swarm. Pour se faire,
|
|
|
|
|
ce n'est pas plus compliqué que de faire :
|
2017-10-17 23:59:55 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
2018-11-16 01:38:41 +00:00
|
|
|
|
```bash
|
|
|
|
|
docker swarm init
|
2017-10-17 23:59:55 +00:00
|
|
|
|
```
|
|
|
|
|
</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.
|
|
|
|
|
|
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
#### Rejoindre un cluster
|
2017-10-17 23:59:55 +00:00
|
|
|
|
|
|
|
|
|
Pour rejoindre un cluster, il est nécessaire d'avoir le jeton associé à ce
|
|
|
|
|
cluster.
|
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
La commande pour rejoindre un cluster et contenant le jeton est iniquée
|
2017-10-17 23:59:55 +00:00
|
|
|
|
lorsque vous initialisez le cluster. Si vous avez raté la sortie de la
|
2022-02-24 19:43:43 +00:00
|
|
|
|
commande, vous pouvez retrouver le jeton avec :
|
2017-10-17 23:59:55 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
2018-11-16 01:38:41 +00:00
|
|
|
|
```bash
|
|
|
|
|
docker swarm join-token worker
|
2017-10-17 23:59:55 +00:00
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
Lançons maintenant la commande `join` indiquée, sur une autre machine, en
|
|
|
|
|
utilisant `docker-machine`.
|
|
|
|
|
|
2022-04-09 00:50:14 +00:00
|
|
|
|
::::: {.warning}
|
|
|
|
|
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 !
|
|
|
|
|
:::::
|
2017-10-17 23:59:55 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
2018-11-16 01:38:41 +00:00
|
|
|
|
```bash
|
|
|
|
|
eval $(docker-machine env echinoidea)
|
|
|
|
|
docker swarm join --token SWMTKN-1-...-... 10.10.10.42:2377
|
2017-10-17 23:59:55 +00:00
|
|
|
|
```
|
|
|
|
|
</div>
|
2017-10-16 01:10:34 +00:00
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
Une fois rejoint, vous devriez voir apparaître un nouveau nœud *worker* dans :
|
2017-10-16 01:10:34 +00:00
|
|
|
|
|
2017-10-17 23:59:55 +00:00
|
|
|
|
<div lang="en-US">
|
2018-11-16 01:38:41 +00:00
|
|
|
|
```
|
|
|
|
|
42sh$ eval $(docker-machine env -u)
|
2022-02-24 19:43:43 +00:00
|
|
|
|
|
2018-11-16 01:38:41 +00:00
|
|
|
|
42sh$ docker node ls
|
|
|
|
|
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
|
|
|
|
|
y9skzvuf989hjrkciu8mnsy echinoidea Ready Active
|
|
|
|
|
ovgh6r32kgcbswb2we48br1 * wales Ready Active Leader
|
2017-10-17 23:59:55 +00:00
|
|
|
|
```
|
|
|
|
|
</div>
|
2017-10-16 01:10:34 +00:00
|
|
|
|
|
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
#### Rejoindre en tant que manager
|
2017-10-16 01:10:34 +00:00
|
|
|
|
|
2017-10-17 23:59:55 +00:00
|
|
|
|
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.
|
2017-10-16 01:10:34 +00:00
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
Nous n'allons pas faire rejoindre de manager supplémentaire à ce stade, mais
|
2017-10-17 23:59:55 +00:00
|
|
|
|
vous pouvez facilement expérimenter la chose en lançant 5 machines virtuelles
|
|
|
|
|
et en définissant trois des cinq machines comme étant managers.
|
2017-10-16 01:10:34 +00:00
|
|
|
|
|
2017-10-17 23:59:55 +00:00
|
|
|
|
Pour que l'algorithme de consensus fonctionne de manière optimale, il convient
|
2022-02-24 19:43:43 +00:00
|
|
|
|
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.
|