Table des matières

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.

<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 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>.

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''

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.

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 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.

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).

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

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 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

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>

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