docker - Contenedores vinculados Dock con Mesos/Marathon

Question

Hasta ahora, he tenido un gran éxito al utilizar Mesos, Marathon y Docker para administrar una flota de servidores y los contenedores que les pongo. Sin embargo, ahora me gustaría ir un poco más lejos y comenzar a hacer cosas como vincular automáticamente un contenedor haproxy a cada servicio de inicio principal que se inicia, o proporcionar otros servicios en contenedor y basados ​​en daemon que están vinculados y solo están disponibles para el contenedor padre único.

Normalmente, comenzaba el servicio de ayuda primero con algún nombre, luego cuando comencé el servicio real, lo vinculaba con el asistente y todo estaría bien. Sin embargo, ¿cómo encaja este modelo en Marathon y Mesos? Parece por ahora, al menos, que la contenedorización asume un solo contenedor.

Tuve una idea para comenzar el servicio de ayuda primero, en cualquier host que pudiera encontrar, luego agregar una restricción al servicio real que nombre de host = nombre de host del servicio auxiliar, pero parece que eso causaría problemas con las ofertas de recursos y condiciones de carrera para esos recursos.

También he pensado en proporcionar una funcionalidad de "inserción" o "enlace profundo" a Docker, o a las secuencias de comandos del ejecutor que inician los contenedores Docker.

Antes de ir por alguno de estos caminos, quería saber si alguien más había resuelto este problema, o si simplemente estaba pensando demasiado en cosas horribles.

¡Gracias!

Answer 1

estás deambulando por un territorio inexplorado! ☺

Hay múltiples enfoques aquí; y ninguno de ellos es perfecto, pero la situación mejorará en futuras versiones de Docker, gracias a los ganchos de orquestación.

Una forma es utilizar un buen descubrimiento y registro de un antiguo servicio. Es decir, cuando se inicia un servicio, descubrirá su dirección de acceso público y se registrará en, por ejemplo, Zookeeper, Etcd o incluso Redis. Dado que no es trivial para un servicio averiguar su dirección disponible públicamente (a menos que adopte algunas convenciones, por ejemplo, siempre asignando el puerto X: X en lugar de dejar que Docker asigne puertos aleatorios), es posible que desee realizar el registro desde afuera. Eso significa que su capa de orquestación (Mesos en ese caso) iniciará el contenedor, luego descubrirá el host y el puerto, y lo colocará en su sistema de descubrimiento de servicios. No estoy muy familiarizado con Marathon, pero deberías poder registrar un gancho para eso. Luego, otros contenedores simplemente buscarán la dirección del punto final en el registro de descubrimiento de servicios, simple y llanamente.

También puedes mirar Skydock , que automáticamente registra los nombres DNS de tus contenedores con Skydns. Sin embargo, actualmente es de un solo host, por lo que si te gusta esa idea, tendrás que ampliarla de alguna manera para admitir varios hosts, y quizás registros SRV.

Otro enfoque es usar "puntos de entrada conocidos". Este es en realidad el caso simplificado de descubrimiento de servicio. Significa que se asegurará de que sus servicios siempre se ejecuten en hosts y puertos preestablecidos, para que pueda usar esas direcciones de forma estática. Por supuesto, esto es malo (porque hará tu vida más difícil cuando desees reproducir el entorno para fines de prueba / estadificación), pero si no tienes ni idea del descubrimiento de servicios, bueno, podría ser un comienzo.

También podría usar Pipework para crear una (o varias) redes virtuales que abarquen múltiples hosts y unir sus contenedores. Pipework le permitirá asignar direcciones IP manualmente o automáticamente a través de DHCP. Sin embargo, este enfoque no es recomendable, pero es una buena opción si también desea conectar sus contenedores a una arquitectura de red existente (por ejemplo, VLAN ...).

No importa qué solución decida usar, le recomiendo que "pretenda" que está utilizando enlaces. Es decir, en lugar de codificar la configuración de su aplicación para conectarse a (ejemplo aleatorio) my-postgresql-db:5432 , use las variables de entorno DB_PORT_5432_TCP_ADDR y DB_PORT_5432_TCP_PORT (como si fuera un enlace) y establezca esas variables al iniciar el contenedor. De esta forma, si "pliega" sus contenedores en un entorno más simple sin descubrir el servicio, etc., puede recurrir fácilmente a los enlaces sin esfuerzos.