Save tuto corrections
This commit is contained in:
parent
f5ee6b8534
commit
10448a6c8d
115 changed files with 1423 additions and 1289 deletions
|
|
@ -1,61 +1,13 @@
|
|||
\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
|
||||
[Google Kubernetes](https://kubernetes.io),
|
||||
[Hashicorp Nomad](https://www.nomadproject.io/) ou encore
|
||||
[Apache Mesos](https://mesos.apache.org/), ...
|
||||
|
||||
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 indique le début du support de Kubernetes au sein de Docker
|
||||
EE, 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
|
||||
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.
|
||||
|
||||
|
|
@ -66,15 +18,16 @@ 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.
|
||||
En termes de cluster, des tâches sont l'équivalent des conteneurs, hors de
|
||||
Swarm.
|
||||
|
||||
|
||||
## Création du cluster Swarm
|
||||
### Création du cluster Swarm
|
||||
|
||||
### Initialisation du cluster
|
||||
#### 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 :
|
||||
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
|
||||
|
|
@ -88,14 +41,14 @@ cluster, afin de pouvoir lancer des tâches ... au moins sur lui-même en
|
|||
attendant d'autres nœuds.
|
||||
|
||||
|
||||
### Rejoindre le cluster
|
||||
#### Rejoindre un 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
|
||||
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 :
|
||||
commande, vous pouvez retrouver le jeton avec :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -106,17 +59,11 @@ docker swarm join-token worker
|
|||
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 !
|
||||
des redirections de ports, mais le résultat n'est pas garanti !
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -125,11 +72,12 @@ 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 :
|
||||
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
|
||||
|
|
@ -138,21 +86,21 @@ ovgh6r32kgcbswb2we48br1 * wales Ready Active Leader
|
|||
</div>
|
||||
|
||||
|
||||
### Rejoindre en tant que manager
|
||||
#### 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
|
||||
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
|
||||
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.
|
||||
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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue