8 Septembre 2016

Documents intéressants

• Gestion Swarm bare metal avec docker-machine
• Utilisation du nouveau mode Docker Swarm
• Sécurité de Docker
• Sécurité Docker 2
• Documentation officielle Swarm
• Sécuriser une Swarm Docker

Mise en place d’un cluster sur des machines réelles

Précédement les expérimentation étaient faites sur machine virtuelle afin de pouvoir rapidement tester différentes configuration possible. À présent, afin de pouvoir tester un programme de crossmatch (croisement de données entre de gros fichiers cvs), un cluster de machines réelles est plus adapté (stockage …)

Fonctionnement

La fonctionnalité Swarm de Docker est très récente (depuis la version 1.12.0) et son utilisation se veut plus simple que l’ancien système fonctionnant avec des containers.

Premièrement il faut déclarer une première machine comme maitre : docker swarm init --advertise-addr [ip-address] en indiquant l’IP de la machine, c’est cette IP que les noeuds suivant devront contacter donc attention à ce qu’ils soient tous sur le même sous réseau. Cette commande va retourner la commande qu’il faudra lancer sur tous les autre noeuds. EX : docker swarm join --token SWMTKN-1-3jv31q64ofkl3j20d8lxeq2eejyhcde7h1o25p6c0i1b1a2e3x-az1nzpiuxaa1ny8te8yocnv3i 192.168.99.105:2377 Une foit cette commande exécutée sur tous les noeud on peut vérifier l’état du cluster en lancant cette commande sur le maitre : docker node ls

Il est ensuite recommandé d’avoir un nombre impair de noeuds maitres supérieur à 1 pour avoir une résistance aux échecs (3 ou 5 sont recommandés en fonction de la taille du cluster). A savoir que plus de 7 est considéré comme inutile car entraine une baisse de performances. La commande est la suivante : docker node promote cds-stage-ms2 cds-stage-mv2

Les connexions entre tous les noeuds sont sécurisé par TLS par défaut, il est possible d’utiliser son propre certificat au besoin

Notre cluster de test

Dans ce cas si jamais la machine cds-stage-ms4 venait à tomber en panne ms2 ou mv2 prendrais immédiatement le relais

Utilisation des service Docker

Avec cette nouvelle fonctionnalité de Swarm Docker intègre les services. Un service peut être vu comme une instruction de container (comment le lancer, le nombre nécessaire) qui va ensuite être répartie sur différents noeuds.

Il est aussi possible de publier des ports pour ces services qui seront ensuite atteignables depuis n’importe quel noeud. Par exemple si on lance le service registery (stockage des images à la Docker hub) de cette façon : docker service create --name registry --publish 5000:5000 registry:2 Il sera possible d’accéder au service depuis n’importe quel noeud, peu importe lequel fait tourner réellement le service. Par exemple curl localhost:5000/v2/_catalog va retourner la liste des images disponible, cette commande fonctionnera sur tous les noeuds. De la même façon un machine située sur le même réseau pourra accéder au service par le biais de n’importe quel noeud. Exemple : curl 130.79.128.188:5000/v2/_catalog avec 130.79.128.188 l’IP d’un noeud arbitraire. De plus en cas de réplication des services les requettes sont réparties par un load balancer.

Il est aussi possible d’accéder aux différents service via le DNS intégré. Par exemple si je lance un service avec pour nom web-server, un curl vers http://web-server depuis une machine du cluster renverra la page du serveur web

Explication détaillées

Une application plus visible est possible avec nginx : docker service create --name web --replicas 3 --mount type=bind,src=/etc/hostname,dst=/usr/share/nginx/html/index.html,readonly --publish 8888:80 nginx va répliquer le service sur trois noeuds et translater le port 8888. Si on accède à http://{IP-d’un-noeud}:8888 on peut voir le round-robin en action car nginx renvoie le hostname. (Utiliser curl pour éviter d’avoir des résultats faussés par le cache du navigateur)

Déploiement de HDFS sur ce nouveau cluster

Commencons par déployer un service distribué plutot simple. La stratégie va être de déployer le service de stockage de hdfs en mode global (c’est à dire que chaque noeud fera tourner le container et en cas de panne ou redémarage le container sera redémarré au démarage de la machine).

1. Construction de la commande

docker service create --name namenode -e CORE_CONF_fs_defaultFS=hdfs://localhost:8020 -e CLUSTER_NAME=test -e CORE_CONF_hadoop_http_staticuser_user=root -e HDFS_CONF_dfs_webhdfs_enabled=true -e HDFS_CONF_dfs_permissions_enabled=false -p 50070:50070 -p 8020:8020 bde2020/hadoop-namenode:1.0.0

docker service create --name datanode --replicas 3 -e CORE_CONF_fs_defaultFS=hdfs://localhost:8020 -e CORE_CONF_hadoop_http_staticuser_user=root -e HDFS_CONF_dfs_webhdfs_enabled=true -e HDFS_CONF_dfs_permissions_enabled=false bde2020/hadoop-datanode:1.0.0

Situation actuelle : les datanodes ne se connectent pas au namenode, l’interface du namenode est cependant accessible depuis tous les noeuds