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:
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
Cela conduit à des scénarios intéressants comme
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 ==