Il s'agit d'un TP noté. Il faudra rendre un rapport rédigé et imagé au plus tard au 04/05/2018.

Avec l'aide de docker-machine et des instructions ci-dessous créer 3 instances de type m1.xsmall vous devez utiliser l'image “SRIV-SVC”. Le hostname doit comprendre votre prénom et le type de noeud swarm (workerN ou manager).

export OS_USERNAME=$(read USER; echo $USER)
export OS_DOMAIN_NAME=univ-lyon1.fr
export OS_SSH_USER=ubuntu
export OS_PASSWORD=$(read -s PASSWORD; echo $PASSWORD)

• QI.1) Sur un nœud, prenez une capture d'écran de vos cartes réseaux, d'où vient la carte réseau en plus de Loopback et ens3? Dans le cadre de Docker à quoi sert cette carte réseau? Quel est le driver docker associé à cette carte?
• QI.2) Notez la sortie de la commande docker network ls pour la question I.4.

Maintenant, vous pouvez initialiser votre cluster swarm avec docker swarm init. Puis intégrez vos workers à votre cluster.

• QI.3) Sur un nœud, affichez vos cartes réseaux, constatez les différences avec la question QI.1, dans une image montrez la différence? Quel est le rapport entre cette nouvelle carte et swarm?
• QI.4) Vous pouvez à nouveau utiliser docker network ls, que constatez vous?

Faites un build de cette image sur les 3 machines ou vous pouvez utiliser un repository c'est à votre convenance.

Petite astuce, pour faire les captures de l’hôte docker depuis votre machine vous pouvez utiliser cette méthode:

mkfifo /tmp/wirepipe
nohup wireshark-qt -k -i /tmp/wirepipe
docker-machine ssh XXXX sudo tcpdump -i ens3 -w - not port 22 > /tmp/wirepipe

Vous allez créer un service avec 2 replicats à partir de l'image précédemment construite. On a lancé 2 replicats alors que notre cluster est composé de 3 machines, il y a donc une machine sans container. Connectez vous sur cette machine faites une capture réseau du trafic. Lancer Firefox et faites des requêtes HTTP vers cet hôte.

• QII.1) En regardant les échanges sur ens3 avec l'aide d'un logiciel comme wireshark, est ce que le VNI est valide? Pourquoi Wireshark affiche 08 pour le champ flags?
• QII.2) Quelle est l'adresse du VTEP de l’hôte qui n’exécute aucun container? Donnez l'adresse du VTEP de l’hôte qui reçoit ensuite la requête.
• QII.3)Utlisez ctrl+shit+r sur Firefox plusieurs fois, regardez à nouveau Wireshark? Vous devriez trouver la nouvelle adresse du VTEP, donnez cette adresse.
• QII.4) Ajoutez une capture d'écran de wireshark, il faut voir toutes les couches du OSI Model apparaître. (l'encapsulation et le champ VXLAN, dans la section tout en bas)
• QII.5) Même s'il n'y a pas de container sur cette hôte, il possède une adresse IP dans le réseau overlay. Donnez cette adresse IP? (screenshot wireshark + screenshot commande docker)
• QII.6) Est ce qu'entre wireshark et la commande Docker les MACs correspondent? Est ce qu'il y a une relation entre l'adresse IP et l'adresse MAC?
• QII.7) Est ce que le VNI correspond entre docker et wireshark? Donnez le numéro de VNI utilisé.

Dés que vous avez initialisé votre swarm, vous avez vu apparaître cette nouvelle carte réseau docker_gwbridge. On va maintenant vérifier son fonctionnement. Vous allez maintenant sur un hôte avec un container actif. Faites un docker exec ping 134.214.100.6. Si vous êtes dans le container, vous pouvez le kill facilement, si vous êtes sur l’hôte, garder en tête que vous avez un ping qui tourne.

• QIII.1) Avec la commande docker inspect donnez l'adresse IP de votre container? Sur quel réseau cette adresse IP est située? Est ce qu'il est possible d'atteindre 134.214.100.6 en étant sur ce réseau?
• QIII.2) Faites un ip addr show dans votre container? Est ce qu'une nouvelle adresse IP apparaît? Si oui, faites un screenshort de la sortie de la commande.
• QIII.3) Sur l’hôte faites un ip addr show. Vous avez normalement 2 veth. Pour le moment, on va faire une recherche à l'aveugle, faites un wireshark sur un interface. Si vous voyez le ping, vous avez trouvé l'interface de l’hôte où la trame transite pour ping 134.214.100.6 sinon faites une capture sur l'autre veth
• QIII.4) Maintenant dans wireshark vous devriez voir l'adresse IP du container et non celle de l’hôte. Est ce qu'on est d'accord? Si oui, joignez une screenshot de wireshark sinon vous faites fausse route. Bien noter les informations sur cette veth @MAC et le nom, on s'en sert dans la prochaine section.
• QIII.5) Depuis votre hôte faites un ping vers votre container. Donnez l'adresse source et l'adresse destination avec l'aide de wireshark joignez un screenshot.

Docker ne respecte pas la convention pour les espaces de nom réseau. Il va falloir créer un lien afin qu'on puisse utiliser ip netns. Sur un hôte exécutez ces commandes:

sudo ln -s /var/run/docker/netns /var/run/netns
sudo ip netns

• QIV.1) Vous venez de lister les espaces de nom réseau sur votre hôte. Vous voyez le nom des namespaces ainsi que leurs id. Si vous faites un ip addr show sur votre hôte, est ce que vous retrouvez le netns id pour la veth de la question QIII.4? Joignez un screenshot avec les informations intéressantes des 2 commandes (ip addr show et ip netns)
• QIV.2) Dans ce namespace listez toutes les informations réseaux ip netns exec le nom ip addr show. Que constatez vous? Est ce qu'il s'agit d'un container?
• QIV.3) Maintenant, il faut trouver le namespace du réseau overlay, on peut s'aider de la commande docker network ls? Dans ce namespace le bridge br0 fait le lien entre l'interface vxlan0 et l'eth0 du container. Qu'est ce qui nous prouve ça avec la commande ip addr show?
• QIV.4) Sur un hôte sans container, si on affiche les informations réseaux du namespace ingress_box, à quel autre namespace est il connecté? A quoi sert il? Vous pouvez vous aider des identifiants des cartes réseaux.

Afin de faciliter la réalisation du schéma, nous allons utiliser la commande brctl show

• QV.1) Sur l'hôte avec container des questions précédentes voir quelles veth sont connectées à l'interface docker_gwbridge
• QV.2) Avec la même commande, on peut montrer que br0 connecte toutes les interfaces dans le réseau ingress. Prouvez le (screenshot)
• QV.3) Dans le namespace du réseau ingress, on peut afficher toutes les adresses MAC des containers et des container ingress_sbox ainsi que leurs adresses IP. Prouvez le avec une screenshot (protocole de correspondance entre la couche 2 et la couche 3)
• QV.4) On a fait plusieurs tests depuis l’hôte sans container et on arrivait a joindre notre container. On comprend que Docker écoute sur le port même sans container puis qu'il envoie la requête à un hôte avec un container. Avec la commande iptables -L, vous pouvez prouver que le port est ouvert. Vers quelle adresse IP les requêtes sont envoyées? Vous pouvez vous aider de la commande iptables -t nat -nL.
• QV.5) On sait que les requêtes sont envoyées vers le réseau ingress_sbox (adresse IP de ce namespace). Vous pouvez utiliser la même commande dans le namespace pour voir où la requête est ensuite envoyée. A quelle adresse IP? Est ce qu'il s'agit d'une IP distants ou locals?

Pour la réponse précédente vous avez peut être vu le mot ipvs, il s'agit du load balancer implémenté dans le noyau Linux

• QV.6) Avec la commande ip netns exec ingress_sbox iptables -nL -t mangle vers quelle adresse IP les requêtes sont envoyées? A quoi correspond cette IP? Est ce un VTEP? Si non, qu'est ce que c'est?

Pour le plaisir on peut maintenant regarder les connexions actives avec la commande ip netns exec ingress_sbox ipvsadm -ln et on comprend comment le load balancing se fait sur un simple GET répétitif

Pour finaliser votre rapport vous devez produire un schéma d'architecture. Vous pouvez utiliser Microsoft Visio ou bien draw.io.

Sur ce schéma, il doit apparaître :

• Vos 3 membres du cluster swarm
• les adresses IP des 3 membres
• Le tunnel vxlan entre les 3 membres et spécifié le VNI
• Sur un hôte avec un container, on affiche les 3 namespaces avec toutes les cartes (nom de carte, adresse IP et identifiant)
• Sur un hôte sans container, on affiche les 2 namespaces avec toutes les cartes (nom de carte et adresse IP)