cloud:2017:tp_network [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.
=====I. Mise en place =====

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 [[https://documentation.univ-lyon1.fr/sriv|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

=====2. Écoute des échanges =====

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

=====3. Docker gateway =====

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.
=====4. Étudier les namespaces =====
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.

=====5. On connecte tous les éléments =====

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
=====6. Schéma d'architecture =====

Pour finaliser votre rapport vous devez produire un schéma d'architecture. Vous pouvez utiliser //Microsoft Visio// ou bien [[https://www.draw.io/|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)