cloud:2016:tp_swarm2 [Cours de Fabien Rico]

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== 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é).
=====I. Docker Machine =====
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 [[https://docs.docker.com/machine/install-machine/|documentation ici]]. Vous avez une documentation plus spécifique à [[https://docs.docker.com/machine/drivers/openstack/|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 :
  - le driver est ''openstack''
  - l'url d'authentification est ''http://192.168.236.2:5000/v2.0/''
  - le nom d'utilisateur et le mot de passe sont ceux qui vous permettent de vous connecter
  - le //tenant// est le projet openstack où créer les machines
  - 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''
  - **Attention** il faut bien spécifier les options de proxy via l'option //engine-env// qui permet de spécifier une variable d'environnement((donnez une valeur pour ''HTTP_PROXY'' et ''HTTPS_PROXY'')). 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''

 
=====III. Réseau overlay=====

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 [[https://docs.docker.com/engine/userguide/networking/get-started-overlay/|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.

=====IV. Utilisation d'image locale =====

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 {{ cloud:2016:scripts.zip |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 //build// où //retagger// une image via la commande :
  docker tag ANCIENTAG NOUVEAUTAG

  * QIV.3) Recréez l'image à partir du {{ cloud:2016:scripts.zip |Dockerfile}}, tagguez la correctement et envoyez la sur le //registry// local((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 ...'')).
  * 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érentes((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)).

=====V. Préparation du TP Intergiciel et service=====
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 {{ cloud:2016:scripts.zip |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.


===== Création d'un fichier de déploiement =====

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>