leave - docker swarm vs kubernetes
¿Cómo compartir volúmenes entre varios hosts en modo de enjambre del motor de la ventana acoplable? (3)
En el gran esquema de las cosas.
Las otras respuestas son definitivamente correctas. Si sientes que todavía te estás perdiendo algo o llegas a la conclusión de que las cosas nunca mejorarán realmente en este espacio, entonces deberías reconsiderar el uso de la típica abstracción del sistema de archivos jerárquico similar a POSIX. No todas las aplicaciones realmente lo necesitan (podría llegar a decir que pocas lo hacen). Tal vez el tuyo tampoco.
En defensa de los sistemas de archivos.
Todavía es muy común en muchos círculos, pero por lo general estas personas conocen muy bien sus sistemas de archivos remotos / distribuidos y saben cómo configurarlos y aprovecharlos adecuadamente (y pueden ser sistemas muy buenos también, aunque a menudo no con los controladores de volumen Docker existentes). ). A veces también es en parte porque simplemente están obligados a hacerlo (bases de código que no pueden o no deben reescribirse para admitir otros backends de almacenamiento). El uso, la configuración o incluso la escritura de controladores de volumen Docker arbitrarios sería solo una preocupación secundaria.
Alternativas
Sin embargo, si tiene la opción, evalúe otras soluciones de persistencia para sus aplicaciones. Muchas implementaciones no utilizarán las interfaces del sistema de archivos POSIX sino las interfaces de red, que no plantean dificultades particulares a nivel de infraestructura en clusters como Docker Swarm.
Soluciones gestionadas por terceros (por ejemplo, proveedores de nube)
Si logra eliminar todas las dependencias de los sistemas de archivos para obtener datos persistentes y compartidos (todavía está bien para el estado local transitorio ), entonces puede afirmar que tiene aplicaciones totalmente "sin estado". Por supuesto, a menudo siempre hay un estado persistente en algún lugar, pero la idea es que usted no lo maneje. Muchos proveedores de la nube (si es donde está alojando cosas) ofrecerán soluciones completamente gestionadas para manejar el estado persistente de modo que no tenga que preocuparse por ello en absoluto. Si va por esta ruta, considere los servicios administrados que usan API compatibles con implementaciones que puede usar localmente para realizar pruebas (por ejemplo, ejecutando un contenedor Docker basado en una imagen para esa implementación que es proporcionada por un tercero o que puedes mantenerte).
Soluciones de bricolaje
Si desea administrar el estado persistente dentro de un clúster de Docker Swarm, la abstracción del sistema de archivos suele ser inevitable (y, de todos modos, probablemente tenga más dificultades para apuntar a los dispositivos de bloque directamente). Querrá jugar con las restricciones de servicio y de nodo para garantizar que se cumplan los requisitos de lo que use para conservar los datos. Para ciertas cosas, como un servidor central de DBMS, podría ser fácil ("ejecutar siempre la tarea solo en ese nodo específico"), para otros podría ser mucho más complicado.
La tarea de configurar, escalar y monitorear tal configuración definitivamente no es trivial, por lo que muchos desarrolladores de aplicaciones están felices de dejar que otra persona (por ejemplo, proveedores de la nube) lo haga. Sin embargo, aún es un espacio muy interesante para explorar, aunque dado que tuvo que hacer esa pregunta, es probable que no sea algo en lo que deba concentrarse si tiene una fecha límite.
Conclusión
Como siempre, use la abstracción correcta para el trabajo y haga una pausa para pensar cuáles son sus fortalezas y dónde gastar sus recursos.
¿Podemos compartir un volumen de nombre único / común en varios hosts en el modo de enjambre del motor de la ventana acoplable, cuál es la forma más fácil de hacerlo?
Desde cero, Docker no admite esto por sí mismo. Debe usar componentes adicionales, ya sea un complemento de ventana acoplable que le proporcionará un nuevo tipo de capa para sus volúmenes, o una herramienta de sincronización directamente en su FS que sincronizará los datos por usted.
Desde mi punto de vista, la solución más sencilla es rsync o, con mayor precisión, lsyncd n la versión daemon de rsync. Pero nunca lo probé para los volúmenes de la ventana acoplable, así que no puedo decir si lo manejé bien. Otras soluciones se ofrecen utilizando Infinit.sh . Básicamente hace lo mismo que lsyncd . Es una sincronización de una manera. Por lo tanto, si el contenedor de la ventana acoplable está RW en sus volúmenes, no coincidirá con sus expectativas. Probé esta solución y funciona bastante bien para las operaciones de RO. Y no en producción. Sigue siendo una versión alfa. Infinit también está en camino de proporcionar un controlador de docker. No publicado aún. Así que ni siquiera lo intenté. Demasiado arriesgado.
Otras soluciones que encontré pero que no pude instalar (y así intentarlo) son flocker y glusterFS. Ambos están diseñados para crear un volumen de FS basado en varios discos duros de varias máquinas. Pero ninguno de sus repositorios funcionaba en las últimas semanas.
Lo siento por darle solo soluciones débiles, pero me enfrento al mismo problema y aún no he encontrado una solución perfecta.
Saludos, Olivier
Si tiene una configuración de servidor NFS, puede usar usar alguna carpeta nfs como un volumen de la ventana acoplable compuesto de esta manera:
volumes:
grafana:
driver: local
driver_opts:
type: nfs
o: addr=192.168.xxx.xx,rw
device: ":/PathOnServer"