Save tuto corrections
This commit is contained in:
parent
f5ee6b8534
commit
10448a6c8d
115 changed files with 1423 additions and 1289 deletions
|
|
@ -1,23 +1,21 @@
|
|||
\newpage
|
||||
|
||||
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 !
|
||||
|
||||
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 !
|
||||
administrateur système redoute : du travail !
|
||||
|
||||
Évidemment, de nombreuses solutions existent pour travailler moins, tout en
|
||||
déployant plus et de manière plus fiable ! On peut parler
|
||||
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
|
||||
[`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
|
||||
|
|
@ -25,9 +23,7 @@ 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 ...
|
||||
|
||||
### Automagiquement
|
||||
### Provisionner des machines ...
|
||||
|
||||
La solution magique consiste à passer par `docker-machine` pour créer des
|
||||
machines virtuelles automatiquement provisionnées avec Docker.
|
||||
|
|
@ -38,21 +34,20 @@ virtuelles. Si votre machine Linux est en fait une machine virtuelle hébergée
|
|||
par VirtualBox sous Windows, vous allez sans doute préférer la deuxième
|
||||
solution, que d'utiliser PowerShell et Docker4Windows[^amazon].
|
||||
|
||||
[^amazon]: Vous pouvez aussi vous inscrire sur
|
||||
[Amazon Web Services](https://aws.amazon.com/), `docker-machine` est
|
||||
capable, à partir de vos
|
||||
[clefs d'API](https://docs.docker.com/machine/examples/aws/), de créer et
|
||||
lancer des machines dans le cloud ! Et ce n'est pas le seul service de
|
||||
[cloud supporté](https://docs.docker.com/machine/drivers/) !
|
||||
[^amazon]: Vous pouvez aussi vous inscrire sur [Amazon Web
|
||||
Services](https://aws.amazon.com/) <https://aws.amazon.com/>,
|
||||
`docker-machine` est capable, à partir de vos clefs d'API, de créer et
|
||||
lancer des machines dans le cloud ! Et ce n'est pas le seul service de
|
||||
cloud supporté !
|
||||
|
||||
|
||||
#### Créer une machine
|
||||
##### Créer une machine {-}
|
||||
|
||||
Pour créer une nouvelle machine, nous allons utiliser la commande
|
||||
`docker-machine create`, en prenant soin de préciser le pilote à utiliser, les
|
||||
éventuelles options que prend ce pilote, ainsi que le nom que vous souhaitez
|
||||
donner à cette machine (les machines ne sont pas considérées comme jetables,
|
||||
leur nom vous permettra par exemple de relancer une machine plus tard) :
|
||||
leur nom vous permettra par exemple de relancer une machine plus tard) :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -61,34 +56,37 @@ docker-machine create --driver virtualbox echinoidea
|
|||
</div>
|
||||
|
||||
Consultez la section suivante, réservée aux gens qui ne peuvent pas passer par
|
||||
`docker-machine` si vous souhaitez avoir plus d'information sur ce que fait
|
||||
`docker-machine`, si vous souhaitez avoir plus d'information sur ce que fait
|
||||
cette commande.
|
||||
|
||||
#### Commandes usuelles de `docker-machine`
|
||||
##### Commandes usuelles de `docker-machine` {-}
|
||||
|
||||
De la même manière que `docker`, vous pouvez lister les machines connues
|
||||
(`ls`), changer leur état d'exécution (`start`/`stop`/`kill`/`restart`) ou encore supprimer la machine (`rm`)
|
||||
(`ls`), changer leur état d'exécution (`start`/`stop`/`kill`/`restart`) ou
|
||||
encore supprimer une machine (`rm`).
|
||||
|
||||
Si vous avez besoin d'obtenir un shell : `docker-machine ssh $NAME` et
|
||||
Si vous avez besoin d'obtenir un shell : `docker-machine ssh $NAME` et
|
||||
évidemment la commande `scp` s'utilise de la même manière, pour transférer des
|
||||
fichiers.
|
||||
|
||||
#### Utilisation avec Docker
|
||||
##### Utilisation avec Docker {-}
|
||||
|
||||
Rappelez-vous, au cours précédent, nous avions évoqué le fait que le deamon
|
||||
pouvait ne pas se trouver sur la même machine que le client `docker`. Eh bien
|
||||
avec `docker-machine` cela prend tout son sens, car vous pouvez très facilement
|
||||
changer de daamon/machine avec une simple commande :
|
||||
Nous avons déjà évoqué le fait que le deamon pouvait ne pas se trouver sur la
|
||||
même machine que le client `docker`. Eh bien avec `docker-machine` cela prend
|
||||
tout son sens, car vous pouvez très facilement changer de daemon/machine avec
|
||||
une simple commande :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ docker container ls
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS
|
||||
42sh$ eval $(docker-machine env echinoidea)
|
||||
42sh$ docker container ls -a
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS
|
||||
a814293b9f45 armbuild/busybox "/bin/sh" 18 seconds ago Up 10 minutes
|
||||
0caddeed5037 armbuild/alpine "/bin/sh" 2 weeks ago Created
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS
|
||||
|
||||
42sh$ eval $(docker-machine env echinoidea)
|
||||
|
||||
42sh$ docker container ls -a
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS
|
||||
a814293b9f45 armbuild/busybox "/bin/sh" 18 seconds ago Up 10 minutes
|
||||
0caddeed5037 armbuild/alpine "/bin/sh" 2 weeks ago Created
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -102,43 +100,44 @@ supprimer manuellement les variables qui ont été ajoutées par l'évaluation,
|
|||
soit lancer `eval $(docker machine env -u)`.
|
||||
|
||||
|
||||
### Automanuellement
|
||||
#### Derrière Docker Machine...
|
||||
|
||||
Si votre environnement ne vous permet pas d'utiliser `docker-machine`, vous
|
||||
pouvez vous contenter aujourd'hui de démarrer une ou deux autres machines
|
||||
virtuelles sur le même réseau que votre machine actuelle.
|
||||
pouvez vous contenter de démarrer une ou deux autres machines virtuelles sur le
|
||||
même réseau que votre machine virtuelle.
|
||||
|
||||
Rassurez-vous, vous n'allez pas avoir besoin de refaire toute la phase
|
||||
d'installation. Des contributeurs maintiennent une petite ISO ne contenant que
|
||||
le strict nécessaire pour utiliser Docker. C'est d'ailleurs cette ISO qui est
|
||||
utilisé par `docker-machine` pour démarrer et configurer en un rien de temps
|
||||
ses machines virtuelles.
|
||||
d'installation. Des contributeurs ont conçu une petite image de CD ne contenant
|
||||
que le strict nécessaire pour utiliser Docker. C'est d'ailleurs cette ISO qui
|
||||
est utilisée par `docker-machine` pour démarrer et configurer en un rien de
|
||||
temps ses machines virtuelles.
|
||||
|
||||
1. Dans un premier temps, commençons par
|
||||
[télécharger la dernière ISO de `boot2docker.iso`](https://github.com/boot2docker/boot2docker/releases/latest).
|
||||
1. Dans un premier temps, commençons par télécharger la dernière ISO de
|
||||
`boot2docker.iso` :\
|
||||
<https://github.com/boot2docker/boot2docker/releases/latest>
|
||||
1. Ensuite, dans notre hyperviseur, créons deux nouvelles machines, avec
|
||||
suffisamment de ressources pour pouvoir lancer des conteneurs. Ce n'est pas
|
||||
parce que l'images que l'on va démarrer est petite, que l'on ne va pas
|
||||
parce que l'image que l'on va démarrer est petite que l'on ne va pas
|
||||
pouvoir allouer beaucoup d'espace disque ou de RAM.
|
||||
1. Lançons ensuite nos deux images, configurées pour démarrer sur l'image ISO
|
||||
que l'on a téléchargée précédemment.
|
||||
1. Faisons un `ip a` pour connaître l'IP de la machine, nous devrions pouvoir
|
||||
s'y connecter en SSH avec l'utilisateur `docker` dont le mot de passe est
|
||||
nous y connecter en SSH avec l'utilisateur `docker` dont le mot de passe est
|
||||
`tcuser`.
|
||||
|
||||
Vous constaterez que le daemon `dockerd` est déjà lancé. `docker` est déjà
|
||||
pleinement utilisable dans cette machine !
|
||||
pleinement utilisable dans cette machine !
|
||||
|
||||
|
||||
#### (Optionnel) Déporter le client Docker
|
||||
|
||||
Dans le suite de ce TP, nous n'allons taper que quelques commandes dans nos
|
||||
Dans la suite, nous n'allons taper que quelques commandes dans nos
|
||||
machines virtuelles, il n'est donc pas primordial d'avoir configuré son
|
||||
environnement pour utiliser localement les daemons Docker des machines
|
||||
virtuelles. Néanmoins, cela ne coûte rien de voir les procédures mise en œuvre.
|
||||
|
||||
Commençons par voir sur quel port le daemon `dockerd` de notre machine
|
||||
virtuelle écoute :
|
||||
virtuelle écoute :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -148,26 +147,25 @@ tcp 0 0 :::2376 :::* 980/dockerd
|
|||
```
|
||||
</div>
|
||||
|
||||
Essayons de renseigner simplement cette configuration à notre client Docker :
|
||||
Essayons de renseigner simplement cette configuration à notre client Docker :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
(main) 42sh$ docker -H tcp://$VM1_IP:2376/ info
|
||||
Get http://$VM1_IP:2376/v1.32/info: net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x15\x03\x01\x00\x02\x02".
|
||||
Get http://$VM1_IP:2376/v1.32/info: net/http: transport connection broken
|
||||
* Are you trying to connect to a TLS-enabled daemon without TLS?
|
||||
```
|
||||
</div>
|
||||
|
||||
En effet, Docker met tout en œuvre pour rendre compliqué l'utilisation
|
||||
En effet, Docker met tout en œuvre pour rendre compliquée l'utilisation
|
||||
non-sécurisée de la plate-forme. Mais ils font également en sorte que la
|
||||
sécurité soit la plus transparente et la moins contraignante possible pour
|
||||
l'utilisateur, sans pour autant être faible.
|
||||
|
||||
Afin de contacter un daemon Docker distant, il est nécessaire présenter un
|
||||
certificat client TLS approuvé par ce daemon (comme lorsque vous vous connectez
|
||||
sur [Epitaf](https://www.epitaf.fr/moodle)). Il est également nécessaire de
|
||||
certificat client TLS approuvé par ce daemon. Il est seulement nécessaire de
|
||||
vérifier le certificat présenté par le daemon, comme dans le cadre d'une
|
||||
connexion TLS classique.
|
||||
connexion SSH classique.
|
||||
|
||||
Tout le nécessaire est déjà configuré au sein de `boot2docker`, pour nos tests,
|
||||
nous n'avons qu'à recopier la clef et les certificats en place.
|
||||
|
|
@ -182,12 +180,12 @@ key.pem
|
|||
```
|
||||
</div>
|
||||
|
||||
Tentons maintenant de nous connecter au daemon distant en utilisant ces éléments :
|
||||
Tentons maintenant de nous connecter au daemon distant utilisant ces éléments :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
42sh$ DOCKER_CERT_PATH=remote/virt1/ docker -H tcp://$VM1_IP:2376/ --tlsverify info
|
||||
DOCKER_CERT_PATH=remote/vir1/ docker -H tcp://$VM1_IP:2376/ --tlsverify info
|
||||
```
|
||||
</div>
|
||||
|
||||
Vous pouvez effectuer la même opération pour la seconde VM.
|
||||
Nous pouvons effectuer la même opération pour la seconde machine virtuelle.
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ Tous les fichiers identifiés comme étant à rendre pour ce TP sont à
|
|||
placer dans une tarball (pas d'archive ZIP, RAR, ...).
|
||||
|
||||
Voici une arborescence type (vous pourriez avoir des fichiers supplémentaires,
|
||||
cela dépendra de votre avancée dans le projet) :
|
||||
cela dépendra de votre avancée dans le projet) :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,42 +1,35 @@
|
|||
\newpage
|
||||
|
||||
Mise en place
|
||||
=============
|
||||
-------------
|
||||
|
||||
Pour cette partie, nous allons avoir besoin de `docker-machine`, installons-le sur
|
||||
notre machine hôte, même si ce n'est pas un Linux : le but va être de lancer
|
||||
plusieurs machines virtuelles dédiées à Docker pour simuler un cluster.
|
||||
|
||||
## `docker-machine`
|
||||
|
||||
Pour ce TP, nous allons avoir besoin de `docker-machine`, installez-le sur
|
||||
votre machine hôte, même si ce n'est pas un Linux : le but va être de lancer
|
||||
plusieurs machines virtuelles Docker pour simuler un cluster.
|
||||
|
||||
Ce programme permet de simplifier la gestion du multiples environnements
|
||||
Docker, comme par exemple lorsque l'on souhaite gérer un cluster de machines
|
||||
Ce programme permet de simplifier la gestion de multiples environnements
|
||||
Docker, comme par exmple lorsque l'on souhaite gérer un cluster de machines
|
||||
pour un projet.
|
||||
|
||||
Ainsi, il est possible de provisionner et gérer des machines hôtes sur les
|
||||
plates-formes de cloud habituelles. C'est également ce projet qui est à la base
|
||||
de *Docker for Mac* et *Docker for Windows*, en permettant de lancer via,
|
||||
respectivement, VirtualBox et Hyper-V, un environnement Linux prêt à être
|
||||
utilisé avec Docker.
|
||||
de *Docker Dektop*, en permettant de lancer via, respectivement, VirtualBox ou
|
||||
Hyper-V, un environnement Linux prêt à être utilisé avec Docker.
|
||||
|
||||
### Par la distribution binaire
|
||||
|
||||
L'équipe en charge de `docker-machine` met à disposition un exécutable compilé
|
||||
pour bon nombres d'environnements. Nous pouvons l'installer en suivant la
|
||||
procédure suivante :
|
||||
pour bon nombre d'environnements. Nous pouvons l'installer en suivant la
|
||||
procédure suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
curl -L https://github.com/docker/machine/releases/download/v0.15.0/docker-machine-Linux-x86_64 \
|
||||
V=0.16.2
|
||||
P=docker-machine-`uname -s`-`uname -m`
|
||||
curl -L https://github.com/docker/machine/releases/download/v${V}/${P} \
|
||||
> /usr/bin/docker-machine
|
||||
chmod +x /usr/bin/docker-machine
|
||||
```
|
||||
</div>
|
||||
|
||||
Si vous êtes dans un environnement différent, jetez un œil à
|
||||
[la documentation d'installation](https://docs.docker.com/machine/install-machine/).
|
||||
|
||||
|
||||
### Support de KVM
|
||||
|
||||
|
|
@ -46,28 +39,30 @@ plug-ins.
|
|||
|
||||
Si vous utilisez KVM comme hyperviseur, vous allez avoir besoin d'installer le
|
||||
plugins
|
||||
[`docker-machine-kvm`](https://github.com/dhiltgen/docker-machine-kvm). Vous
|
||||
n'aurez qu'à suivre les instructions du
|
||||
[`README`](https://github.com/dhiltgen/docker-machine-kvm/blob/master/README.md)
|
||||
!
|
||||
[`docker-machine-kvm`](https://github.com/machine-drivers/docker-machine-kvm). Vous
|
||||
n'aurez qu'à suivre les instructions du `README` :\
|
||||
<https://github.com/machine-drivers/docker-machine-kvm/>
|
||||
|
||||
Les autres plugins sont disponibles au sein de l'organisation Machine-Driver
|
||||
sur GitHub :\
|
||||
<https://github.com/machine-drivers/>
|
||||
|
||||
### Vérification du fonctionnement
|
||||
|
||||
Comme avec Docker, nous pouvons vérifier le bon fonctionnement de
|
||||
`docker-machine` en exécutant la commande :
|
||||
`docker-machine` en exécutant la commande :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ docker-machine version
|
||||
docker-machine version 0.12.2, build 9371605
|
||||
docker-machine version 0.16.2, build 9371605
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## Play With Docker
|
||||
### Play With Docker
|
||||
|
||||
Tout comme pour le TP précédent, si vous avez des difficultés pour réaliser les
|
||||
exercices sur vos machines, vous pouvez utiliser le projet
|
||||
[Play With Docker](https://play-with-docker.com/) qui vous donnera accès à un
|
||||
bac à sable avec lequel vous pourrez réaliser tous les exercices de ce TP.
|
||||
Si vous avez des difficultés pour réaliser les exercices sur votre machine,
|
||||
vous pouvez utiliser le projet [Play With
|
||||
Docker](https://play-with-docker.com/) qui vous donnera accès à un bac à sable
|
||||
avec lequel vous pourrez réaliser tous les exercices de cette partie.
|
||||
|
|
|
|||
|
|
@ -1,15 +1,15 @@
|
|||
\newpage
|
||||
|
||||
Déploiement de services
|
||||
=======================
|
||||
-----------------------
|
||||
|
||||
## Services ?
|
||||
### Services ?
|
||||
|
||||
Une petite minute terminologie avant de continuer, car lorsque l'on passe sur
|
||||
les clusters de Docker, cela change un peu :
|
||||
les clusters de Docker, cela change un peu :
|
||||
|
||||
* une *tâche* correspond à **un** unique conteneur, lancé sur l'un des nœuds
|
||||
*workers* du cluster ;
|
||||
*workers* du cluster ;
|
||||
* un *service* est un groupe de tâches (oui, les tâches du point précédent),
|
||||
exécutant la même image.
|
||||
|
||||
|
|
@ -18,13 +18,13 @@ la haute-disponibilité ou pour répartir la charge.
|
|||
|
||||
|
||||
<div lang="en-US">
|
||||
### Hello world, again?
|
||||
#### Hello world, again?
|
||||
</div>
|
||||
|
||||
Non, pas d'hello-world ici, mais nous allons prendre en main les services avec
|
||||
un serveur web, qui sera bien plus représentatif de ce que l'on pourra obtenir.
|
||||
|
||||
Précédemment, nous lancions notre serveur web favori avec :
|
||||
Précédemment, nous lancions notre serveur web favori avec :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -33,7 +33,7 @@ docker container run --name mywebs -d nginx
|
|||
</div>
|
||||
|
||||
La même commande, mais déployée à partir d'un nœud manager, vers un nœud
|
||||
*workers*, est :
|
||||
*workers*, est :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -41,7 +41,7 @@ docker service create --name myWebS nginx
|
|||
```
|
||||
</div>
|
||||
|
||||
Allons-y, essayons !
|
||||
Allons-y, essayons !
|
||||
|
||||
On peut consulter l'état du service avec, comme d'habitude `ls` :
|
||||
|
||||
|
|
@ -59,7 +59,7 @@ déployé, le tâche apparaît dans la liste des conteneurs !
|
|||
|
||||
Rien de très excitant pour le moment, car nous ne pouvons pas vraiment accéder
|
||||
à notre serveur. Essayons de modifier sa configuration en direct, afin
|
||||
d'ajouter une redirection de port :
|
||||
d'ajouter une redirection de port :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -71,13 +71,13 @@ docker service update --publish-add 80 myWebS
|
|||
service sont stoppés puis, le manager voyant que le service n'est pas dans
|
||||
l'état demandé, va lancer des tâches avec la nouvelle configuration.
|
||||
|
||||
La commande `update` est très puissante : vous pouvez mettre à jour
|
||||
La commande `update` est très puissante : vous pouvez mettre à jour
|
||||
pratiquement n'importe quel élément de configuration, y compris le nom de
|
||||
l'image ou son tag. Grâce à cela, faire des mises à jour se fait de manière
|
||||
transparente.
|
||||
|
||||
|
||||
#### Magie du mesh
|
||||
##### Magie du mesh {-}
|
||||
|
||||
Lorsque l'on publie un port de cette manière, chaque nœud du cluster devient un
|
||||
point d'entrée pour ce port, même si la tâche ne s'exécute pas sur ce nœud
|
||||
|
|
@ -88,25 +88,26 @@ nœuds. Vous devriez voir la même page.
|
|||
|
||||
Lorsque plusieurs tâches s'exécutent pour ce service, le nœud d'entrée choisi
|
||||
selon un round-robin à quelle tâche il va diriger la requête. C'est grâce à ce
|
||||
mécanisme qu'il est possible faire une répartition de charge très simplement.
|
||||
mécanisme qu'il est possible de faire de la répartition de charge très
|
||||
simplement.
|
||||
|
||||
\vspace{1.5em}
|
||||
|
||||
Cette méthode n'est pas la seule permettant d'exposer des ports. Mais c'est
|
||||
sans doute la plus intuitive. Si vous souhaitez en apprendre plus, vous deviez
|
||||
consulter la
|
||||
[documentation à ce sujet](https://docs.docker.com/engine/swarm/networking/).
|
||||
sans doute la plus intuitive. Si vous souhaitez en apprendre plus, vous devriez
|
||||
consulter la documentation à ce sujet :\
|
||||
<https://docs.docker.com/engine/swarm/networking/>
|
||||
|
||||
|
||||
### Mise à l'échelle et placement
|
||||
#### Mise à l'échelle et placement
|
||||
|
||||
On parle depuis toute à l'heure de lancer plusieurs tâches pour le même
|
||||
service. La mise à l'échelle c'est ça : exécuter plusieurs conteneurs pour la
|
||||
service. La mise à l'échelle, c'est ça : exécuter plusieurs conteneurs pour la
|
||||
même tâche afin de mieux répartir la charge, idéalement sur des machines
|
||||
physique différentes.
|
||||
physiques différentes.
|
||||
|
||||
Ce qui se fait souvent avec beaucoup de douleur hors de Docker, se résume ici à
|
||||
:
|
||||
Ce qui se fait souvent avec beaucoup de douleur hors de Docker, se résume ici
|
||||
à :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -122,21 +123,21 @@ docker service ps myWebS
|
|||
```
|
||||
</div>
|
||||
|
||||
nous montre bien, a priori 3 tâches en cours d'exécution pour ce service !
|
||||
nous montre bien, a priori 3 tâches en cours d'exécution pour ce service !
|
||||
|
||||
Enfin, vous avez compris le principe !
|
||||
Enfin, vous avez compris le principe !
|
||||
|
||||
|
||||
## Stack ?
|
||||
### Stack ?
|
||||
|
||||
Refermons cette longue parenthèse et revenons-en au sujet du jour : la
|
||||
Refermons cette longue parenthèse et revenons-en au sujet du jour : la
|
||||
supervision de nos machines.
|
||||
|
||||
Une *stack* est un groupe de services. Un projet, par exemple un site web dans
|
||||
son ensemble : frontend, API, base de données, ...
|
||||
son ensemble : frontend, API, base de données, ...
|
||||
|
||||
Notre système de monitoring est une *stack* lui aussi, d'ailleurs, nous pouvons
|
||||
la lancer grâce à notre `docker-compose.yml` :
|
||||
la lancer grâce à notre `docker-compose.yml` :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -144,7 +145,7 @@ docker stack deploy --compose-file docker-compose.yml tic
|
|||
```
|
||||
</div>
|
||||
|
||||
### Règle de déploiement
|
||||
#### Règle de déploiement
|
||||
|
||||
Par rapport à `docker-compose`, nous pouvons indiquer dans ce fichier des
|
||||
paramètres qui ne serviront qu'au déploiement de notre tâche.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ institute: EPITA
|
|||
date: Jeudi 18 octobre 2018
|
||||
abstract: |
|
||||
Dans la troisième partie de ce TP, nous allons orchestrer nos
|
||||
conteneurs !
|
||||
conteneurs !
|
||||
|
||||
\vspace{1em}
|
||||
|
||||
|
|
@ -21,4 +21,4 @@ abstract: |
|
|||
[me](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x842807A84573CC96)
|
||||
faire signer votre clef et n'hésitez pas à [faire signer la
|
||||
vôtre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
...
|
||||
...
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue