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 : contact@rhopenlabs.africa
