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


25

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?



Según el autor de este blog, uno NO debe ejecutar bases de datos dentro de contenedores, ya que los proveedores de la nube ofrecen bases de datos administradas.
030

Respuestas:


20

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.


Otro factor es si la alternativa es usar un servicio de DB administrado en lugar de alojar el suyo.
avi

3

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.


Gracias, esa es casi una respuesta razonada. Sin embargo, en su publicación de blog, agrega una advertencia que valida la suposición de que he escrito la parte superior. "Los problemas que se detallan a continuación no se relacionan con solo ejecutar su base de datos en la ventana acoplable sin almacenamiento compartido o la capacidad de iniciarla automáticamente en un nodo diferente". Es decir, su publicación de blog dice que la situación sobre la que escribí anteriormente es válida.
Hawkeye

Según su pregunta, parece que está utilizando algún tipo de orquestación para iniciar la base de datos y montar el volumen. Pero entonces tiene un posible problema de coherencia con la orquestación, de lo que hablo. Mi advertencia es explícitamente sobre cuando no usas orquestación.
Robo

¿Has visto flynn.io? Supuestamente están listos para la producción y evitan escenarios de cerebro dividido mediante el uso de una máquina de estado de coro (basada en Joyent Manatee).
Alix Axel

Ninguno de estos puntos se aplica a cassandra u otras bases de datos distribuidas, pero todavía no creo que sea una buena idea ejecutarlo en un contenedor.
dres

0

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.