cloud:2016:tp_swarm2

Swarm, docker-machine, réseau overlay

Pour ce TP vous allez créer 3 VMs, vous utiliserez la flavor xxsmall et l'image snap-tp-dm. Ces machines ne seront pas conservées donc prenez garde à bien récupérer les données intéressantes dessus avant vendredi 20/01. Nous somme assez limités, je vous demande donc de bien travailler en binôme.

En raison du manque de VMs et du manque de clef possible nous avons ajouté un utilisateur à demander aux charger de TPs. Il y a aussi un autre projet : Ricoker. C'est dans ce dernier projet qu'il faut créer des machines virtuelles (pour la partie docker-machine). Attention, il y a un firewall qui isole chaque réseau de VMs donc chaque projet. Vous ne pouvez a priori pas faire le TP avec des machines placées dans des projets différents.

  • QPrélimminaire) : Créez une machine via l'interface openstack avec la flavor xxsmall et l'image snap-tp-dm. Appelez la VM VOTRENOM-manager

<hi #ff7f27>Ce TP doit être rendu sous la forme d'un rapport avant lundi 16/01 sur tomuss</hi>. Dans le sujet, pour chaque question, il faut mentionner les commandes nécessaires à la réalisation sans que cela soit précisé. Certaines des questions demandent des informations supplémentaires (et dans ce cas, cela est précisé).

Docker machine est un script qui permet de générer des machines virtuelles et d'installer docker automatiquement. Il est capable d'utiliser plusieurs hyperviseurs comme virutalbox ou openstack. Vous pouvez l'installer en utilisant la documentation ici. Vous avez une documentation plus spécifique à openstack ici

La commande docker-machine est assez simple car elle signale la plupart des options qui lui manque. Je rappelle (ou vous apprend) que :

  1. le driver est openstack
  2. l'url d'authentification est http://192.168.236.2:5000/v2.0/
  3. le nom d'utilisateur et le mot de passe sont ceux qui vous permettent de vous connecter
  4. le tenant est le projet openstack où créer les machines
  5. le nom de l'image à utilisé est celui d'une VM par défaut (car docker-machine s'occupera des configurations) : Ubuntu 16.04 LTS Xenial
  6. Attention il faut bien spécifier les options de proxy via l'option engine-env qui permet de spécifier une variable d'environnement1). Cela permettra de configurer le docker installé pour l'utilisation du proxy de l'université et s'utilise de cette manière :
docker-machine ... --engine-env HTTP_PROXY="http://adresse_de_votre_proxy:port" ... NOMDELAMACHINE

docker-machine sauvegarde ses informations dans le répertoire ~/.docker/machine/. Si à un moment docker-machine rm … ne fonctionne pas car openstack n'a pas créé la machine correspondante, il suffit d'effacer le répertoire ~/.docker/machine/machines/NOMDELAMACHINE.pour que docker-machine oublie cette denière. <hi #ff7f27>Avec le rapport du TP, vous joindrez l'archive du répertoire ~/.docker mentionnant les VM crées par docker-machine</hi>.

  • QI.1) En utilisant docker-machine, créez 2 machines qui serviront de nœuds de travail pour swarm. Appelez-les VOTRENOM-node1 et VOTRENOM-node2.

Vous pouvez ensuite voir les nœud gérés par docker-machine via la commande docker-machine ls, en supprimer une par docker-machine rm, vous connecter sur le serveur via docker-machine ssh

Une commande intéressante est docker-machine env. En effet, elle fournit des variables d’environnement qui lorsqu'elles sont configurées permettent d'utiliser le client docker de votre machine locale pour agir sur les dockers des machines gérées par docker-machine. Lancer la commande

docker-machine env --no_proxy VOTRENOM-node1''
  • QI.2) À quoi servent les variables DOCKER_TLS_VERIFY et DOCKER_CERT_PATH ?

Si vous lancez la commande eval $(docker-machine env –no_proxy VOTRENOM-node1) les variables d'environnement sont configurées et une commande docker quelconque sera transmise au deamon docker de la machine DOCKER_HOST. Attention, le proxy de l'université peut de nouveau causer des problèmes car docker utilise le protocole HTTP donc utilise le proxy et le proxy de l'université refuse la connexion à un certains nombre de port. Votre VM peut contacter directement le serveur docker, il faut donc lui dire de ne pas utiliser le proxy. Pour cela, l'option no_proxy de docker-machine env reconfigure la variable NO_PROXY correctement.

  • QI.3) Initialiser un cluster swarm dont le manager est votre machine principale et les noeud de travail les machines node1 et node2.
    • Pour configurer le manager utiliser la commande docker normale.
    • Pour configurer les deux workers ne vous connectez pas directement dessus mais utilisez les variables d’environnement via la commande docker-machine env

Dans un précédent TP, vous avez créé un réseau entre les dockers. Mais ce dernier était limité à une seul machine ce qui ne permettra pas de faire vraiment de l'équilibrage de charge. Pour allez plus loin, il faut utiliser swarm et un réseau de type overlay. Les différentes méthodes sont expliquées ici. Nous allons utiliser la méthode la plus simple où swarm gère le réseau et de plus l'authentification des VM qui doivent accéder à ce réseau.

  • QIII.1) Créez un réseau overlay utilisant les adresses 10.10.0.0/24, nommez le VOTRENOM-network.
  • QIII.2) Créez un service nommé test et utilisant ce réseau à partir d'une image classique par exemple nginx. Ce service doit avoir 3 répliquas pour que chaque VM instancie un docker. Une fois cela fait relevez sur chacun des dockers les adresses utilisées et testez le fait qu'ils puissent se pinguer via le réseau overlay.

Via swarm, on peut lancer des images docker présentent sur un dépot (registry) mais pas une image locale. Par exemple une image crée via un dockerfile qui est locale ne peut pas être utilisée directement. Pour créer un service qui utilise ce type d'image, il faut tout d'abord la déposer dans un registry. Pour ne pas polluer le registry par défaut, il faut créer un registry privé accéssible par tout le cluster. Ce qui se fait facilement (grâce à docker/swarm justement).

  • QIV.1) Tout d'abord créer un service utilisant l'image registry (qui fait des dépots docker), dans le réseau VOTRENOM-network, avec le nom registry et qui partage le port 5000 avec les machines hôtes. Ne demander qu'un seul répliqua.
  • QIV.2) Sur quel VM est effectivement lancé le docker registry ? Les 3 VMs peuvent-elles effectivement accéder au port 5000 de la machine locale ? Faites le test.

Utilisez le Dockerfile fourni ici. Ce dernier ajoute l'utilitaire wget au docker nginx officiel. <hi #ff7f27>L'utilisation de nginx est arbitraire et n'est pas très importante. Les étudiants qui souhaitent en parallèle avancer sur le TP d'IS peuvent utiliser un autre type de serveur</hi>. Pour que l'image soit déposée sur le registry privé, il faut que son tag commence par localhost:5000/. Vous pouvez donc la nommer localhost:5000/VOTRETAG directement lors du buildretagger une image via la commande :

docker tag ANCIENTAG NOUVEAUTAG
  • QIV.3) Recréez l'image à partir du Dockerfile, tagguez la correctement et envoyez la sur le registry local2).
  • QIV.4) Créez un service avec 2 répliquas et vérifiez que les dockers correspondant sont bien lancés sur des machines différentes3).

Pour le TP “Intergitiel et Service”, il faut de plus que chaque répliqua s'enregistre auprès d'un serveur. Pour cela, nous allons modifier le démarrage des dockers pour qu'ils accèdent à une adresse prévue avant de démarrer nginx. Pour cela, la commande de démarrage doit être remplacée par le script suivant grâce à wget. Le serveur que vous allez contacter ici ne sera qu'un simple nc :

nc -kl 8080

C'est une commande qui lance un serveur en écoute sur le port 8080, ce serveur ne répondra rien et ne fera qu'afficher les requêtes des clients. Attention n'oubliez pas de modifier l'adresse du serveur à contacter dans ce script, vous devez mettre l'adresse du serveur où vous avez lancer nc

  • QV.5) Créez le service correspondant et testez le fait que les requêtes envoyées mentionnent bien des adresses IP différentes (sur la première ligne).

Dans le rapport, affichez le résultat de la commande qui donne les adresses IP de tous les conteneurs dockers lancés sur les 3 VM du cluster.

Pour automatiser vos déploiement, il est plus pratique d'utiliser un fichier yaml pour décrire votre application. Comme pour le premier TP avec docker-compose, vous allez maintenant utiliser docker stack.

Vous devez supprimer votre précédent service avec docker service rm.

Ecrivez votre fichier yaml pour lancer votre image localhost:5000/VOTRETAG avec 2 replicas.

Lancez le stack avec la commande docker stack up -c votre fichier

Lors de la mise en place d'application, il y a de nombreuses données sensibles comme les certificats ou les mots de passe. Pour ne pas les mettre en clair dans vos fichiers, docker propose la fonction secret.

Maintenant, vous allez créer un secret avec la commande docker secret. Puis modifier votre fichier yaml afin de lui indiquer qu'il peut accéder à ce secret externe.

Quand vous avez fini vous pouvez modifier le fichier afin d'afficher votre secret :

echo “mon secret :” . file_get_contents(“/var/run/secrets/nom de votre secret”,“r”);

Ne pas oublier de rebuild votre image et de recréer votre stack.

<hi #ff7f27>N'oubliez pas de joindre au rapport l'archive du répertoire de docker-machine, les différents dockerfiles utilisés</hi>


1)
donnez une valeur pour HTTP_PROXY et HTTPS_PROXY
2)
attention il y a 3 chose à faire : la construction de l'image docker build …, le fait de lui donner le bon tag localhost:5000/TRUC et l'envoie dans le registry docker push …
3)
en cas de problème, si certains nœuds n'ont pas accès au fichier image, seule la machine qui détient l'image locale lance les répliquas
  • cloud/2016/tp_swarm2.txt
  • Dernière modification : 2018/01/12 16:11
  • de romain.chanu