hashtags architecture docker service-discovery linux-containers

architecture - hashtags - Anunciando su aplicación desde dentro de un contenedor(acoplador)



architecture hashtags instagram (2)

Creo que tal vez el enfoque para realizar el registro del servicio después de lanzar el contenedor. Otros contenedores pueden realizar una búsqueda de registro para descubrir estos servicios.

Actualizar

El proyecto maestro proporciona un ejemplo de cómo los contenedores se configuran externamente y luego se inician para configurar una red cooperativa de contenedores.

Hice esta pregunta en el IRC de Docker durante el fin de semana, pero tuve que irme antes de pensar en las respuestas:

Si tengo varias aplicaciones ejecutándose en contenedores (supongamos, por el momento, que todas se ejecutan en el mismo hardware físico, pero ese no es el caso) y quiero que cada una de ellas pueda encontrar cada una otro automáticamente

Utilizando algún tipo de registro (p. Ej., Etcd o DNS-SD / Bonjour) podría anunciar su servicio y cualquier detalle pertinente y hacer que las otras aplicaciones lo descubran y enrutar el tráfico en consecuencia.

El problema aquí es que, aunque una aplicación puede saber qué nombre de host / puerto se está publicando dentro de un contenedor, no es necesario que sea el puerto o la dirección desde la que se puede acceder. Hay dos bits de información que deben unirse:

  • Donde se puede acceder al servicio; accesible desde fuera del contenedor
  • Qué hace el servicio (número de versión, tipo de servicio); accesible desde el interior del contenedor

¿Cómo recomendaría que obtuviera esta información a través de la barrera de contenedores?

  1. Podría exponer docker sobre TCP a los contenedores, por lo que una aplicación puede consultar dónde se muestra, pero esto parece violar la separación de preocupaciones.
  2. Podría tener un archivo / puerto abierto en mi contenedor que el sistema host consulta después de que se inicia un contenedor para prepararse para un anuncio, pero esto se siente como si estuviera reinventando el WSDL.

¿Alguna idea u orientación sobre cómo debería resolver este problema?


He tenido problemas con esto también. Creo que el error en su forma de pensar es que el contenedor en sí es el único que sabe lo que hace.

Los contenedores no son entidades autoconscientes que estén prestando servicio a MySQL hoy, y decidan convertirse en un procesador de cola mañana.

En cambio, hay un controlador (que puede ser simplemente un sistema automatizado, o usted en la línea de comando), y ese controlador sabe que una aplicación en particular debe ejecutarse, que para ejecutar esta aplicación, se necesita un cierto conjunto de servicios, y eso Es por eso que se inicia un contenedor en primer lugar.

El controlador sabe que se necesita un servicio MySQL y que un servicio MySQL representa un solo host: puerto para conectarse. Si es el caso, también puede saber que un servicio se compone de dos o tres puertos.

Por lo tanto, es arquitectónicamente correcto que el host / controlador le diga al contenedor con qué dirección se registre, o que le pregunte a qué puerto local está atendiendo (o más probablemente, que conozca el puerto según la definición del contenedor).

En la práctica, el host puede decirle al contenedor "ejecute su servicio en la interfaz LAN en este puerto específico y lo registraré", "ejecute su servicio usted mismo en cualquier puerto de esta interfaz LAN y regístrelo usted mismo" o "ejecute su servicio en este puerto y registrarlo con el host: puerto y configurar las asignaciones para garantizar que esté disponible allí ".

Todo esto arquitectónicamente estaría bien: al final, siempre es el anfitrión / controlador el que decide, porque es realmente el único que sabe qué servicios se ejecutan y dónde están accesibles.

Encuentro que un problema práctico con esto en la ventana acoplable es que las direcciones IP del contenedor y los puertos mapeados del host se asignan dinámicamente de tal forma que no se puede obtener realmente ninguna información hasta después de que se ejecuta el contenedor; por eso Flynn elige las asignaciones del puerto de host en lugar de dejar que Docker lo haga automáticamente.

He escrito algunos de mis pensamientos sobre esto.