¿Cómo vincular los servicios de Docker entre hosts?

Estibador permite que los servidores de varios contenedores se conecten entre sí a través de enlaces y descubrimiento de servicios . Sin embargo, por lo que puedo ver, este descubrimiento de servicio es local de host. Me gustaría implementar un servicio que utilice otros servicios alojados en una máquina diferente.

Ha habido varios enfoques para resolver este problema en Docker, como CoreOSjumpers , los servicios locales de host que esencialmente hacen proxy a la otra máquina, y un montón de proyectos de github para administrar las implementaciones de Docker que parecen haber intentado admitir este caso de uso. .

Dado el ritmo de desarrollo, es difícil seguir las mejores prácticas actuales. Por lo tanto, mi pregunta es esencialmente:

1. ¿Cuál (si lo hay) es el método predominante actual para vincular entre hosts en Docker, y
2. ¿Hay planes para admitir esta funcionalidad directamente en el sistema Docker?

Actualizar

Docker ha anunciado recientemente una nueva herramienta llamada Swarm para la orquestación de Docker.

Enjambre te permite "unirte" a múltiples demonios acoplables: primero creas un enjambre, inicias un administrador de enjambres en una máquina y haces que los demonios acoplables "se unan" al administrador de enjambres usando el identificador del enjambre. El cliente de la ventana acoplable se conecta al administrador de enjambres como si fuera un servidor acoplable normal.

Cuando un contenedor comenzó con Swarm, se asigna automáticamente a un nodo libre que cumple con las restricciones que se han definido. El siguiente ejemplo se tomó de la publicación del blog:

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

Una de las restricciones admitidas es "node"que le permite anclar un contenedor a un nombre de host específico. El enjambre también resuelve enlaces entre nodos.

En mis pruebas tuve la impresión de que Swarm todavía no funciona muy bien con volúmenes en una ubicación fija (o al menos el proceso de vincularlos no es muy intuitivo), así que esto es algo a tener en cuenta.

Swarm está ahora en fase beta.

Hasta hace poco, Ambassador Pattern era el único enfoque nativo de Docker para el descubrimiento de servicios de host remoto. Este patrón aún se puede usar y no requiere ninguna magia más allá de Docker simple, ya que el patrón consta de uno o más contenedores adicionales que actúan como proxies.

Además, hay varias extensiones de terceros para que Docker sea compatible con clústeres. Las soluciones de terceros incluyen:

• Al conectar los puentes de red de Docker en dos hosts, existen soluciones ligeras y diversas, pero generalmente con algunas advertencias
• Descubrimiento basado en DNS, por ejemplo, con skydock y SkyDNS
• Herramientas de administración de Docker como Shipyard y herramientas de orquestación de Docker. Consulte esta pregunta para obtener una lista extensa: Cómo escalar contenedores Docker en producción

ACTUALIZACIÓN 3

Libswarm ha sido renombrado como swarm y ahora es una aplicación separada.

Aquí está la demostración de la página de github para usar como punto de partida:

# 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>

ACTUALIZACIÓN 2

El enfoque oficial ahora es usar libswarm. Vea una demostración aquí.

ACTUALIZAR

Hay una buena esencia para la comunicación de hosts openvswitch en la ventana acoplable usando el mismo enfoque.

Para permitir el descubrimiento de servicios, existe un enfoque interesante basado en DNS llamado skydock .

También hay un screencast .

Este también es un buen artículo que usa las mismas piezas del rompecabezas, pero agrega también vlans en la parte superior:

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

El parche no tiene nada que ver con la solidez de la solución. Docker es en realidad solo una especie de DSL sobre contenedores de Linux y ambas soluciones en estos artículos simplemente omiten algunas configuraciones automáticas de Docker y recurren directamente a los contenedores de Linux.

Así que puedes usar las soluciones de forma segura y esperar a poder hacerlo de una manera más sencilla una vez que Docker lo implemente.

Weave es una nueva tecnología de red virtual de Docker que actúa como un conmutador de Ethernet virtual sobre TCP / UDP; todo lo que necesita es un contenedor Docker que ejecute Weave en su host.

Lo interesante aquí es

• En lugar de enlaces, use IP estáticas / nombres de host en su red virtual
• Los hosts no necesitan conectividad completa, se forma una malla en función de los pares disponibles y los paquetes se enrutarán en varios saltos a donde deben ir

Esto conduce a escenarios interesantes como

• Cree una red virtual a través de la WAN, ninguno de los contenedores de Docker sabrá o le importará en qué red se encuentran
• Mueva sus contenedores a diferentes hosts de Docker físicos, Weave detectará el par en consecuencia

Por ejemplo, hay una guía de ejemplo sobre cómo crear un clúster de Cassandra de varios nodos en su computadora portátil y algunos hosts en la nube (EC2) con dos comandos por host. Lancé un clúster de CoreOS con AWS CloudFormation, instalé weave en cada in / home / core, además de la máquina virtual de docker vagabundo de mi computadora portátil, y conseguí un clúster en menos de una hora. Mi computadora portátil tiene cortafuegos, pero Weave parecía estar de acuerdo con eso, simplemente se conecta a sus pares EC2.

Actualizar

Docker 1.12 contiene el llamado modo enjambre y también agrega una serviceabstracción. Probablemente no sean lo suficientemente maduros para cada caso de uso, pero le sugiero que los mantenga bajo observación. El modo de enjambre al menos ayuda en una configuración de múltiples hosts, lo que no necesariamente facilita la vinculación. El servidor DNS interno de Docker (desde 1.11) debería ayudarlo a acceder a los nombres de los contenedores, si son bien conocidos, lo que significa que los nombres generados en un contexto Swarm no serán tan fáciles de abordar.

Con la versión Docker 1.9, obtendrá una red integrada de múltiples hosts . También proporcionan un script de ejemplo para aprovisionar fácilmente un clúster de trabajo.

Necesitará una tienda K / V (por ejemplo, Consul) que le permita compartir el estado entre los diferentes motores Docker en cada host. Cada motor de Docker debe configurarse con esa tienda K / V y luego puede usar Swarm para conectar sus hosts.

Luego crea una nueva red superpuesta como esta:

$ docker network create --driver overlay my-network

Los contenedores ahora se pueden ejecutar con el nombre de la red como parámetro de ejecución:

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

También se pueden conectar a una red cuando ya se están ejecutando:

$ docker network connect my-network my-container

Más detalles están disponibles en la documentación .

El siguiente artículo describe muy bien cómo conectar contenedores de Docker en múltiples hosts: http://goldmann.pl/blog/2014/01/21/connecting-docker-containers-on-multiple-hosts/

Es posible unir varias subredes de Docker mediante Open vSwitch o Tinc. He preparado Gists para mostrar cómo hacerlo:

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

La ventaja que veo al usar esta solución en lugar de la --linkopción y el patrón de embajador es que la encuentro más transparente: no hay necesidad de tener contenedores adicionales y, lo que es más importante, no es necesario exponer puertos en el host. En realidad, pienso en la --linkopción de ser un truco temporal antes de que Docker obtenga una historia más agradable sobre configuraciones de múltiples hosts (o múltiples demonios).

Nota: Sé que hay otra respuesta que apunta a mi primera esencia, pero no tengo suficiente karma para editar o comentar esa respuesta.

Como se mencionó anteriormente, Weave es definitivamente una solución viable para vincular contenedores Docker entre los hosts. Basado en mi propia experiencia con él, es bastante sencillo configurarlo. Ahora también tiene servicio DNS que puede direccionar los contenedores por sus nombres DNS.

Por otro lado, está Flannel de CoreOS y Opencontrail de Juniper para conectar los contenedores a través de los hosts.

Parece que el enjambre de Docker 1.14te permite:

• Asignando el nombre de host al contenedor, usando la --hostnameetiqueta, pero no he podido hacer que funcione, los contenedores no pueden hacer ping entre sí por los nombres de host asignados.

• asignar servicios a la máquina usando --constraint 'node.hostname == <host>'