infrastructure:installation_docker_swarm_cluster

Cette documentation ne reflète plus l’infra actuelle de Picasoft. Nous n’utilisons plus Swarm pour des raisons de robustesse et de simplicité.

Installation d'un cluster Docker Swarm

Cette page a pour but la mise en place d’un cluster Docker Swarm sur deux noeuds avec un partage des données via un volume partagé utilisant GlusterFS.

Afin de stocker les données, nous devons créer un disque dédié au volume GlusterFS. Pour se faire, il faut aller (sur l’interface proxmox) sur la VM pour laquelle on veut ajouter un disque, puis aller dans la rubrique “Hardware” puis sélectionner l’option “Add”, en haut a gauche du cadrant. On clique dessus et on clique sur l’option “Hard disk”. On configure ce disque de telle sorte a ce qu’il ai une capacité de 15G, au format raw, avec un “storage” local (qui correspond en fait au ssd). On monte le disque dur en SATA.

Le disque devrait être bien ajouté a la liste de composants hardware de la VM. Toutefois, il apparaît en rouge. Pour qu’il soit bien pris en compte et rattaché à la VM, il est nécessaire de la relancer.

Une fois que le disque dur est bien prit en compte par la VM, il est nécessaire d’executer les commandes suivantes dans la VM:

  1. Verifier que le disque a bien été ajouté/est détectable par l’OS: $ fdisk -l
  2. On ajoute le “physical volume” avec pvcreate pour le rendre visible au niveau de LVM. Ainsi on pourra lui ajouter un volume group par dessus $ pvcreate /dev/sdb
  3. On créer un volume groupe data $ vgcreate vg01 /dev/sdb

C’est ce volume qui sera ensuite partagé avec les différents serveurs sur le réseau.

$ vgs
  VG   #PV #LV #SN Attr   VSize  VFree
  vg00   1   2   0 wz--n- 39,76g     0
  vg01   1   0   0 wz--n- 15,00g 15,00g

Sur la machine virtuelle, j’ai donc ajouté un nouveau disque d’une taille de 15G ici ajouté sur un groupe logique vg01. Je créé ensuite un volume logique (lv) à partir de ce vg et qui va prendre tout l’espace disponible

$ lvcreate -l 100%FREE -n data vg01

On peux maintenant formater ce disque et le monter sur la machine:

$ mkfs -t ext4 /dev/mapper/vg01-data.
$ echo "/dev/mapper/vg01-data /gluster-data ext4    defaults        0       2" >> /etc/fstab
$ mkdir /gluster-data && mount -a 

Une fois le volume monté, il faut maintenant créer un volume de plus haut niveau à l’aide de glusterFS. Cela permettra aux différentes machines de notre cluster d’accéder à un volume de données partagé et répliqué automatiquement entre les nœuds. Cela signifie qu’en cas de panne, le nœud restant sera toujours en mesure de fournir le service évitant ainsi l’interruption de service.

La première chose à faire et de s’assurer que les différentes machines du cluster se connaissent les unes les autres:

$ cat /etc/hosts
   127.0.0.1	localhost
   91.224.148.57   pica01 pica01.picasoft.net
   91.224.148.60   pica02 pica02.picasoft.net

Il faut ajouter les clés du repo ainsi que le repo contenant les packages

$ wget -O - http://download.gluster.org/pub/gluster/glusterfs/3.9/rsa.pub | apt-key add -
$ echo deb http://download.gluster.org/pub/gluster/glusterfs/3.9/LATEST/Debian/jessie/apt jessie main > /etc/apt/sources.list.d/gluster.list
$ apt-get update
$ apt-get -y install glusterfs-server

Ensuite, on ajoute le second serveur à partir du premier noeud du cluster. Ici, on lance donc sur pica01

$ gluster peer probe pica02
$ gluster peer status
  Number of Peers: 1
  Hostname: pica02
  Uuid: 36530258-860b-4403-85b3-3de1fd6bb47a
  State: Peer in Cluster (Connected)
  

On peut maintenant créer un volume répliqué que l’on va configurer en mirroring afin d’avoir une copie parfaite des données entre les noeuds.

$ gluster volume create gluster-data replica 2 transport tcp pica01:/gluster-data pica02:/gluster-data force
$ gluster volume start gluster-data

Une fois le volume créé, on peut vérifier l’état de celui-ci via la commande:

$ gluster volume info
  Volume Name: gluster-data
  Type: Replicate
  Volume ID: 24ec2dcb-84fe-4981-9e01-1a5614cd209b
  Status: Started
  Snapshot Count: 0
  Number of Bricks: 1 x 2 = 2
  Transport-type: tcp
  Bricks:
  Brick1: pica01:/gluster-data
  Brick2: pica02:/gluster-data

Afin d’éviter que n’importe qui puisse accéder à notre volume et faire des écriture, on doit limiter les droits en écriture aux machines pica01/02

$ gluster volume set gluster-data auth.allow pica02

On peut maintenant ajouter une ligne au fichier fstab pour lancer le montage automatique du volume. À noter qu’il faut adapter le point de montage en fonction de la machine

$ echo "pica01:/gluster-data /DATA glusterfs defaults,_netdev 0 0" >> /etc/fstab
$ mkdir /DATA && mount -a

Pour le moment, le montage automatique au boot de la machine ne fonctionne pas. Pour palier à ce problème, j’ai ajouté les lignes suivante a la fin du fichier /etc/rc.local (avant l’instruction exit 0 bien sûr)

systemctl start glusterfs-server
mount -a

Docker va nous servir pour mettre en place et faire tourner les conteneurs contenant les services. Avant de mettre en place un cluster Swarm permettant de répartir automatiquement les conteneurs sur les différentes machines, il faut installer le Docker engine sur chacune de nos machines. Pour cela:

$ apt-get update
$ apt-get install \
   apt-transport-https \
   ca-certificates \
   curl \
   software-properties-common
$ curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -

Verifier que la signature soir bien 9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88

$ apt-key fingerprint 0EBFCD88
$ add-apt-repository \
 "deb [arch=amd64] https://download.docker.com/linux/debian \
 $(lsb_release -cs) \
 stable"
$ apt-get update && apt-get install docker-ce
$ systemctl start docker && systemctl enable docker

On peut vérifier que l’installation s’est bien déroulée à l’aide de la commande docker version

$ docker version
  Client:
   Version:      1.12.3
   API version:  1.24
   Go version:   go1.6.3
   Git commit:   6b644ec
   Built:        Wed Oct 26 21:39:14 2016
   OS/Arch:      linux/amd64
  Server:
   Version:      1.12.3
   API version:  1.24
   Go version:   go1.6.3
   Git commit:   6b644ec
   Built:        Wed Oct 26 21:39:14 2016
   OS/Arch:      linux/amd64

On peut maintenant déployer le cluster Swarm à l’aide des commandes suivantes: Sur pica01

$ root@pica01:~# docker swarm init
  Swarm initialized: current node (alpfdvrzjrbiuvya7nyiwhbjg) is now a manager.
  To add a worker to this swarm, run the following command:
      docker swarm join \
      --token SWMTKN-1-0aieljefhgeirgjkzrjkbgerohzg69rnlj6why0dmaddseswnsmntldd9-ci1ew93yu91p7dfl1gxlur1zh \
      91.224.148.57:2377
  To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

Sur pica02 on lance la commande proposée par pica01

$ root@pica02:~# docker swarm join \
>     --token SWMTKN-1-0aieljefhgeirgjkzrjkbgerohzg69rnlj6why0dmaddseswnsmntldd9-ci1ew93yu91p7dfl1gxlur1zh \
>     91.224.148.57:2377
This node joined a swarm as a worker.

Sur le nœud master, on peut voir les nœuds du cluster:

$ docker node ls
ID                           HOSTNAME  STATUS  AVAILABILITY  MANAGER STATUS
9c3xnjjo1u6mbol5qtbeh92cb    pica02    Ready   Active
alpfdvrzjrbiuvya7nyiwhbjg *  pica01    Ready   Active        Leader

Dans le cas d’un cluster à deux noeuds, la notion de manager et de client est difficile à mettre en place. On peut donc passer le second noeud comme manager. En cas de panne du premier, il sera possible de lancer des commandes “service” sur le second noeud

$ docker node promote pica02

Le cluster est maintenant prêt à être utilisé. Avant de lancer les premiers services, il faut savoir que Docker lorsque est utilisé en mode Swarm ne permet plus de lier des conteneurs les uns aux autres comme c’est le cas avec Docker en standalone. Pour palier à ce problème, il faut créer une réseau overlay qui par la suite permettra de contacter n’importe quel conteneur sur ce réseau en utilisant son nom. La commande ci-dessous permet de créer un réseau overlay sur les différentes machines

$ docker network create --driver overlay --opt encrypted pica-net

Maintenant, lorsque l’on lance différents services sur le réseau pica-net à l’aide du paramètre –network, ils seront en mesure de communiquer à partir du nom qui leur aura été attribué au lancement.

Il est désormais possible de lancer les premiers services utilisant le volume partagé glusterfs pour la persistance des données. Par exemple, le lancement d’un conteneur dokuwiki peut se traduire avec la commande suivante:

$ docker service create --name dokuwiki --replicas 3 \ 
  --publish 3000:80 \
  --mount type=bind,source=/DATA/WEB/dokuwiki,target=/var/www/html \ 
  --network pica-net registry.picasoft.net:5000/pica-dokuwiki

Cette commande va automatiquement déployer 3 instances dokuwiki sur les différents noeuds du cluster en fonction de la charge de ceux-ci. Le service est accessible sur le port 3000 sur chacune des machines du cluster et ce même si le noeud n’héberge pas le service. Il est par la suite possible d’augmenter ou de réduire le nombre d’instance à l’aide de la commande

$ docker service scale dokuwiki=1
  dokuwiki scaled to 1
$ docker service scale dokuwiki=4
  dokuwiki scaled to 4
  

Bon à savoir: Pour qu’une image puisse être lancée sur les deux serveurs, il faut au préalable avoir télécharger cette image sur les différents noeuds du cluster. Sans cela, Swarm va scheduller les conteneurs sur une unique machine qui possède les images.

Contact en cas de questions : Antoine Picasoft

  • infrastructure/installation_docker_swarm_cluster.1494702945.txt.gz
  • (modification externe)