10 votes

Comment résoudre correctement l'adresse IP d'un autre conteneur dans un essaim de Docker (DNS) ?

Je m'amuse à déployer des services dans un essaim de Docker. J'ai du mal à laisser un conteneur se connecter de manière cohérente à un conteneur situé sur un autre nœud.

Disons que je construise un pool GlusterFS ; je dois ouvrir un terminal dans chaque conteneur et ajouter le démon Gluster au pool. Comment puis-je faire référence aux autres conteneurs du pool ? Actuellement, j'utilise une adresse IP, mais que se passe-t-il si un conteneur meurt et est recréé ? Pour autant que je sache, il n'y a aucune garantie que le nouveau conteneur aura la même adresse IP. Je pourrais utiliser le serveur DNS intégré pour faire référence aux autres conteneurs, mais je ne peux résoudre que les noms de conteneurs et les ID de conteneurs en adresses IP, et les deux changeront si un conteneur meurt et est recréé, donc il n'y a aucun intérêt.

Ne devrais-je pas être en mesure de résoudre la noms d'hôtes des autres conteneurs à leurs adresses IP ? Je pensais que c'était le cas, mais ce n'est pas le cas.

Y a-t-il des solutions à mon énigme ? (J'ai l'impression que je m'y prends mal pour utiliser les services, et que dans ce cas, je devrais créer manuellement un conteneur sur chaque nœud).

10voto

Murmel Points 885

En fonction de votre situation exacte, vous devez utiliser différentes solutions :

Résolution des noms d'hôtes à l'intérieur d'un service

Problème : Vous avez plusieurs conteneurs (/replicas) du même service. serviceX par exemple :

  • conteneur a1b3d130275a avec le nom d'hôte serviceX.1.nq4rjbae
  • conteneur 65040b1cada6 avec le nom d'hôte serviceX.2.m9wl1f1r
  • conteneur 944704427b9e avec le nom d'hôte serviceX.3.3d08baql

Maintenant, vous voulez récupérer le nom d'hôte de la seconde ( serviceX.2.m9wl1f1r ) et le troisième ( serviceX.3.3d08baql ) à partir du premier conteneur ( serviceX.1.nq4rjbae ).

Docker propose une solution appelée découverte des conteneurs en utilisant une requête DNS contre tasks.$serviceName par exemple :

nslookup tasks.serviceX
[...]
Name:      tasks.serviceX
Address 1: 10.0.0.205 a1b3d130275a  (<- resolved locally by /etc/hosts)
Address 2: 10.0.0.206 serviceX.2.m9wl1f1r
Address 3: 10.0.0.207 serviceX.3.3d08baql

Il est également question de faire serviceX.{1,2,3} Mais à l'heure actuelle, aucun de ces éléments n'est mis en œuvre, de sorte que cette solution ne fonctionne qu'au moment de l'exécution.

Remarque : la définition du nom d'hôte à l'aide de la fonction de modèle (comme docker service create ... --hostname {{.Service.Name}}.{{.Task.Slot}} ) rendrait les noms d'hôtes prévisibles localement, mais ils ne pourront pas être résolus par d'autres conteneurs.

Résolution des noms d'hôtes entre services

Problème : Vous avez plusieurs conteneurs pour les différents services. serviceX , serviceY . Mais un seul conteneur par service, par exemple :

  • conteneur a1b3d130275a avec le nom d'hôte serviceX.1.nq4rjbae
  • conteneur 65040b1cada6 avec le nom d'hôte serviceY.2.m9wl1f1r

Et vous voulez vous connecter à un conteneur d'un autre service ( serviceX ) d'un service ( serviceY ) et vice versa. Il suffit d'utiliser le --name paramètre :

docker service create --name=serviceX serviceX
docker service create --name=serviceY serviceY

Et vous pouvez compter sur ce conteneur a1b3d130275a sera résoluble par le nom d'hôte serviceX et conteneur 65040b1cada6 par nom d'hôte serviceY .

Référence :

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X