Recientemente comencé a trabajar para una empresa que quiere dividir su aplicación SaaS monolítica en microservicios en contenedores. Sin embargo, estoy teniendo dificultades para comprender una parte fundamental del almacenamiento persistente. ¿Por qué hay tantas plataformas competidoras diferentes? Portworx, Rexray, StorageOS, Flocker, Inifint, etc.
Mis preguntas
¿Por qué alguien simplemente no activaría un servidor NFS y usaría una estructura de carpetas jerárquica allí como su back-end de almacenamiento? ¿Qué ganancias obtienes al usar una de estas herramientas?
¿Qué tan peligroso es usar algo así con Docker? ¿Cuáles son las causas comunes de la pérdida catastrófica de datos en un entorno basado en Docker?
¿Qué solución de almacenamiento persistente recomendaría y por qué? Mi empresa opera una plataforma SaaS. Las cargas útiles de datos son pequeñas (5kb-100kb). El procesamiento de datos es pequeño-mediano en el consumo de recursos. El volumen general es medio, pero continúa creciendo. Esperamos mover completamente nuestra aplicación monolítica a la nube como microservicios en contenedores separados. Incluyendo nuestro almacén de datos.
Algo no relacionado, pero está vinculado. ¿Cuáles son las fortalezas de usar Kubernetes como orquestador en lugar de ganadero / ganadero? ¿No está Kubernetes sobre diseñado para una plataforma pequeña y mediana? ¿Hay alguna fortaleza para usar Kubernetes en Rancher aparte de la instalación con un solo clic?
Gracias por la visión de usted. Perdón por la ingenuidad. Agradezco toda la documentación y material de lectura complementario.
EDITAR: por contexto, estamos usando Azure como nuestra plataforma de nube subyacente.
fuente
Respuestas:
Puedo responder al segundo punto:
Docker es más adecuado en una arquitectura basada en micro servicios cuando la aplicación se ejecuta dentro de los contenedores, pero el almacenamiento o cualquier otra sesión en vivo se mantienen en la RAM compartida o en la base de datos.
Básicamente, no debes almacenar nada dentro del contenedor acoplable. Hay muchas razones para ello:
Considere la actualización: alguien de su equipo ha creado una imagen más nueva de la aplicación y necesita que el contenedor se ejecute con la última imagen. El acoplador actual y la forma popular de hacerlo es bajar el contenedor existente y hacer girar un nuevo contenedor con los mismos parámetros de tiempo de ejecución que el contenedor anterior pero con la imagen más nueva. Esta es una de las principales razones por las cuales los contenedores siempre deben estar sin estado y no contener ningún dato. Puede tener todos sus datos montados en algún lugar y sesiones guardadas dentro de un db o algo así como memchached, etc.
Uno de los grandes casos de uso de Docker es construir clústeres. Si comienza a mantener los datos dentro de sus contenedores, es una sobrecarga para mantener esos datos sincronizados entre los contenedores de la aplicación.
La comunidad de acopladores en general no recomienda mantener ningún dato en el contenedor y, por lo tanto, nadie ha intentado correr este riesgo en la producción y nadie quiere ser el primer narrador de cómo desordenaron la producción :)
fuente