¿Cuáles son las razones por las que Docker no debe usarse para bases de datos?

Tengo una discusión con un amigo sobre los casos de uso de Docker . Un chico del equipo quiere usar Docker para todo, como una especie de envoltorio de proceso universal de Unix. El otro piensa que Docker solo debe usarse para aplicaciones sin estado como Microservices y aplicaciones de estilo AWS Lambda .

Hemos diseñado pruebas de conceptos para ambos. En nuestro clúster docker, tenemos una unidad compartida que se monta cuando se monta el host Docker, y si se monta una base de datos en un contenedor, simplemente monta un volumen en la unidad compartida.

Mi amigo todavía se apega a su posición, a pesar de que se me muestra la evidencia contraria. (También argumenta que Docker agrega riesgos innecesarios al agregar complejidad a la pila).

Estoy tratando de escuchar y comprender su punto de vista, tanto en un acto de empatía, como también para razonar mejor con él. (Todos nos llevamos bastante bien, así que esta es una mezcla de discusión en broma y seria).

El tipo de pregunta detrás de la pregunta es: ¿son las bases de datos ganado ? Este comentario sugiere que una buena estrategia automatizada de respaldo y recuperación para su base de datos es indistinguible de un servidor de ganado.

Mi pregunta es: ¿Cuáles son las razones por las que Docker no debe usarse para bases de datos?

EDITAR: La gente me ha pedido que aclare mi terminología. Supuse que la aplicación de la base de datos estaba en el contenedor y el almacenamiento estaba en el volumen. Lo que quise decir fue que el RDBMS está en el contenedor y el almacenamiento de la base de datos está en el volumen.

Algunos comentaristas han sugerido que los controladores de volumen de la ventana acoplable no funcionarán muy bien con las escrituras de bases de datos. (O algo por el estilo). ¿Podría por favor ampliar eso?

Cuando las personas hablan de ejecutar una base de datos en Docker, no tienen la intención de almacenar los datos en un contenedor; están hablando de tener una imagen acoplable con el software DB y montar los datos como un volumen (un volumen de enlace, no un volumen de contenedor).

Los volúmenes son una parte esencial en Docker, y no son algo escamoso o simplemente agregado. Docker no está hecho solo para servicios (micro) sin estado.

Por mucho que lo desee, no puedo encontrar una razón técnica para no ejecutar una base de datos en un Docker, así que desafortunadamente elegiré el otro lado del argumento y, por lo tanto, tal vez no le dé la respuesta que está buscando.

(Estoy usando Oracle como ejemplo porque estoy familiarizado con él, tanto de metal desnudo como dockerizado, y porque es una bestia bastante notoria por ser un poco no trivial de operar si pasa de la configuración predeterminada).

• Empaquetar el software DB en un contenedor le brinda los beneficios habituales: tener la misma versión en todas partes, evitar problemas de dependencia / biblioteca compartida, ser capaz de activar exactamente la misma DB en computadoras portátiles de desarrollador o donde sea que la necesite.
• Es muy fácil hacerlo funcionar en cualquier lugar; la actualización es trivial, y así sucesivamente. Se aplican todos los beneficios de Docker. Hay una imagen de Oracle en Dockerhub que le permite girar una base de datos en funcionamiento en un minuto o tres (y para los demás, por supuesto).
• Las personas hicieron pruebas de rendimiento y no encontraron diferencias de E / S entre volúmenes y metal desnudo ( https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/ , https: // stackoverflow .com / preguntas / 21889053 / what-is-the-runtime-performance-cost-of-a-docker-container ).
• Debajo del capó, no es como Docker de alguna manera intercepta todas las E / S, de todos modos. Simplemente se vuelve creativo con las herramientas estándar de Linux (los montajes de enlace en este caso, la destrucción de las tablas internas del núcleo que hacen posible el Docker-fu).
• Obviamente, eso no significa que pueda ejecutar dos instancias de la base de datos y simplemente hacer que funcionen en los mismos archivos, pero nadie está implicando eso. Docker no le brinda acceso automático, simultáneo y mágicamente libre de carrera a los volúmenes, y nunca pretendió hacerlo. El resto de los beneficios aún se aplican. Si su DB no detecta conflictos como este, es mejor que proporcione un script CMD a la imagen que se niegue a girar un segundo contenedor cuando el volumen ya esté en uso.
• Debe ser un poco más cuidadoso al girar / apagar el contenedor (así como no simplemente apaga un servidor de base de datos), pero eso debería ser bastante manejable.

Ahora, dependiendo de las circunstancias, puede haber razones blandas para no hacerlo:

• Oracle (la compañía), por ejemplo, ciertamente no lo apoyará si ejecuta su RDBMS en un contenedor Docker. Pero tal vez esté utilizando imágenes dockizadas de Oracle RDBMS solo para sus desarrolladores y el entorno de prueba, donde no necesitaría su soporte en ningún caso, reservándolo para un servidor de producción simple. (Pero no olvides pagar tus licencias ...).
• Si los chicos de operaciones no están familiarizados con Docker, podría ser un poco más fácil matar accidentalmente todo, destruir sus archivos de datos, etc.
• Si usted tiene grandes máquinas de metal dedicada DB ya, con grandes cantidades de almacenamiento SAN dedicado muy rápido, y corriendo nada más de todos modos, entonces no solo habría ningún punto en el uso acoplable a containerize aquellos a medida que se nunca se acaba de girar otro servidor cuando hay son cientos de GB o incluso TB de datos. Después de todo, para la producción, un RDBMS como Oracle está muy, muy avanzado en todos los aspectos de replicación, integridad de datos, failover sin tiempo de inactividad, etc. Tenga en cuenta que este argumento solo dice "no es necesario que contenga su RDBMS en contenedores". No dice "no deberías hacerlo", tal vez quieras hacerlo porque deseas implementar actualizaciones de software de bases de datos a través de contenedores o por cualquier otra razón que puedas imaginar.

Ahí vas. Por supuesto , dockerice su base de datos, al menos para sus desarrolladores (que estarán eternamente agradecidos) y sus entornos de prueba. En la producción, que se reducirá a gusto, y hay por lo menos, yo también preferiría la solución que se sienta mejor con los DBA / OPS especializados - si tienen décadas de experiencia trabajando servidores metal desnudo DB, entonces por todos los medios que confiar para continuar así. Pero si de todas formas es una startup que tiene toda la TI en la nube, entonces un contenedor Docker sería una pieza más de cebolla en toda la imagen.

Yo escribí sobre esto en profundidad pero aquí está el resumen:

• Prevenir la división del cerebro (elegir más de un nodo maestro) necesita ser resuelto. De lo contrario, puede ser catastrófico

• No existen soluciones de almacenamiento compartido listas para producción que permitan cerrar las bases de datos en una instancia y mostrarlas en otra sin perder todos sus datos.

Cuando dice que los datos están montados en un contenedor acoplable, ¿no sería más correcto decir que la "base de datos" está montada en el contenedor acoplable? Si persiste sus datos fuera del contenedor, entonces está haciendo lo "correcto" de no poner su base de datos en un contenedor.

Claro, vaya a la ciudad colocando un DBMS en un contenedor y dejándolo administrar los datos que almacena afuera, personalmente creo que es un buen diseño porque mantiene una separación clara entre la lógica y los datos. Pero una vez que coloca sus datos en un contenedor, potencialmente está jugando con fuego.

Aunque los controladores de almacenamiento de contenedores han recorrido un largo camino, personalmente todavía no estoy dispuesto a sumergirme y dejar mis datos enredados en un contenedor.