Comment lier les services Docker entre les hôtes?

Docker permet aux serveurs de plusieurs conteneurs de se connecter les uns aux autres via des liens et la découverte de services . Cependant, d'après ce que je peux voir, cette découverte de service est locale à l'hôte. Je souhaite implémenter un service qui utilise d'autres services hébergés sur une machine différente.

Il y a eu plusieurs approches pour résoudre ce problème dans Docker, telles que CoreOSjumpers , les services locaux de l'hôte qui sont essentiellement proxy vers l'autre machine, et tout un tas de projets github pour la gestion des déploiements Docker qui semblent avoir tenté de prendre en charge ce cas d'utilisation .

Compte tenu du rythme du développement, il est difficile de suivre les meilleures pratiques actuelles. Ma question est donc essentiellement:

1. Quelle est (le cas échéant) la méthode prédominante actuelle pour la liaison entre les hôtes dans Docker, et
2. Existe-t-il des plans pour prendre en charge cette fonctionnalité directement dans le système Docker?

Mettre à jour

Docker a récemment annoncé un nouvel outil appelé Swarm pour l'orchestration Docker.

Swarm vous permet de "rejoindre" plusieurs démons docker: vous créez d'abord un essaim, démarrez un gestionnaire d'essaim sur une machine et demandez aux démons docker de "rejoindre" le gestionnaire d'essaim en utilisant l'identifiant de l'essaim. Le client docker se connecte au gestionnaire d'essaim comme s'il s'agissait d'un serveur docker normal.

Lorsqu'un conteneur a démarré avec Swarm, il est automatiquement affecté à un nœud libre qui répond aux contraintes qui ont été définies. L'exemple suivant est tiré du billet de blog:

$ docker run -d -P -e constraint:storage=ssd mysql

L'une des contraintes prises en charge est "node"que vous pouvez épingler un conteneur à un nom d'hôte spécifique. L'essaim résout également les liens entre les nœuds.

Lors de mes tests, j'ai eu l'impression que Swarm ne fonctionnait pas encore très bien avec des volumes à un emplacement fixe (ou du moins le processus de liaison n'est pas très intuitif), c'est donc quelque chose à garder à l'esprit.

Swarm est maintenant en phase bêta.

Jusqu'à récemment, le modèle Ambassador était la seule approche native de Docker pour la découverte de services d'hôte distant. Ce modèle peut toujours être utilisé et ne nécessite aucune magie au-delà de Docker simple dans la mesure où le modèle consiste en un ou plusieurs conteneurs supplémentaires qui agissent comme des proxys.

De plus, il existe plusieurs extensions tierces pour rendre compatible les clusters Docker. Les solutions tierces comprennent:

• Connexion des ponts réseau Docker sur deux hôtes, des solutions légères et diverses existent, mais généralement avec quelques mises en garde
• Découverte basée sur DNS, par exemple avec Skydock et SkyDNS
• Outils de gestion Docker tels que Shipyard et outils d'orchestration Docker. Voir cette question pour une liste complète: Comment mettre à l'échelle des conteneurs Docker en production

MISE À JOUR 3

Libswarm a été renommé en essaim et est maintenant une application séparée.

Voici la démo de la page github à utiliser comme point de départ:

# create a cluster
$ swarm create
6856663cdefdec325839a4b7e1de38e8

# on each of your nodes, start the swarm agent
#  <node_ip> doesn't have to be public (eg. 192.168.0.X),
#  as long as the other nodes can reach it, it is fine.
$ swarm join --token=6856663cdefdec325839a4b7e1de38e8 --addr=<node_ip:2375>

# start the manager on any machine or your laptop
$ swarm manage --token=6856663cdefdec325839a4b7e1de38e8 --addr=<swarm_ip:swarm_port>

# use the regular docker cli
$ docker -H <swarm_ip:swarm_port> info
$ docker -H <swarm_ip:swarm_port> run ... 
$ docker -H <swarm_ip:swarm_port> ps 
$ docker -H <swarm_ip:swarm_port> logs ...
...

# list nodes in your cluster
$ swarm list --token=6856663cdefdec325839a4b7e1de38e8
http://<node_ip:2375>

MISE À JOUR 2

L'approche officielle est maintenant d'utiliser libswarm voir une démo ici

METTRE À JOUR

Il y a une bonne idée pour la communication des hôtes openvswitch dans docker en utilisant la même approche.

Pour permettre la découverte de services, il existe une approche intéressante basée sur le DNS appelée skydock .

Il y a aussi un screencast .

C'est aussi un bel article utilisant les mêmes pièces du puzzle mais ajoutant également des vlans sur le dessus:

http://fbevmware.blogspot.it/2013/12/coupling-docker-and-open-vswitch.html

Le patch n'a rien à voir avec la robustesse de la solution. Docker n'est en fait qu'une sorte de DSL sur les conteneurs Linux et les deux solutions de ces articles contournent simplement certains paramètres automatiques de Docker et reviennent directement aux conteneurs Linux.

Vous pouvez donc utiliser les solutions en toute sécurité et attendre de pouvoir le faire de manière plus simple une fois que Docker les implémentera.

Weave est une nouvelle technologie de réseau virtuel Docker qui agit comme un commutateur Ethernet virtuel sur TCP / UDP - tout ce dont vous avez besoin est un conteneur Docker exécutant Weave sur votre hôte.

Ce qui est intéressant ici, c'est

• Au lieu de liens, utilisez des adresses IP / noms d'hôte statiques dans votre réseau virtuel
• Les hôtes n'ont pas besoin d'une connectivité complète, un maillage est formé en fonction des pairs disponibles et les paquets seront acheminés en plusieurs sauts vers l'endroit où ils doivent aller

Cela conduit à des scénarios intéressants comme

• Créez un réseau virtuel sur le WAN, aucun des conteneurs Docker ne saura ou ne se souciera du réseau réel dans lequel il se trouve
• Déplacez vos conteneurs vers différents hôtes docker physiques, Weave détectera le pair en conséquence

Par exemple, il existe un exemple de guide sur la création d'un cluster Cassandra à plusieurs nœuds sur votre ordinateur portable et sur quelques hôtes cloud (EC2) avec deux commandes par hôte. J'ai lancé un cluster CoreOS avec AWS CloudFormation, installé le tissage sur chaque in / home / core, ainsi que ma VM docker vagrant pour ordinateur portable, et j'ai obtenu un cluster en moins d'une heure. Mon ordinateur portable est pare-feu mais Weave semble être d'accord avec cela, il se connecte simplement à ses pairs EC2.

Mettre à jour

Docker 1.12 contient ce qu'on appelle le mode Swarm et ajoute également une serviceabstraction. Ils ne sont probablement pas assez matures pour chaque cas d'utilisation, mais je vous suggère de les garder sous observation. Le mode Swarm aide au moins dans une configuration multi-hôte, ce qui ne facilite pas nécessairement la liaison. Le serveur DNS interne à Docker (depuis 1.11) devrait vous aider à accéder aux noms de conteneurs, s'ils sont bien connus - ce qui signifie que les noms générés dans un contexte Swarm ne seront pas si faciles à adresser.

Avec la version Docker 1.9, vous bénéficierez d' un réseau multi-hôte intégré . Ils fournissent également un exemple de script pour provisionner facilement un cluster fonctionnel.

Vous aurez besoin d'un magasin K / V (par exemple Consul) qui permet de partager l'état entre les différents moteurs Docker sur chaque hôte. Chaque moteur Docker doit être configuré avec ce magasin K / V et vous pouvez ensuite utiliser Swarm pour connecter vos hôtes.

Ensuite, vous créez un nouveau réseau de superposition comme celui-ci:

$ docker network create --driver overlay my-network

Les conteneurs peuvent désormais être exécutés avec le nom du réseau comme paramètre d'exécution:

$ docker run -itd --net=my-network busybox

Ils peuvent également être connectés à un réseau lorsqu'ils sont déjà en cours d'exécution:

$ docker network connect my-network my-container

Plus de détails sont disponibles dans la documentation .

L'article suivant décrit bien comment connecter des conteneurs Docker sur plusieurs hôtes: http://goldmann.pl/blog/2014/01/21/connecting-docker-containers-on-multiple-hosts/

Il est possible de relier plusieurs sous-réseaux Docker en utilisant Open vSwitch ou Tinc. J'ai préparé Gists pour montrer comment le faire:

• Ouvrez vSwitch: https://gist.github.com/noteed/8656989
• Tinc: https://gist.github.com/noteed/11031504

L'avantage que je vois en utilisant cette solution au lieu de l' --linkoption et du modèle d'ambassadeur est que je le trouve plus transparent: il n'est pas nécessaire d'avoir des conteneurs supplémentaires et surtout, pas besoin d'exposer les ports sur l'hôte. En fait, je pense à l' --linkoption d'être un hack temporaire avant que Docker n'ait une meilleure histoire sur les configurations multi-hôtes (ou multi-démons).

Note: Je sais qu'il y a une autre réponse qui pointe vers mon premier Gist mais je n'ai pas assez de karma pour éditer ou commenter cette réponse.

Comme mentionné ci-dessus, Weave est certainement une solution viable pour relier les conteneurs Docker entre les hôtes. D'après ma propre expérience, il est assez simple de le mettre en place. Il dispose désormais d' un service DNS auquel vous pouvez adresser le conteneur par ses noms DNS.

D'autre part, il y a Flannel de CoreOS et Opencontrail de Juniper pour câbler les conteneurs à travers les hôtes.

On dirait que docker swarm 1.14vous permet de:

• assing hostname to container, using --hostnametag, mais je n'ai pas été en mesure de le faire fonctionner, les conteneurs ne sont pas capables de se cingler les uns les autres par les noms d'hôte assignés.

• attribution de services à la machine en utilisant --constraint 'node.hostname == <host>'