Vous êtes ici:

Menu


Stacks Image 36912
Notre ClusterHat étant prêt, nous pouvons installer Docker. Puis pour gérer les PI Zero, nous utiliserons Swarm. Pourquoi ce choix ? C'est tout simple, je débute avec Docker et j'ai trouvé un très bon tutoriel sur l'installation de Swarm écrit par Niels Dommerholt. Alors, pourquoi s'en priver ? Après je me suis dit que Swarm étant l'outil proposé par Docker, cela ne pouvait pas être un mauvais choix.
Mis à jour du § octobre 2019 : j'ai privilégié le mode BRIDGE pour le fonctionnement de Swarm.

Installation de Docker et Swarm

Pour l'instant installons docker sur le Controller. L'installation est on ne peut plus facile. Connectons-nous en ssh avec le user pi et lançons la commande suivante :
pi@cbridge:~ $ curl -sSL https://get.docker.com | sudo sh
Voici la suite des opérations avec la dernière version :
# Executing docker install script, commit: 6bf300318ebaab958c4adc341a8c7bb9f3a54a1a
+ sh -c apt-get update -qq >/dev/null
+ sh -c apt-get install -y -qq apt-transport-https ca-certificates curl >/dev/null
+ sh -c curl -fsSL "https://download.docker.com/linux/raspbian/gpg" | apt-key add -qq - >/dev/null
Warning: apt-key output should not be parsed (stdout is not a terminal)
+ sh -c echo "deb [arch=armhf] https://download.docker.com/linux/raspbian buster stable" > /etc/apt/sources.list.d/docker.list
+ sh -c apt-get update -qq >/dev/null
+ [ -n  ]
+ sh -c apt-get install -y -qq --no-install-recommends docker-ce >/dev/null
+ sh -c docker version
Client: Docker Engine - Community
 Version:           19.03.2
 API version:       1.40
 Go version:        go1.12.8
 Git commit:        6a30dfc
 Built:             Thu Aug 29 06:18:36 2019
 OS/Arch:           linux/arm
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.2
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.8
  Git commit:       6a30dfc
  Built:            Thu Aug 29 06:12:41 2019
  OS/Arch:          linux/arm
  Experimental:     false
 containerd:
  Version:          1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683
If you would like to use Docker as a non-root user, you should now consider
adding your user to the "docker" group with something like:

  sudo usermod -aG docker your-user

Remember that you will have to log out and back in for this to take effect!

WARNING: Adding a user to the "docker" group will grant the ability to run
         containers which can be used to obtain root privileges on the
         docker host.
         Refer to https://docs.docker.com/engine/security/security/#docker-daemon-attack-surface
         for more information.
Pour autoriser l'utilisateur pi à lancer les commandes docker, saisissez les commandes suivantes :
sudo usermod -aG docker pi

Initialisation du cluster

Pour prendre en compte l'ajout du groupe, re-connectons à notre console SSH. Nous pouvons vérifier si Swarm est installé et initialisé.
docker info|grep Swarm

Swarm: inactive
Dans ce cas, Swarm n'est pas actif, il faut initialiser la machine qui deviendra le leader à savoir le Raspberry Controller. Lancer la commande suivante pour le mode NAT :

Mode NAT

pi@cnat:~ $ docker swarm init

Mode BRIDGE

Il faudra indiquer une adresse réseau pour éviter un message de ce type : "Error response from daemon: could not choose an IP address to advertise since this system has multiple addresses on different interfaces (172.19.180.254 on brint and 192.168.1.224 on br0) - specify one with --advertise-addr", vous devez préciser l'adresse IP de votre cluster. Pour ce cas l'adresse est celle de l'interface br0.
pi@cbridge:~ $ docker swarm init --advertise-addr 192.168.1.70
Le résultat affiche la ligne de commande avec le token pour ajouter nos workers (PI Zero).
Swarm initialized: current node (3zqj6io9py3o3iusmncjnn0ed) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-0kjhv52x2ehjuknmobcuxp0yncpioy7l4n6lhdpkyoimiuyz57-c9x0qrunhnmybct4wb3004vss 192.168.1.70:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
On peut retrouver le token avec cette commande.
docker swarm join-token -q manager
SWMTKN-1-0kjhv52x2ehjuknmobcuxp0yncpioy7l4n6lhdpkyoimiuyz57-0q7hox1c8zagowttn46yx8q33
On peut vérifier le fonctionnement de notre cluster Docker avec cette commande. Pour l'instant, seul la machine Leader est active.
pi@cbridge:~ $ docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
3zqj6io9py3o3iusmncjnn0ed *   cbridge             Ready               Active              Leader              19.03.2

Mode BRIDGE

Ajout des workers

Maintenant, il faut ajouter les workers à notre cluster. Nous installons Docker pour chaque PI Zero.
curl -sSL https://get.docker.com | sudo sh
Pour autoriser l'utilisateur pi à lancer les commandes docker, saisissez les commandes suivantes :
sudo usermod -aG docker pi
Connectez le PI Zero au cluster Docker avec la commande affichée lors de l'initialisation de Swarm :
docker swarm join --token SWMTKN-1-0kjhv52x2ehjuknmobcuxp0yncpioy7l4n6lhdpkyoimiuyz57-c9x0qrunhnmybct4wb3004vss 192.168.1.70:2377
Vous devez avoir cette réponse :
This node joined a swarm as a worker.
Lorsque tous les workers sont attachés au cluster, vous devriez avoir ce résultat :
docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
7cse8vh53n1ts8ycgf6vfyvcy *   cbridge             Ready               Active              Leader              19.03.2
oyxc472divutxdoli9hzy82r0     p1                  Ready               Active                                  19.03.2
vuskxibi9dep2nyuse4cxwl2j     p2                  Ready               Active                                  19.03.2
8gugy3uzeapo4lf5s1fgengiw     p3                  Ready               Active                                  19.03.2
6ymj940ashi8ycn7j5mi2y83g     p4                  Ready               Active                                  19.03.2

Utilisation du cluster Docker Swarm

Installation d'un visualisateur

Maintenant que notre docker Swarm est opérationnel, nous allons installer un visualisateur accessible avec une url web. Installez l'image alexellis2/visualizer-arm.
docker pull alexellis2/visualizer-arm
Ensuite créez et démarrez le container sur le Controller. le visualisateur sera accessible avec cette url http://192.168.1.70:5000
docker service create --name=viz --publish=5000:8080/tcp --constraint=node.role==manager --mount=type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock alexellis2/visualizer-arm:latest
Admirez le résultat.
Stacks Image 969860
Le ClusterHat PI en fonctionnement

Création d'un service Web

Avant de créer le service web, nous allons créer un réseau pour que les conteneurs puissent communiquer entre eux.
docker network create --driver overlay networkpi
Ensuite nous allons créer deux containers Web avec l'image alexellis2/nginx-arm. Nous allons contraindre le déploiement de ces containers aux workers.
docker pull alexellis2/nginx-arm
docker service create --constraint node.role==worker --replicas 2 -p 8080:80 --network=networkpi --name web alexellis2/nginx-arm
Les deux containers sont déployés dans les workers p1 et p2
Stacks Image 969863
Nous accédons à notre application web avec l'url suivante http://192.168.1.70:8080
Stacks Image 969924
Pour vérifier le fonctionnement de notre cluster, nous allons augmenter le nombre de container pour ce service pour avoir plus d'instance avec cette commande :
docker service scale web=4
Nous avons maintenant quatre containers pour le service web.
Stacks Image 969927

Test de la haute disponibilité

Nous allons vérifier le fonctionnement de notre cluster en testant la haute disponibilité. Admettons que deux workers tombent en panne. Pour l'exemple, arrêtons le p2 et le p4.
clusterhat off p2
clusterhat off p4
Après l'arrêt de p2 et de p4, les containers sont automatiquement déplacés dans les workers disponible. Si nous n'avions pas notifié une contrainte de déploiement seulement sur les workers, le mécanisme de haute disponibilité aurait pu déplacer les containers dans le Controller.
Stacks Image 969934
Cet article est terminé pour l'instant. Passons à la supervision de ce cluster.

Références

comments powered by Disqus
comments powered by Disqus
 Vous êtes ici: