« Back
post_image

Le multihost networking avec Docker et Weave Networks

Par défaut, sur Docker, lorsque vous exécutez vos conteneurs, ils ne sont accessibles uniquement qu’a partir de conteneurs fonctionnant sur le même serveur, et ne peuvent donc pas communiquer avec les conteneur d’un autre host – sauf via l’exposition de port sur le serveur hôte afin de mettre en place un mapping entre le serveur et le conteneur.Une architecture mono-serveur soulève donc des manquements que nous pouvons citer ci-dessous :

  •  Il n’est pas possible de faire communiquer des conteneurs entre plusieurs serveurs, du coup vos micro-services ne pourront fonctionner que sur la même machine ce qui va être un point en panne
  •  Vous pouvez avoir besoin de faire fonctionner certains types de services sur des serveurs beaucoup plus performants que d’autres.
  •  Il n’est pas possible de communiquer avec des conteneurs docker hébergés sur un autre hôte
  • L’une des recommandations du modèle des applications basées sur des micro-service est la possibilité de pouvoir s’étendre à la demande en ajoutant de nouveaux conteneurs pour le même service, pour répartir la charge de traitement de requêtes entre plusieurs conteneurs. Et pour que cela fonctionne bien il faudrait que ces derniers soient démarrés sur plusieurs serveurs.
  •  La découverte des services dans ce modèle de réseau n’est pas aussi possible entre plusieurs serveurs.

Dans un environnement de développement et de test, cette architecture mono-serveur est tolérable du fait que vous pouvez très rapidement mettre en place un environment, exécuter vos micro-services sur la même machine et réaliser vos tests applicatifs.

Par contre en production il est primordial d’opter pour une architecture plus distribuée, qui est un élément très  important pour assurer le bon fonctionnement, la haute disponibilité, la résilience d’une architecture basée sur des micro-services ou des applications cloud natives. Le multihost networking peut être utilisé pour palier à ces différents problèmes. 

Fonctionnement du multihost network

Le multihost networking ou overlay est une abstraction d’un réseau existant(constitué de multiple vlans, routeurs, firewall) par la création d’un réseau virtuel. Ce réseau virtuel a pour but de dé-complexifier le réseau existant en implémentant un réseau simple permettant de faire communiquer les conteneurs fonctionnant sur plusieurs serveurs. Vous pourrez donc simplement mettre en liaison des conteneurs se trouvant sur des datacenter différents, des hébergeurs différents, ou encore connecter votre réseau local a un datacenter distant. Quelques caractéristiques du multihost networking :

  • Elle s’appuie sur des technologies réseau existantes pour fonctionner. Les 2 principales techniques utilisées sont le VXLAN (Virtual Extensible LAN) ou le BGP (Border Gateway Protocol). Ces technologies sont implémentées au niveau du noyau des systèmes d’exploitation récent, rendant donc possible l’overlay
  • Un processus logiciel s’exécutant sur chaque serveur et mettant en oeuvre les confirmation relatives a l’overlay. Ce processus va aussi communiquer avec les autres hôtes pour recueillir des informations nécessaire au bon fonctionnement du réseau (Par exemple pour la mise à jour des entrée dns, le service discovery, etc)
  • Une base de donnée distribuée de type etcd ou consul est utilisée pour stocker les informations découvertes et échanges entre les différents serveurs. Les informations présentes dans cette base seront accessible par les conteneur afin de faciliter la découverte des services.
  • Un serveur dns fonctionnant sur chaque serveur, ayant les informations sur tous les conteneurs permet d’assurer une résolution sur tout le réseau overlay.
  • L’abstraction du firewall pour les ouvertures de flux d’applications. Il suffit d’ouvrir un port TCP et UDP entre les hôtes et tout le trafic IP y sera encapsuler.
  • La sécurité : Le trafic pour être encrypté de bout en bout afin d’éviter toutes intrusion
  • La simplicité, le développeur n’a pas besoin de se soucier de la complexité du réseau. Il sait qu’il communique avec un service et n’a pas besoin de savoir les détails de connection vers le service en question.

Ci-dessous une image d’un réseau overlay, on peut bien voir une simplification et extension d’un réseau pour communiquer entre plusieurs datacenter. Vous pouvez avoir aussi bien des services on-premises ou sur le cloud.

Weave networks

L’une des solutions les plus utilisés pour la mise en place de la solution est weave networks, ce pour plusieurs raisons :

  • Simplicité de la mise en place. En moins de 15 minutes votre réseau overlay est en route
  • Weave encapsule le trafic entre serveurs via un tunnel vxlan
  • Vous avez la possibilité de crypter tout le trafic qui circule dans le réseau afin de vous assurer qu’il ne soit pas intercepté
  • Weave assure un équilibrage de charge entre vos services, il suffit de leur donner le même nom et le reste se fait automatiquement. Le trafic sera reparti entre les 2 services

Implementation et test de weave networks

Supposons que nous avons 3 serveurs sur lesquels nous souhaitons faire communiquer nos services.

Serveur 1, address IP : 10.136.1.26

Serveur 2, address IP : 10.136.1.27

Serveur 3, address IP : 10.136.1.28

Installer weave sur vos 3 serveurs.

Pour le faire, il suffit d’exécuter les commandes ci-dessous :

sudo curl -L git.io/weave -o /usr/local/bin/weave

sudo chmod a+x /usr/local/bin/weave

Configuration du peering

  • Sur le serveur 1

weave launch

eval $(weave env)

  • Sur le serveur 2

weave launch 10.136.1.26

eval $(weave env)

  • Sur serveur 3 :

weave launch 10.136.1.26 10.136.1.27

eval $(weave env)

Verification

Une fois ces commandes exécutées, vous pouvez vérifier le bon fonctionnement par le biais des commandes :

root@node01:~# weave status

        Version: 2.5.2 (up to date; next check at 2019/10/01 17:33:58)

        Service: router

       Protocol: weave 1..2

           Name: 6e:b2:81:6c:ac:b3(node01)

     Encryption: disabled

  PeerDiscovery: enabled

        Targets: 0

    Connections: 2 (2 established)

          Peers: 3 (with 6 established connections)

TrustedSubnets: none

        Service: ipam

         Status: ready

          Range: 10.32.0.0/12

  DefaultSubnet: 10.32.0.0/12

        Service: dns

         Domain: weave.local.

       Upstream: 127.0.0.1, 213.186.33.99

            TTL: 1

        Entries: 2

        Service: proxy

        Address: unix:///var/run/weave/weave.sock

        Service: plugin (legacy)

     DriverName: weave

root@node01:~#

root@node01:~# weave status peers

d2:d6:43:1d:51:de(node02)

   -> 10.136.1.26:6783      6e:b2:81:6c:ac:b3(node01)             established

   <- 10.136.1.28:53813     62:94:06:5a:dc:ae(node03)             established

62:94:06:5a:dc:ae(node03)

   -> 10.136.1.26:6783      6e:b2:81:6c:ac:b3(node01)             established

   -> 10.136.1.27:6783      d2:d6:43:1d:51:de(node02)             established

6e:b2:81:6c:ac:b3(node01)

   <- 10.136.1.27:43953     d2:d6:43:1d:51:de(node02)             established

   <- 10.136.1.28:59191     62:94:06:5a:dc:ae(node03)             established

Tests de communication.

  • Démarrer un conteneur sur un des 3 serveurs

docker run -itd –name service1 wordpress

  • Démarrer un autre conteneur sur un autre serveur

docker run -itd –name service2 wordpress

  • Faire un test de ping entre les 2

root@service1:/var/www/html# ping service2

PING service2 (10.32.0.2) 56(84) bytes of data.

64 bytes from service2.weave.local (10.32.0.2): icmp_seq=1 ttl=64 time=0.257 ms

64 bytes from service2.weave.local (10.32.0.2): icmp_seq=2 ttl=64 time=0.281 ms

64 bytes from service2.weave.local (10.32.0.2): icmp_seq=3 ttl=64 time=0.289 ms

— service2 ping statistics —

3 packets transmitted, 3 received, 0% packet loss, time 48ms

rtt min/avg/max/mdev = 0.257/0.275/0.289/0.023 ms

En exécutant cette commande sur chaque serveur, on retrouve bien tous nos services. La découverte est donc aussi fonctionnelle.

root@node01:~# weave status dns

service2        10.32.0.2       7bc0ed421519 6e:b2:81:6c:ac:b3

service1        10.44.0.0       ad1abd82d401 d2:d6:43:1d:51:de

A l’aide de weave, vous pouvez-donc déployer une architecture redondante, scalable et prête pour la production.

Par ailleurs, nous devons préciser que les actions telles que la scalabilité, le placement des conteneurs sur un serveur, le démarrage des conteneurs se font toutes manuellement. Il est aussi possible d’automatiser tout cela, en passant la main à un orchestrateur tel que kubernetes. Nous en parlerons plus en détail dans un autre article.

Nous espérons que cet article vous a plu et que vous pourrez en profiter dans le cadre de votre aventure dans le monde du Devops.

Si vous avez besoin d’assistance, n’hésitez pas à nous contacter à l’adresse : info@entrepreneur-numerique.cm

Nous suivre et partager 🙂
error20

About the Author

Leave a Reply

Copyright 2018 © Entrepreneur-Numerique.africa | CGU
error

Vous avez aimé? Partagez!