Une vraie gestion du réseau pour Docker avec Weave
J’ai déjà beaucoup parlé de Docker dans ce blog. Et comme le projet prend de l’ampleur, je suis à l’affût de nouveautés dans ce domaine.
Dans les limitations habituelles de Docker, il y avait principalement la gestion du réseau et la gestion des logs.
Bon, pour le deuxième problème, je n’ai pas encore de solution optimale à vous proposer.
Par contre un outil de gestion du réseau qui est très intéressant : Weave.
Ce que fait Docker
Par défaut, sous Docker, l’hôte a une interface virtuelle docker0 avec une adresse en 172.17.42.1/16.
Les containers ont des adresses attribuées automatiquement (pas par DHCP) dans le réseau 172.17.0.0/16.
On peut utiliser pipework pour configurer les containers.
Principale limitation :
L’hôte fait du masquage d’adresse (Nat) pour que les containers aient accès à l’extérieur.
Quand le port d’un container doit être accessible de l’extérieur on l’expose (l’hôte fait de la redirection de ports).
Ce qu’apporte Weave
Tout ça est très bien à petite échelle, mais si on veut aller plus loin au niveau réseau, on est bloqué.
Weave propose de remplacer le Nat par du routage.
Ça permet de créer des réseaux pour des groupes de containers, même si ils sont sur des hôtes différents.
Un peu de réseautage avec Weave
Pour résumer leur page Github très bien expliquée. On part de l’idée qu’on a deux hôtes Docker.
On installe Weave sur chacun d’eux :
apt-get install -y wget ethtool conntrack
sudo wget -O /usr/local/bin/weave https://raw.githubusercontent.com/zettio/weave/master/weaver/weave
sudo chmod a+x /usr/local/bin/weave
On lance weave sur chacun d’eux, les weave sont connectés entre eux :
srv1# weave launch 10.0.0.1/16
srv2# weave launch 10.0.0.2/16 srv1
Puis, on lance des containers dans différents sous réseaux :
Sur srv1 :
srv1# c1=$(weave run 10.0.1.1/24 -t -i dans-les-nuages/humhub)
srv1# c2=$(weave run 10.0.2.1/24 -t -i dans-les-nuages/owncloud)
Sur srv2 :
srv2# c3=$(weave run 10.0.1.2/24 -t -i dans-les-nuages/humhub)
srv2# c4=$(weave run 10.0.2.2/24 -t -i dans-les-nuages/owncloud)
Dans mon exemple, c1 et c3 se ping car ils sont dans le même sous réseau.
Par contre, c1 ne peut pas envoyer de ping à c2.