Comment relier les services Docker à des hôtes?

Docker permet aux serveurs de plusieurs conteneurs de se connecter 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 voudrais implémenter un service qui utilise d’autres services hébergés sur un autre ordinateur.

Il y a eu plusieurs approches pour résoudre ce problème dans Docker, telles que les jumpers de CoreOS , les services hôte-local qui procurent essentiellement un proxy à l’autre machine et toute une série de projets github pour gérer les déploiements Docker. Cas.

Compte tenu du rythme de développement, il est difficile de suivre les meilleures pratiques actuelles. Par conséquent, ma question est essentiellement la suivante: 1) Quelle est la méthode prédominante (le cas échéant) pour relier 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 for Docker orchestration.

Swarm vous permet de “joindre” plusieurs démons de docker: vous créez d’abord un essaim, démarrez un gestionnaire de swarm sur une machine et les démons de docker “rejoignent” 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 standard.

Lorsqu’un conteneur a démarré avec Swarm, il est automatiquement affecté à un nœud libre répondant à toutes les contraintes définies. L’exemple suivant est tiré de l’article du blog:

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

L’une des contraintes sockets en charge est "node" qui vous permet d’é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 travaillait pas encore très bien avec des volumes à un emplacement fixe (ou du moins, le processus de liaison n’était pas très intuitif), il faut donc garder cela à l’esprit.

Swarm est maintenant en phase bêta.


Jusqu’à récemment, le modèle Ambassador était la seule approche de Docker native 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, car le modèle se compose uniquement d’un ou plusieurs conteneurs supplémentaires qui agissent comme des proxys.

En outre, il existe plusieurs extensions tierces pour rendre Docker compatible avec les clusters. Les solutions tierces incluent:

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

MISE À JOUR 3

Libswarm a été renommé Swarm et est maintenant une application distincte.

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

 # create a cluster $ swarm create 6856663cdefdec325839a4b7e1de38e8 # on each of your nodes, start the swarm agent #  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= # start the manager on any machine or your laptop $ swarm manage --token=6856663cdefdec325839a4b7e1de38e8 --addr= # use the regular docker cli $ docker -H  info $ docker -H  run ... $ docker -H  ps $ docker -H  logs ... ... # list nodes in your cluster $ swarm list --token=6856663cdefdec325839a4b7e1de38e8 http:// 

MISE À JOUR 2

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

METTRE À JOUR

Il y a une belle 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 en ajoutant aussi des vlans:

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

Le correctif n’a rien à voir avec la robustesse de la solution. Docker n’est en réalité qu’une sorte de DSL sur les conteneurs Linux et les deux solutions de ces articles contournent simplement certains parameters automatiques de Docker et se replient directement sur les 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 l’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ôtes 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 sont acheminés en plusieurs sauts là où ils doivent aller.

Cela conduit à des scénarios intéressants comme

  • Créer un réseau virtuel sur le WAN, aucun des conteneurs Docker ne saura ou ne se souciera du réseau réel dans lequel ils sont installés
  • Déplacer vos conteneurs vers différents hôtes Docker physiques, Weave détectera le pair en conséquence

Par exemple, vous trouverez 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 élément / home / core, ainsi que ma VM de docker vagrant portable et obtenu un cluster en moins d’une heure. Mon ordinateur portable est protégé par un pare-feu mais Weave semblait être d’accord avec cela, il se connecte simplement à ses homologues EC2.

Mettre à jour

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


Avec la version Docker 1.9, vous aurez access à un réseau multi-hôte . Ils fournissent également un exemple de script permettant de provisionner facilement un cluster fonctionnel.

Vous aurez besoin d’un magasin K / V (par exemple, Consul) qui permet de partager l’état des 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 recouvrement comme celui-ci:

 $ docker network create --driver overlay my-network 

Les conteneurs peuvent maintenant être exécutés avec le nom de réseau en tant que paramètre d’exécution:

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

Ils peuvent également être connectés à un réseau 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 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é des Gists pour montrer comment le faire:

L’avantage que je vois utiliser cette solution au lieu de l’option --link et du modèle ambassadeur est que je la trouve plus transparente: il n’est pas nécessaire d’avoir des conteneurs supplémentaires et, plus important encore, il n’est pas nécessaire d’exposer les ports sur l’hôte. En fait, je pense que l’option --link est 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 ma première liste mais je n’ai pas assez de karma pour la modifier ou la commenter.

Comme mentionné ci-dessus, Weave est certainement une solution viable pour relier les conteneurs Docker entre les hôtes. Sur la base de ma propre expérience, il est assez simple de le configurer. Il est maintenant également doté d’ un service DNS auquel vous pouvez adresser le conteneur par ses noms DNS.

D’autre part, il y a l’Opencontrail Flanelle et Juniper de CoreOS pour le câblage des conteneurs entre les hôtes.

On dirait que Docker Swarm 1.14 vous permet de:

  • associer un nom d’hôte à un conteneur, en utilisant la balise --hostname , mais je n’ai pas réussi à le faire fonctionner, les conteneurs ne peuvent pas se cingler les uns les autres par des noms d’hôte atsortingbués.

  • assigner des services à la machine en utilisant --constraint 'node.hostname == '