tag imagenes hub ejemplos compose comandos docker

imagenes - ¿Cómo vincular los servicios de Docker en todos los hosts?



dockerfile ejemplos (8)

Docker permite que los servidores de múltiples 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 del host. Me gustaría implementar un servicio que use otros servicios alojados en una máquina diferente.

Ha habido varios enfoques para resolver este problema en Docker, como los jumpers de CoreOS , los servicios de host local que esencialmente sustituyen a la otra máquina y un montón de proyectos de Github para administrar las implementaciones de Docker que parecen haber intentado respaldar este uso. caso.

Dado el ritmo de desarrollo, es difícil seguir las mejores prácticas actuales. Por lo tanto, mi pregunta es esencialmente: 1) ¿Qué (si existe) es el método predominante actual para vincular entre hosts en Docker, y 2) ¿hay planes para soportar esta funcionalidad directamente en el sistema Docker?

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

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

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

La ventaja que veo al utilizar esta solución en lugar de la opción --link y el patrón de embajador es que la considero más transparente: no es necesario tener contenedores adicionales y, lo que es más importante, no hay necesidad de exponer puertos en el host. De hecho, creo que la opción --link es un hack temporal antes de que Docker obtenga una historia más agradable sobre las configuraciones de varios hosts (o multi-daemon).

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

Parece que Docker Swarm 1.14 te permite:

  • Asignando hostname al contenedor, usando --hostname tag, 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>''

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

Lo que es interesante aquí es

  • En lugar de enlaces, use direcciones IP / nombres de host estáticos en su red virtual
  • Los hosts no necesitan conectividad completa, se forma una malla en función de qué pares están disponibles, y los paquetes se enrutarán con múltiples saltos hacia donde necesiten ir.

Esto lleva a escenarios interesantes como

  • Cree una red virtual a través de la WAN, ninguno de los contenedores Docker sabrá ni se interesará en la red en la que se encuentran.
  • Mueva sus contenedores a diferentes hosts físicos Docker, Weave detectará al igual en consecuencia

Por ejemplo, hay una guía de ejemplo sobre cómo crear un clúster de Cassandra multinodo 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é tejido en cada uno de los elementos / home / core, más la VM de docker vagabundo de mi laptop y obtuve un clúster en menos de una hora. Mi computadora portátil tiene cortafuegos, pero Weave parecía estar de acuerdo con eso, solo se conecta con sus pares EC2.

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 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 ver una demostración here

ACTUALIZAR

Hay una buena idea para la comunicación de los hosts de OpenSwitch en Docker usando el mismo enfoque.

Para permitir el descubrimiento del servicio hay un enfoque interesante basado en DNS llamado skydock .

También hay un screencast .

Este es también un buen artículo que usa las mismas piezas del rompecabezas pero que también agrega 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 Linux Containers y ambas soluciones en estos artículos simplemente pasan por alto algunas configuraciones automáticas de Docker y vuelven directamente a Linux Containers.

Entonces puede usar las soluciones de manera segura y esperar para poder hacerlo de una manera más simple una vez que Docker lo implemente.

Actualizar

Docker 1.12 contiene el llamado modo de enjambre y también agrega una abstracción de service . Probablemente no sean lo suficientemente maduros para cada caso de uso, pero te sugiero que los mantengas bajo observación. El modo de enjambre al menos ayuda en una configuración de múltiples hosts, lo que no necesariamente hace que la vinculación sea más fácil. 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 de Enjambre no serán tan fáciles de abordar.

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

Necesitará una tienda K / V (por ejemplo, Cónsul) que permita compartir el estado de los diferentes motores Docker en cada host. Todos los motores Docker deben configurarse con esa tienda K / V y luego puede usar Swarm para conectar sus hosts.

A continuación, crea una nueva red de superposición 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á ejecutando:

$ docker network connect my-network my-container

Más detalles están disponibles en la documentation .

Actualizar

Docker announced recientemente una nueva herramienta llamada Swarm for Docker orchestration.

Swarm le permite "unirse" a múltiples daemons de docker: Primero crea un enjambre, inicia un administrador de enjambre en una máquina y tiene daemons docker "unidos" al administrador de enjambre usando el identificador de enjambre. El cliente de Docker se conecta al administrador de enjambre como si fuera un servidor de Docker normal.

Cuando un contenedor se inició con Swarm, se asigna automáticamente a un nodo libre que cumple con cualquier restricción que se haya definido. El siguiente ejemplo se toma de la publicación del blog:

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

Una de las restricciones compatibles es "node" que le permite fijar 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 aún no funciona con volúmenes en una ubicación fija muy bien (o al menos el proceso de vincularlos no es muy intuitivo), así que esto es algo a tener en cuenta.

Swarm ahora está en fase beta.

Hasta hace poco, el patrón Ambassador era el único enfoque nativo de Docker para el descubrimiento del servicio de host remoto. Este patrón todavía se puede utilizar y no requiere ninguna magia más allá de Docker simple en que el patrón consiste en uno o más contenedores adicionales que actúan como representantes.

Además, hay varias extensiones de terceros para hacer que Docker tenga capacidad de clúster. Las soluciones de terceros incluyen:

  • Conectando los puentes de red de Docker en dos hosts, existen soluciones livianas y varias, pero generalmente con algunas advertencias
  • Descubrimiento basado en DNS, por ejemplo, con skydock y SkyDNS
  • Herramientas de administración de Docker como Shipyard y Docker orchestration tools. Consulte esta pregunta para obtener una lista extensa: cómo escalar los contenedores Docker en producción